Resources
Blogs
Hrida AI Blog

Cutting LLM Costs with Intelligent Model Routing

Most LLM bills are high because one flagship model answers everything. See the real price gap between model tiers, a worked cost example with every assumption shown, and how SPRO routes each request to the right model with a two-line code change.

← Back to Blog

The Model That Answers Everything

Most LLM bills are not too high because of volume. They are too high because one premium model is answering questions a model a tenth of its price would answer just as well.

The pattern is familiar. Early in a project, someone picks the strongest model available, drops its name into a config file, and ships. It works. Months later, that same flagship model is tagging support tickets, pulling dates out of emails, reformatting JSON and detecting the language of a chat message. Every one of those calls is billed at frontier rates. Nobody decided to do this. It just never got revisited.

This blog shows how to find that waste in your own traffic, what the current price gap between model tiers actually looks like, how much routing can save (with every assumption on the table), and where a secure AI gateway like SPRO fits in.


Step One: Look at What You Are Actually Asking the Model

Before touching any pricing page, pull a day of request logs and bucket every call by the job it does. You do not need a classifier for this. Grouping by endpoint or prompt template gives you most of the picture in an afternoon.

For a typical AI-enabled SaaS product (a support assistant, a document workflow, some in-app writing help), the buckets usually look like this:

  • Classification and routing: ticket category, intent, sentiment, language, "is this spam?" The output is a single label or a short JSON object.
  • Extraction: pulling names, dates, amounts or line items out of emails, invoices and forms into a schema.
  • Drafting: replies, summaries, product copy, changelog entries. Tone matters, but the reasoning is shallow.
  • Complex reasoning: multi-step analysis, agentic tool use, hard code generation, anything where a weaker answer costs you a customer.

The uncomfortable finding is almost always the same: the first two buckets are the majority of requests, and they are where a flagship model adds the least. A small model returns the same label. Often it returns a cleaner one, because it does not wrap the answer in three paragraphs of explanation you then have to parse out.

The last bucket is where the premium model earns its price. The goal is not to stop using it. The goal is to stop using it for everything.


The Price Gap Is Wider Than Most Teams Assume

Today's list prices put up to a 100x spread between the top and bottom of a single provider's lineup: OpenAI lists GPT-6 Astra at $10 / $50 per million input / output tokens and GPT-6 Luna at $0.10 / $0.50. These are the models used in this post, across four providers, at standard (non-batch) API rates as of October 2026:

ModelProviderTierInput ($/1M tokens)Output ($/1M tokens)Typical fit
GPT-6 AstraOpenAIPremium flagship10.0050.00The most demanding reasoning and research
Claude Opus 5.5AnthropicFlagship4.0020.00Long-running agentic work, hard reasoning
GPT-6.1 SolOpenAIFlagship-class2.0010.00Near-Astra performance on complex work at lower cost
Claude Sonnet 5.5AnthropicMid2.0010.00Drafting, summaries, most production work
DeepSeek V4 ProDeepSeekMid1.32†3.96†Low-cost mid-tier generation
DeepSeek V4.1 FlashDeepSeekSmall0.30†1.20†Low-cost, high-volume tasks
Gemini 3.1 Flash-LiteGoogleSmall0.251.50Low-cost, high-volume text tasks
GPT-6 LunaOpenAISmall0.100.50Focused, high-volume tasks
Claude Haiku 5.5AnthropicSmall0.10*0.50*Classification, extraction, routing

*Haiku 5.5 rates apply to prompts up to 100,000 tokens; longer prompts are billed at $0.50 / $2.50. We left out newer Gemini models such as Gemini 3.8 Flash and Gemini 4 Argon because Google lists them at promotional prices that rise in December 2026 and January 2027.

†DeepSeek rates shown are peak-hour prices (weekdays 01:00–04:00 and 06:00–10:00 UTC); off-peak rates are half. DeepSeek has changed its prices several times in 2026, so check them before budgeting.

Three details matter when comparing these numbers:

  • Every major provider now ships a small tier for bulk work. OpenAI describes GPT-6 Luna as built for focused, high-volume tasks, and Anthropic positions Haiku 5.5 for classification, extraction and routing.
  • The best option per task often sits with a different vendor. That is why this post mixes providers rather than staying inside one lineup.
  • Tokenizers differ. Anthropic notes that its Claude 4.7-and-later models produce roughly 30% more tokens for the same text than earlier ones, so per-token prices are not perfectly comparable across vendors. Measure tokens on your own prompts before you trust any spreadsheet, including ours.

Why Nobody Does This, and the Two-Line Fix

"Use small models for easy work" is advice everyone agrees with and few teams act on. Doing it by hand means a separate SDK and auth flow per provider, retry and failover logic for each, a task classifier, and cost tracking stitched across several billing dashboards. That is weeks of plumbing, plus maintenance every time a provider ships a new model, which in 2026 is roughly monthly.

A gateway collapses that into one integration. Your application keeps talking to a single OpenAI-compatible endpoint. The gateway holds the provider credentials, decides which model serves each request, and handles retries when a provider has a bad hour.

The Entire Application-Side Change

If your code already uses the OpenAI SDK, this is all that changes:

import os
from openai import OpenAI

# Before: client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
client = OpenAI(
    base_url=os.environ["SPRO_BASE_URL"],   # change 1: point at the gateway
    api_key=os.environ["SPRO_API_KEY"],
)

resp = client.chat.completions.create(
    model="support-router",                 # change 2: a routing alias, not a model ID
    messages=[{"role": "user", "content": ticket_text}],
)

Everything else (prompts, message format, streaming and tool-calling code) stays the same. support-router is an illustrative alias name: you define it in the gateway, map it to the models you want, and change that mapping later without redeploying. The same pattern works in Node, Go or anything else with an OpenAI-compatible client.


Designing the Routing Table

A good routing policy is boring on purpose: a short list of task types, one primary model each, a fallback, and a strong default for anything the router cannot place.

Task TypePrimary ModelFallbackWhy
Classification (intent, sentiment, language, spam)GPT-6 Luna (OpenAI)Claude Haiku 5.5 (Anthropic)Output is a label; the cheapest tier handles well-specified prompts
Extraction (invoices, emails, forms to JSON)Gemini 3.1 Flash-Lite (Google)GPT-6 Luna (OpenAI)Schema-bound output; validate it rather than pay for reasoning
Drafting (replies, summaries, copy)DeepSeek V4 Pro (DeepSeek)Claude Sonnet 5.5 (Anthropic)Voice matters, deep reasoning does not; mid-tier quality at a low price
Complex reasoning, agents, hard codeClaude Opus 5.5 (Anthropic)GPT-6.1 Sol (OpenAI)Model quality visibly changes the outcome
Default (unclassified)Claude Opus 5.5 (Anthropic)GPT-6.1 Sol (OpenAI)Ambiguous prompts should land on a model that can handle them

The specific picks are illustrative. On paper GPT-6 Luna is cheaper than Gemini 3.1 Flash-Lite, so if Luna passes your extraction evals, use it. Likewise, test DeepSeek V4 Pro's drafts against your brand voice before moving customer-facing replies to it. Provider data-handling terms matter too: some teams limit which providers may receive customer data, a rule a gateway can enforce per route.

Four Rules That Keep Routing From Backfiring

  1. Make the default strong, not cheap. Prompts that are half code and half explanation fall through to the default bucket. If that bucket is your cheapest model, your worst-case answers get worse.
  2. Route by latency, not only price, on user-facing paths. For chat UIs, prioritise time-to-first-token. Save lowest-price routing for batch and background jobs.
  3. Cross providers in your fallbacks. Every primary model above falls back to a model from a different provider, so a single provider outage never takes down a whole task type.
  4. Put guardrails in front of the router, not behind it. Cheaper models are not necessarily more robust to prompt injection, and PII in a prompt is just as sensitive whichever model reads it. Inspect and mask on the way in, validate on the way out, whichever model serves the request.

The Math: A Worked Example

In this hypothetical, routing cuts a $42,150 monthly bill to $22,330, a 47.0% saving, without moving a single complex request off the flagship model.

Assumptions

  • Volume: 100,000 requests a day, 3,000,000 a month.
  • Traffic mix and token counts: shown in the table below, chosen to resemble a support-plus-documents SaaS workload. These are illustrative, not measured.
  • Baseline: every request goes to Claude Opus 5.5, a common "pick the strongest model" default. A team defaulting to GPT-6 Astra ($10 / $50) would save more; one defaulting to GPT-6.1 Sol ($2 / $10) would save less.
  • Prices: the list rates from the pricing table above, with DeepSeek at its peak-hour rates as the conservative case for daytime traffic.
  • Simplifications: the same token counts are used for every model (ignoring tokenizer differences), and the math excludes prompt caching, batch discounts and any gateway fees.

Each bucket's cost is calculated the same way:

monthly cost = requests × (input tokens × input price + output tokens × output price) ÷ 1,000,000

For classification on Opus: 1,050,000 × (600 × $4 + 30 × $20) ÷ 1,000,000 = $3,150.

On GPT-6 Luna: 1,050,000 × (600 × $0.10 + 30 × $0.50) ÷ 1,000,000 = $78.75.

Before vs. After

Task TypeShareRequests / MonthAvg Tokens (In / Out)All on Opus 5.5Routed ToRouted CostSaving
Classification35%1,050,000600 / 30$3,150GPT-6 Luna$78.7597.5%
Extraction20%600,0001,500 / 250$6,600Gemini 3.1 Flash-Lite$45093.2%
Drafting30%900,0002,000 / 400$14,400DeepSeek V4 Pro$3,801.6073.6%
Complex reasoning15%450,0004,000 / 1,200$18,000Claude Opus 5.5 (unchanged)$18,0000%
Total100%3,000,000$42,150$22,33047.0%

That is $19,820 a month, or about $238,000 a year, from a configuration change.

What the Numbers Actually Say

  • Request share is not cost share. Classification and extraction are 55% of requests but only 23% of the baseline bill, because their prompts and outputs are short. The dramatic per-request savings (up to 40x) shrink once weighted by spend.
  • The mid tier moves the most dollars. Shifting drafting from Opus to DeepSeek V4 Pro saves $10,598 a month, more than classification and extraction combined ($9,221). Run drafting off-peak and that line drops from $3,802 to $1,901. If drafting stays on Opus, total savings fall to 21.9%.
  • Hard work dominates what is left. After routing, the 15% of complex requests make up 81% of the bill. That is the right shape: you are now paying flagship prices almost exclusively for flagship work.

Your number will differ. A chat product dominated by long, open-ended conversations will save less; a pipeline that is mostly tagging and parsing will save more.


Before You Flip the Switch

Routing saves money only if quality holds, and you can only know that from your own prompts.

  • Run a shadow evaluation first. Send a few hundred real prompts per task type to both the current and the candidate model. For classification and extraction, score automatically (exact label match, schema-valid JSON). For drafting, use side-by-side human review on a sample.
  • Roll out by percentage. Send 5% of a task type to the cheaper model, watch error, feedback and retry rates for a week, then widen.
  • Watch for hidden costs. A cheaper model that fails validation and triggers a retry on the expensive one can cost more than never routing at all. Track retries and escalations per route.
  • Don't route a bad prompt down. A vague prompt that only works because a flagship model fills in the gaps will break on a small model. Fix the prompt first; it often then works on the smaller model too.
  • Re-check every quarter. Prices and lineups change constantly. Keeping the mapping in a gateway, not in code, is what makes revisiting it cheap.

Where SPRO Fits: Routing With Security Built In

SPRO, a product of Hrida AI, is a unified AI gateway and security platform, not just a routing layer. Once all your AI traffic flows through one gateway, that gateway is also the natural place to enforce security, with guardrails enabled by default rather than bolted on later.

Routing ChallengeHow SPRO Handles It
Separate integrations per providerOne OpenAI-compatible API for 350+ models across 16+ providers, including OpenAI, Anthropic, Google, DeepSeek, Groq, Mistral and xAI
Picking the right model per requestDynamic routing by cost, latency or quality
Provider outagesAutomatic retries and provider failover
Cheaper models and new providers widen the attack surface29 guardrails on every request, regardless of which model serves it
Runaway loops and bill shockRequest, token and cost limits per application
Costs scattered across dashboardsUnified billing and observability across every provider

Guardrails on Every Route

Whether a request lands on a flagship or a small model, SPRO evaluates it against the same policies: PII and PHI masking before prompts leave your organisation, prompt-injection and jailbreak detection, output validation against JSON schemas, toxicity filtering and hallucination checks. Routing to a cheaper model never means routing to a weaker security posture.

Spend Limits Cap the Worst Case

Routing lowers your average cost per request. Spend limits cap your worst case. A malicious prompt or a buggy agent loop can be stopped before it turns into an invoice. You want both.

Managed Keys or Bring Your Own

Start with a single SPRO API key and unified billing, or connect your existing provider credentials. Either way, every request flows through the same routing engine, caching, guardrails and observability.


Key Takeaways

  • Most LLM overspend comes from sending every task to one flagship model, not from high volume.
  • Current list prices show up to a 100x gap between flagship and small models within a single provider's lineup.
  • The cheapest good model for each task often comes from a different provider.
  • In our hypothetical worked example, routing cut monthly spend by 47.0% while keeping complex work on the top model.
  • The application change is two lines: a new base URL and a routing alias.
  • Quality must be verified on your own prompts before production traffic moves.
  • A gateway is where routing, failover, spend limits and security guardrails belong together.

Sources

Prices checked October 21, 2026. List prices change often; confirm before relying on them.


Conclusion

The cheapest token is the one you never send to a flagship model by accident. Most teams are not overpaying because they chose the wrong model. They are overpaying because they chose one model for every job and never looked again.

The question every team should keep asking is simple:

Do you know which model answered each of yesterday's requests, and whether it needed to?

Because in the age of multi-model AI, cost control and security both belong at the one place every request passes through.

🚀 Explore SPRO

Ready to route every request to the right model, securely?

Learn how SPRO gives you one API for 350+ models with intelligent routing, automatic failover, spend limits, and guardrails on every request.

🌐 Learn More

Right model. Right price. Protected by default.

HridaAI
Wed Oct 21 2026