How to Read LLM Pricing Tables Without Getting Burned
Token pricing looks simple and hides at least six things that change what you actually pay. A practical guide to comparing model costs on equal footing.
Every provider publishes two numbers — dollars per million input tokens, dollars per million output tokens — and those two numbers are genuinely useful. They are also not sufficient to predict your bill, and the gap between the headline and the invoice is where most budget surprises live.
Here is what the table does not tell you.
1. Output costs five to six times input
This is the first thing to internalise, because it inverts the obvious optimisation. Teams reflexively trim prompts and leave responses alone. It should be the other way round.
Look at any current price list and the pattern is consistent: a model at $2 per million input tokens will charge $10–12 on output. If your workload generates long responses, the output column dominates the bill and the input column is close to noise.
The practical consequence: request structured output instead of prose, set explicit length limits, and stop asking the model to restate the question before answering.
2. Monthly totals, not unit prices
A 10x difference in per-token price is irrelevant at a thousand requests a month and decisive at ten million. Compare the number you will actually be invoiced.
The arithmetic is simple enough to do in your head:
monthly cost = (requests × input tokens / 1M × input price)
+ (requests × output tokens / 1M × output price)As a rough conversion, one token is about four characters of English, so 1,000 tokens is roughly 750 words. If you would rather not do this by hand, the cost calculator does it across every model at once.
3. Reasoning models bill their thinking
This is the biggest change since this article was first written. Nearly every frontier model now generates an internal chain of thought before answering, and those tokens bill at the output rate.
The effect is that sticker price stops predicting cost. A model at $20 per million output that solves your task in 2,000 tokens costs $0.04. A model at $6 that burns 15,000 tokens thinking costs $0.09 — more than twice as much, at less than a third of the advertised price.
Token efficiency between frontier models genuinely varies by multiples on the same task, and providers now compete on it explicitly. More on how this works.
4. Cached input is a different price
Cached input typically bills at about a tenth of the base input rate. For anything that resends a stable prompt each turn — chat, agents, coding assistants — this is usually the single largest saving available.
The catch is that the cached prefix must be byte-identical. A timestamp or session ID interpolated near the top of your system prompt invalidates the cache on every single request, which is a common and expensive mistake. Put the stable content first and anything dynamic at the end.
5. Long context can reprice the whole request
Several providers apply a higher rate once a prompt crosses a threshold — and it applies to the entire request, not just the tokens above the line. One current flagship charges $2 per million input under 200K tokens and $4 above it. Another raises rates past 272K.
A prompt that grows from 195K to 205K tokens therefore doubles in cost with no visible change in behaviour. If you operate anywhere near a threshold, treat prompt length as a metric you monitor.
This is also why “just use the million-token window” rarely turns out to be the cheap answer.
6. Batch is half price
Batch APIs are consistently 50% off across major providers, in exchange for a delayed and non-guaranteed completion window. Anything that is not blocking a user should default to batch: nightly enrichment, embeddings backfill, evals, bulk classification.
Treating batch as an emergency cost lever rather than the default for background work leaves money on the table every month.
Prices move now
One more thing that has changed. Provider pricing used to be reasonably stable; in 2026 it became a competitive weapon. One budget tier fell 80% in a single day in July. A flagship dropped over 20% six weeks later, framed explicitly as promotional with an expiry date.
Two consequences. First, check the date on any price you read — including on this site, which is why every table here carries a verification date. Comparison pages that scraped a launch announcement can be wrong by a factor of five. Second, architectural savings like caching and routing are more durable than betting on the next price cut, because they compound with it rather than being erased by it.
A workable checklist
Before committing to a model:
- Estimate monthly input and output token volume separately.
- Multiply by current prices and compare monthly totals.
- If it is a reasoning model, run your real task and measure actual output tokens rather than trusting an estimate.
- Check for a long-context threshold near your typical prompt size.
- Work out what share of your input is cacheable.
- Move anything asynchronous to batch.
- Confirm the price on the provider’s own page before signing anything.
That last step matters more than it sounds. Every aggregator, this one included, is a snapshot.