LLM API Pricing Comparison: The Five Variables a Rate Table Leaves Out

Every LLM pricing comparison you can find is a table of published per-million-token rates. Those tables are easy to build, easy to read, and mostly useless for predicting what you will actually pay — because the published rate is one of at least five variables that decide a bill, and it is not the one with the largest spread.

This is a guide to comparing prices in a way that survives contact with a real workload. It gives you the variables that matter, a worked example using rates that can be checked against a primary source, and the reason a table of headline numbers keeps misleading people who read it carefully.

Why the headline rate under-determines your bill

A published price is a rate per million tokens, quoted separately for input and output. Four things sit between that rate and your invoice.

Input and output are priced differently, usually by a factor of four or five. Your effective blended rate therefore depends on your own input-to-output ratio, which varies enormously by workload. A classification job sends a lot and returns almost nothing. A drafting job sends a little and returns a lot. Two teams paying the same published rates can have blended costs that differ by three times, and neither of them is being overcharged.

Cache discounts change the arithmetic, not just the total. Where a provider supports prefix caching, repeated context is billed at a fraction of the normal input rate. For agentic workloads that resend a large stable prefix every turn, this is not a rounding adjustment — it is the dominant term. A provider with a higher published rate and effective caching can be cheaper in production than one with a lower rate and none.

Tokenizers differ, so token counts are not comparable across providers. The same paragraph does not become the same number of tokens everywhere. This means a per-token rate is only comparable after you normalise for how many tokens each provider will actually count for your text. Even within one provider's own lineup this can shift: Anthropic notes that its newer tokenizer counts roughly one to one-and-a-third times as many tokens as the older one for the same input, which is why re-baselining is recommended when moving between model generations rather than assuming the count carries over.

Reasoning tokens are billed as output. On models that think before answering, the thinking is generated text and is charged at the output rate whether or not it is displayed to you. Two models with identical published rates can differ substantially in cost if one is more verbose internally.

Batch and asynchronous tiers exist. Work that tolerates delay is commonly discounted — Anthropic's batch tier runs at half cost. If a meaningful share of your volume is not latency-sensitive, the applicable rate for that share is not the one on the front of the pricing page.

A worked example with checkable numbers

Rather than reproduce a multi-provider table that would be stale within weeks and that I cannot verify line by line, here is one provider's lineup in full, so the method has something concrete to operate on. These are Anthropic's first-party rates as documented in Anthropic's own current model reference, cached as of 2026-06-24, in dollars per million tokens:

Read that table the way the previous section suggests and several things appear that a cross-provider comparison would have hidden.

The output rate is five times the input rate throughout, so the input column alone tells you almost nothing. Sonnet 5 is priced below Sonnet 4.6 despite being the newer model, so "newer costs more" is not a rule you can carry between lineups either. And the spread from the cheapest to the most expensive row is ten times — larger than the spread between most competing providers at the same tier, which means choosing the right model within one provider usually matters more than choosing between providers.

Now apply the cache term. Anthropic prices cache reads at one tenth of the base input rate, with a write premium of 1.25x for the short-lived cache and 2x for the long-lived one, and the break-even lands at two to three requests against the same prefix. For a workload that resends a 50,000-token prefix on every turn, the difference between caching and not caching is roughly an order of magnitude on the input side. No cross-provider table has a column for that, and it is bigger than any of the differences such tables do show.

For the full mechanics of the caching side — where breakpoints go, why cache hits silently stop happening, and how to confirm you are getting them — see prompt caching with the Claude API. The single-provider rate detail lives in Claude API pricing.

The metric that actually decides the winner

Cost per token is not the thing you are buying. Cost per completed task is.

A cheaper model that needs three attempts, or that produces output requiring a second pass to fix, is not cheaper. This is the single most common error in LLM cost comparisons, and it is invisible to any methodology that stops at the pricing page. A model one tier up that finishes correctly on the first attempt can be the cheaper option at twice the published rate.

This also reverses a common instinct about capability tiers. Running a more capable model at reduced reasoning effort frequently outperforms running a less capable one at full effort, at comparable or lower total cost — and it keeps you on a single cache namespace, since caches are scoped per model and any multi-model routing scheme forfeits cache reuse across the models it routes between. A cascade that looks cheaper per request can lose more to cache misses than it saves on rates.

How to actually run the comparison

1. Collect a real sample. Twenty to fifty requests representative of your actual traffic, not synthetic prompts. Synthetic samples systematically understate prefix size, which is exactly the variable that caching acts on.
2. Measure token counts per provider, do not estimate them. Use each provider's own token counting endpoint against your sample. This is where the tokenizer difference stops being theoretical.
3. Compute a blended rate from your own I/O ratio. Multiply your measured input tokens by the input rate and your measured output tokens by the output rate. The result is your effective rate, and it will not match the number on anyone's pricing page.
4. Apply the cache term with your real prefix. Split input into cacheable prefix and volatile remainder, then price the prefix at the cache-read rate and add the write premium at whatever rate your traffic pattern implies.
5. Score on completed tasks, not requests. Run the sample end to end, count how many produced usable output without a retry, and divide total spend by that count.
6. Re-run when anything changes. Rates move, models are added, and your own traffic shape drifts. A comparison is a measurement with a date on it, not a fact.

If the comparison is partly about consolidating several providers behind one interface rather than picking one, the architectural side is covered in LLM API gateways, and the integration-level differences between two of the major request shapes in Claude vs GPT API.

Where to get the current numbers

Published rates change, and any figure copied into an article starts aging immediately — including the table above, which is why it carries a date. Treat provider pricing pages as the only authoritative source for current rates, and treat any third-party comparison table, including this one, as a method demonstration rather than a live quote.

Two practical habits follow from that. Check the rate at the time you commit to an architecture, not at the time you first read about it. And build your own cost baseline from your own measured traffic, because that number stays meaningful even when every published rate around it moves.

Frequently asked questions

Which LLM API is cheapest?

The question has no provider-level answer, because the spread between models within a single provider's lineup is typically larger than the spread between providers at the same capability tier. The answerable version is "which model, at which effort setting, with which caching arrangement, is cheapest for my specific traffic" — and that is a measurement, not a lookup.

Can I just compare the per-million-token input rates?

No. Output is priced several times higher than input, so your blended rate depends on your own input-to-output ratio, and cache discounts can move the input side by an order of magnitude. The input column in isolation is the least informative number on a pricing page.

Why do token counts differ between providers for the same text?

Each provider uses its own tokenizer. The same paragraph becomes a different number of tokens depending on which one processes it, so per-token rates are only comparable after you measure the counts your text actually produces on each.

Are thinking or reasoning tokens billed?

Yes, at the output rate, on models that generate them — whether or not the reasoning is shown in the response. A model that reasons more verbosely costs more at the same published rate.

Does a cheaper model always mean a cheaper bill?

No. If it needs more attempts or produces output that requires correction, the cost per completed task can exceed that of a more capable model that succeeds first time. Always score on completed tasks.

Summary

Published per-million-token rates are the starting point of a price comparison, not the substance of one. Input and output are priced differently, tokenizers are not comparable, reasoning is billed as output, caching can move the input side by ten times, and batch tiers discount work that can wait. The number that decides which option is actually cheaper is cost per completed task measured on your own traffic — and that number cannot be read off anyone's pricing page.

ROIBest AI serves an OpenAI-compatible and Anthropic-compatible endpoint, which means the measurement described here can be run against your existing client without rewriting the integration first.