The Cheapest LLM API: What 'Cheap' Actually Means

"What's the cheapest LLM API" sounds like a question with a one-line answer: look up the price sheets, find the lowest number, done. In practice the question is ambiguous in a way that matters a lot once real money is involved, because "cheapest" can mean three different things that point to three different answers. This post works through the distinction with current provider pricing and a worked example, because the gap between these definitions is exactly where a lot of AI budgets quietly go sideways.

Three things "cheapest" can mean

The first meaning is the cheapest individual model's list price: whichever model has the lowest per-token rate on a provider's pricing page, full stop. This is the easiest number to find and the one most comparison articles report, because it requires no context about your actual workload.

The second meaning is the cheapest way to handle a whole workload by mixing models: sending each request to whichever model in a pool can handle it for the least money, rather than sending everything to one model. A workload is rarely uniform, so the model with the lowest sticker price is not automatically the cheapest way to serve every request in it, especially the ones that need more capability than that model has.

The third meaning is the cheapest way to handle a workload once you count the cost of wrong answers that have to be redone, escalated, or that cause real damage downstream. This is the meaning that gets left out of nearly every pricing comparison, because it depends on your specific failure rate and what a bad answer costs you, not on anything a provider publishes. A model that is cheaper per token but wrong more often on your traffic can easily be more expensive once you count rework, and it can be a lot more expensive if the wrong answer reaches a customer before anyone catches it.

Most "cheapest LLM API" content answers the first question and implies it has answered the third. It hasn't. Here is what each one actually looks like with real numbers.

Current per-token pricing: a snapshot, not a fact

Model pricing changes often enough that any table like this is accurate as of the day it was checked and nothing more. Both figures below come from each provider's own pricing documentation, and both pages are worth checking directly rather than trusting a screenshot of them, since either provider can and does revise these numbers.

Source: OpenAI's published API pricing and Anthropic's published Claude API pricing, both checked September 2026. Verify against the live pages before relying on these figures for a budget.

The spread inside a single provider's own lineup is the first thing worth noticing. OpenAI's cheapest listed model is roughly 200 times less expensive on input tokens than its flagship, and Anthropic's cheapest is 5 times less expensive than its own flagship on input and output alike. If your workload sends every request to the flagship model regardless of whether it needs that much capability, the "cheapest LLM API" question was never really about which provider to pick. It was about which model inside your chosen provider's own lineup you were leaving on the table.

Anthropic's own documentation states this plainly as guidance for anyone deciding between its tiers:

"Use appropriate models: Choose Haiku for simple tasks, Sonnet for most production workloads, and Opus for the most complex reasoning."

Source: Anthropic, Claude API pricing documentation

That is a mixing recommendation, not a single-model recommendation, and it comes from the provider itself.

A worked example: blending models across a realistic workload

Take a workload of 100,000 requests a day, a mix that looks like a lot of real production traffic once you break it down by actual difficulty rather than assuming every request is the same:

• 70,000 requests are simple: classification, short extraction, formatting, routine lookups. These do not need frontier reasoning.
• 25,000 requests are moderate: multi-step reasoning, longer context, but nothing near the hardest end of what the traffic contains.
• 5,000 requests are genuinely hard: complex reasoning, high-stakes output, or both.

Assume an average of 800 input tokens and 400 output tokens per request across the board, a simplification real traffic rarely respects exactly, but close enough to illustrate the shape of the math. Using the Anthropic pricing above:

Scenario A: everything goes to Claude Opus 5. 100,000 requests x (800 input tokens x $5/million + 400 output tokens x $25/million) = 100,000 x ($0.004 + $0.01) = $1,400 per day.

Scenario B: mixed by actual difficulty.

• 70,000 simple requests on Haiku 4.5: 70,000 x ($0.0008 + $0.002) = $196
• 25,000 moderate requests on Sonnet 5: 25,000 x ($0.0016 + $0.004) = $140
• 5,000 hard requests on Opus 5: 5,000 x ($0.004 + $0.01) = $70
• Total: $406 per day

That is roughly a 71% reduction in this illustrative scenario, and it is entirely a function of the mix, nothing about any single model got cheaper. This is the second definition of cheap doing real work: the blended cost of matching each request to a model that can actually handle it, rather than defaulting every request to whichever model handles the hardest case.

Where the third definition changes the math again

Scenario B looks great until you ask what happens when the split is wrong: when a request classified as "simple" actually needed Sonnet-level reasoning and Haiku got it wrong. If nothing catches that, the wrong answer ships, and the cost of fixing it, a support ticket, a redone task, a customer who lost trust in the output, is very likely to exceed whatever you saved routing that one request to the cheap tier. Run enough of those silently and the "71% cheaper" scenario can end up costing more than the flat, safe Scenario A, just spread across a different ledger than the one you were watching.

This is the entire argument for pairing routing with verification rather than trusting the split blind: a check on the answer before it ships, and an automatic escalation to a stronger model when the check fails, is what lets you route aggressively without eating the third definition's downside. Guessing the split correctly up front is hard; catching the guesses that were wrong is a more tractable problem, and it is the one worth solving if you want the savings in Scenario B to actually be real. The broader cost optimization playbook covers routing, caching, and the other levers this worked example is one piece of.

What this means for picking a provider or a router

None of this argues for a specific provider being "the cheapest." It argues that the question needs a workload attached to it before it has an answer. A provider whose flagship model is expensive can still be the cheapest option for you if its cheap tier handles most of your traffic well; a provider with a low headline price can still be expensive if your traffic skews toward the requests only its top tier can handle safely.

llm11 resells at exactly the provider's own list price with no markup added to any model, so the pricing page shows the same per-model rates you would get calling providers directly; the mechanism that can save money is the routing and verification layer sitting in front of that pricing, not a discount on the tokens themselves. For a look at how that compares to a hosted router with a different pricing model and a free auto-router, the OpenRouter alternative page goes through that comparison directly, and llm11's own cost-first positioning explains where the actual savings come from when routing is done with checks attached.

Frequently asked questions

Is the cheapest individual model always the cheapest choice?

No. The cheapest model by list price is only the cheapest choice for requests it can actually handle correctly. For a mixed workload, blending models by difficulty usually beats sending everything to either the cheapest or the most capable model alone, and for any workload where wrong answers carry a real cost, the model with the lowest error rate on your specific traffic can be worth more than the model with the lowest sticker price.

How often does LLM pricing change?

Often enough that any specific figure should be treated as a snapshot rather than a permanent fact. Providers have introduced new model tiers, cut prices on existing ones, and retired older models multiple times within a single year, which is why this post links to the live pricing pages rather than only quoting numbers.

Does mixing models actually save money in practice, or just in theory?

It saves money in practice whenever a workload genuinely contains a range of difficulty, which most production traffic does. The size of the saving depends entirely on how accurately requests get matched to the model that can handle them, which is why routing accuracy and verification matter as much as the price table itself.

Does llm11 mark up model pricing to fund its own service?

No. Every token is billed at the exact rate the provider reports for that call, with llm11's only revenue coming from a percentage fee applied when you purchase credits, not from a markup on tokens. The exact current fee and credit mechanics are on the pricing page.

What's the risk of routing to a cheaper model without checking the output?

The risk is a wrong answer shipping with nobody having noticed, which can cost far more than the routing decision saved. That is the reason a verification step and an automatic escalation path matter as much as the routing logic itself in any system that claims to save money by mixing models.