Every vendor publishes a price per million tokens, and every engineering team quietly converts that number into a budget it later misses. The gap is not dishonesty. It is that the LLM cost per task depends on four things the price table never shows: how many tokens the model bills for your text, how many of those tokens it thinks before answering, how much of the prompt it reads from cache, and how many turns it takes to finish. This post prices ten current models against three concrete workloads, using list prices read on 9 September 2026, and shows the arithmetic in full so you can re-run it against your own token counts.
Where These 2026 Prices Came From
Prices decay faster than anything else in this post, so here is exactly what was read and when.
Prices read 2026-09-09
Anthropic https://platform.claude.com/docs/en/about-claude/pricing
OpenAI https://developers.openai.com/api/docs/pricing
Google https://ai.google.dev/gemini-api/docs/pricing
xAI https://docs.x.ai/docs/models
DeepSeek https://api-docs.deepseek.com/quick_start/pricing
All figures are USD per million tokens, standard synchronous tier,
public list price, no volume or enterprise discount applied.
Next scheduled re-read: 2026-12-09
Treat any table below as a snapshot rather than a constant. Google, for one, publishes a scheduled increase inside its own table: Gemini 3.8 Flash costs $0.75 per million input tokens “through December 31, 2026” and $1.50 “starting January 1, 2027”. Anyone budgeting a 2027 workload from a 2026 table is already wrong by a factor of two.
What a Per-Token Price Leaves Out
A per-token price tells you the rate, not the bill. The bill is the rate multiplied by the tokens a specific model actually charges for a specific job, and that token count varies by tokenizer, by how much hidden reasoning the model generates, by cache hit rate, and by how many turns the task takes. Cost per task is the only unit that survives all four.
That is why two models with identical sticker prices can differ by 30% on the same corpus, and why the cheapest model on the page is sometimes the most expensive one in production.
The Published Prices, Read on 9 September 2026
These are the raw vendor tables, trimmed to current text models. Prices are per million tokens.
Anthropic
Anthropic is the only vendor of the five that charges a separate premium to write the cache, and the only one that publishes a cache duration.
| Model | Input | 5m cache write | Cache read | Output |
|---|---|---|---|---|
| Claude Fable 5.1 | $10 | $12.50 | $0.25 | $50 |
| Claude Fable 5 | $10 | $12.50 | $1.00 | $50 |
| Claude Opus 5 | $5 | $6.25 | $0.50 | $25 |
| Claude Opus 4.8 | $5 | $6.25 | $0.50 | $25 |
| Claude Sonnet 5 | $2 | $2.50 | $0.20 | $10 |
| Claude Sonnet 4.6 | $3 | $3.75 | $0.30 | $15 |
| Claude Haiku 4.5 | $1 | $1.25 | $0.10 | $5 |
Two footnotes on that table carry real money. First, cache reads cost 0.1x the base input price on every model except Fable 5.1, where they cost 0.025x. Second, the Batch API takes 50% off both input and output, and it stacks with caching.
OpenAI
OpenAI publishes a cached input rate but no cache write premium, so the cache is effectively free to fill.
| Model | Input | Cached input | Output |
|---|---|---|---|
| gpt-6-astra | $10.00 | $1.00 | $50.00 |
| gpt-5.6-sol | $4.00 | $0.40 | $20.00 |
| gpt-5.6-terra | $2.00 | $0.20 | $12.00 |
| gpt-5.6-luna | $0.20 | $0.02 | $1.20 |
| gpt-5.5 | $5.00 | $0.50 | $30.00 |
| gpt-5.4 | $2.50 | $0.25 | $15.00 |
| gpt-5.4-mini | $0.75 | $0.075 | $4.50 |
| gpt-5-nano | $0.05 | $0.005 | $0.40 |
Notice how much the cached-input multiplier has moved between generations. On gpt-4o it is 0.5x; on the 5.x and 6 families it is 0.1x. Consequently, a caching strategy tuned on an older model understates its own savings on a newer one.
Google splits several models by context length and by modality, which makes the headline number the least informative one on the page.
| Model | Input | Cached input | Output |
|---|---|---|---|
| Gemini 3.8 Flash | $0.75 | $0.075 | $3.75 |
| Gemini 3.5 Flash | $1.50 | $0.15 | $9.00 |
| Gemini 3.5 Flash-Lite | $0.30 | not listed | $2.50 |
| Gemini 3.1 Pro Preview (up to 200k) | $2.00 | not listed | $12.00 |
| Gemini 3.1 Pro Preview (over 200k) | $4.00 | not listed | $18.00 |
| Gemini 2.5 Flash-Lite | $0.10 | not listed | $0.40 |
The Flash prices above hold through 31 December 2026 and double on 1 January 2027, per the pricing page itself. Batch requests take 50% off.
xAI and DeepSeek
Both vendors price a second tier that most comparison posts drop entirely: xAI by context length, DeepSeek by clock time.
| Model | Input | Cached input | Output |
|---|---|---|---|
| grok-4.6 (under 200k) | $2.00 | $0.50 | $6.00 |
| grok-4.6 (200k and over) | $4.00 | $1.00 | $12.00 |
| grok-4.3 (under 200k) | $1.25 | $0.20 | $2.50 |
| deepseek-v4-pro (peak) | $1.32 | $0.044 | $3.96 |
| deepseek-v4-pro (off-peak) | $0.66 | $0.022 | $1.98 |
| deepseek-v4-flash (peak) | $0.44 | $0.014 | $1.32 |
DeepSeek’s off-peak rate is half the peak rate, with peak defined as 01:00 to 04:00 and 06:00 to 10:00 UTC on weekdays. For a nightly batch job, therefore, the effective rate is the off-peak one, and the model is roughly three times cheaper than its headline suggests.
Four Multipliers That Decide Your Bill
Sticker price is the first term in the equation. These four are the rest of it.
Tokenizers do not agree on what a token is
The same paragraph is a different number of tokens on every vendor, and only one of them publishes the delta. Anthropic’s pricing page states that Claude 4.7 and later “use a newer tokenizer” that “produces approximately 30% more tokens for the same text”, with the exact increase depending on content and workload shape.
That footnote is worth more than most of the price table. A model at $2 per million input tokens that bills 30% more tokens for your corpus is a $2.60 model against a competitor’s $2.00, and no pricing comparison that assumes equal token counts will ever show it. Every table below therefore reports two figures: an equal-token cost, and a cost adjusted by that published 1.3x ratio for Claude Opus 5 and Sonnet 5.
Reasoning tokens bill as output, invisibly
Hidden thinking is charged at the output rate on every major vendor. OpenAI’s reasoning guide states that reasoning tokens “are not visible via the API” but “still occupy space in the model’s context window and are billed as output tokens”. Google is equally direct: “response pricing is the sum of output tokens and thinking tokens”, and “pricing is based on the full thought tokens the model needs to generate, despite only the summary being output from the API”.
Since output is priced at four to five times input on most models, thinking is the single most expensive thing a model does. Effort controls exist precisely for this reason, and turning one down is usually a bigger lever than switching vendors. For a way to see the damage before the invoice does, our guide to token counting and budget management for LLM apps covers instrumenting usage per request.
Cache reads change the shape of the bill
At a 0.1x read multiplier, a cached prefix costs a tenth of what it cost the first time. In practice this converts a long system prompt from a per-request cost into a near-fixed one, and it is the reason agent workloads are viable at all.
The catch is that the discount only applies to a byte-identical prefix. A timestamp in the system prompt, an unsorted JSON blob, or a tool list that reorders between requests silently drops the hit rate to zero, and nothing in the response shouts about it. Our walkthrough of prompt caching with the Claude API covers breakpoint placement and the invalidation traps that quietly zero out the discount.
Long context flips into a second price tier
Gemini 3.1 Pro doubles from $2.00 to $4.00 per million input tokens above 200k, and its output rate rises from $12.00 to $18.00. Grok 4.6 doubles at the same threshold. Anthropic, by contrast, states that Claude 4.6 and later include the full 1M context window at standard pricing, so a 900k request bills at the same rate as a 9k one.
This matters more than it looks, because context length is not something most applications control tightly. A RAG pipeline that retrieves twelve chunks today retrieves twenty after someone tunes recall, and a workload sitting at 180k tokens crosses into the higher tier without a single code change.
The Cost-per-Task Formula
The whole model fits in one expression:
cost per completed task =
(fresh_input x input_rate
+ cached_input x cache_read_rate
+ cache_writes x cache_write_rate
+ output x output_rate) x tokenizer_ratio / 1,000,000
/ success_rate
Here is that formula as a script you can point at your own numbers. The prices are the ones read on 9 September 2026; replace them when you re-read the vendor pages.
"""Cost per completed task for one LLM workload, from published per-token prices.
Prices are USD per million tokens, read from vendor pricing pages on 2026-09-09.
Replace them before trusting any output from this file.
"""
from dataclasses import dataclass
@dataclass(frozen=True)
class Price:
"""Published rates for one model, in USD per million tokens."""
inp: float
cache_read: float
cache_write: float
out: float
token_ratio: float = 1.0 # tokens billed for the same text, relative to 1.0
@dataclass(frozen=True)
class Workload:
"""Token counts for one attempt at one task."""
fresh_in: int
cached_in: int
cache_write: int
out: int
success_rate: float = 1.0
def cost_per_completed_task(price: Price, work: Workload) -> float:
"""Return USD per finished task, including retries implied by success_rate."""
ratio = price.token_ratio
dollars = (
work.fresh_in * ratio * price.inp
+ work.cached_in * ratio * price.cache_read
+ work.cache_write * ratio * price.cache_write
+ work.out * ratio * price.out
) / 1_000_000
return dollars / work.success_rate
PRICES = {
"Claude Opus 5": Price(5.00, 0.50, 6.25, 25.00, token_ratio=1.30),
"Claude Sonnet 5": Price(2.00, 0.20, 2.50, 10.00, token_ratio=1.30),
"Claude Haiku 4.5": Price(1.00, 0.10, 1.25, 5.00),
"gpt-6-astra": Price(10.00, 1.00, 0.00, 50.00),
"gpt-5.6-sol": Price(4.00, 0.40, 0.00, 20.00),
"gpt-5.6-terra": Price(2.00, 0.20, 0.00, 12.00),
"gpt-5.6-luna": Price(0.20, 0.02, 0.00, 1.20),
"Gemini 3.8 Flash": Price(0.75, 0.075, 0.00, 3.75),
"grok-4.6": Price(2.00, 0.50, 0.00, 6.00),
"deepseek-v4-pro": Price(1.32, 0.044, 0.00, 3.96),
}
if __name__ == "__main__":
# One coding-agent ticket: 14 tool-calling turns, context growing 4,300 tokens a turn.
agent_task = Workload(fresh_in=60_200, cached_in=391_300, cache_write=60_200, out=44_800)
ranked = sorted(PRICES.items(), key=lambda item: cost_per_completed_task(item[1], agent_task))
for name, price in ranked:
print(f"{name:<18} ${cost_per_completed_task(price, agent_task):.4f}")
The token_ratio field is doing the quiet work here. It is the only place in a cost model where a vendor’s tokenizer shows up, and leaving it at 1.0 for every model is the most common way these comparisons go wrong.
Three Workloads, Priced End to End
Each workload below states its token assumptions in full, because a cost table without its assumptions is a horoscope. None of these figures is a benchmark result. They are arithmetic on published prices, and the numbers move the moment your token counts differ. The Claude Opus 5 and Sonnet 5 rows carry the published 1.3x tokenizer ratio, since both run the newer tokenizer; Claude Haiku 4.5 predates it and so carries none.
Support ticket triage, at scale
Assumptions per ticket: 2,000 input tokens, of which 1,700 are a stable system prompt plus policy document and 300 are the ticket itself; 250 output tokens; no extended reasoning. In the cached column, the 1,700-token prefix is written once per 100 tickets and read on the rest. The monthly column assumes 300,000 tickets, roughly 10,000 a day.
| Model | No caching | With caching | Cached and batched | Monthly, cached |
|---|---|---|---|---|
| gpt-5.6-luna | $0.00070 | $0.00039 | $0.00020 | $118 |
| Gemini 3.8 Flash | $0.00244 | $0.00129 | $0.00064 | $387 |
| deepseek-v4-pro | $0.00363 | $0.00146 | $0.00073 | $438 |
| Claude Haiku 4.5 | $0.00325 | $0.00174 | $0.00087 | $522 |
| grok-4.6 | $0.00550 | $0.00295 | $0.00147 | $885 |
| Claude Sonnet 5 | $0.00845 | $0.00453 | $0.00226 | $1,358 |
| gpt-5.6-sol | $0.01300 | $0.00688 | $0.00344 | $2,064 |
| Claude Opus 5 | $0.02113 | $0.01132 | $0.00566 | $3,395 |
Caching alone cuts this workload roughly in half, and batching halves it again. In other words, the same model on the same tickets spans a 4x range depending only on how the calls are made. Anyone comparing vendors before turning on caching is comparing the wrong thing. If the work tolerates a delay, the OpenAI Batch API is the cheapest configuration change available.
RAG answers over retrieved chunks
Assumptions per answer: 6,000 cached tokens of instructions and tools, 22,000 fresh tokens of retrieved passages, 600 visible output tokens plus 1,200 reasoning tokens, billed together as 1,800 output tokens.
| Model | Cost per answer | Per 10,000 answers |
|---|---|---|
| gpt-5.6-luna | $0.0067 | $67 |
| Gemini 3.8 Flash | $0.0237 | $237 |
| Claude Haiku 4.5 | $0.0317 | $317 |
| deepseek-v4-pro | $0.0364 | $364 |
| grok-4.6 | $0.0578 | $578 |
| gpt-5.6-terra | $0.0668 | $668 |
| Claude Sonnet 5 | $0.0824 | $824 |
| gpt-5.6-sol | $0.1264 | $1,264 |
| Claude Opus 5 | $0.2059 | $2,059 |
| gpt-6-astra | $0.3160 | $3,160 |
Retrieved passages are the dominant term, and they are the one part of the prompt that cannot be cached, because they change with every query. Cutting retrieval from twelve chunks to eight therefore saves more than any vendor switch inside the same tier. The chunking strategies guide is a cost document as much as a quality one.
One coding-agent ticket
Assumptions: 14 tool-calling turns; context grows by 4,300 tokens per turn, so total billed input is 451,500 tokens; 60,200 of those are new content, the remaining 391,300 are cache reads; 3,200 output tokens per turn including hidden thinking, so 44,800 output tokens in total.
| Model | Equal tokens | Tokenizer-adjusted |
|---|---|---|
| gpt-5.6-luna | $0.0736 | $0.0736 |
| Gemini 3.8 Flash | $0.2425 | $0.2425 |
| deepseek-v4-pro | $0.2741 | $0.2741 |
| Claude Haiku 4.5 | $0.3986 | $0.3986 |
| grok-4.6 | $0.5848 | $0.5848 |
| gpt-5.6-terra | $0.7363 | $0.7363 |
| Claude Sonnet 5 | $0.7972 | $1.0363 |
| gpt-5.6-sol | $1.2933 | $1.2933 |
| Claude Opus 5 | $1.9929 | $2.5908 |
| gpt-6-astra | $3.2333 | $3.2333 |
The tokenizer adjustment reorders the table. On equal tokens, Claude Sonnet 5 looks cheaper than gpt-5.6-terra; with the published 1.3x ratio applied, it costs 41% more. Whether that ratio holds for your corpus is an empirical question, which is exactly the point: it is a question, and treating it as settled at 1.0 is a choice nobody makes deliberately.
Is the Cheapest LLM API Also the Cheapest per Task?
Often yes, and the popular counter-argument is weaker than it sounds. The retry story says a cheap model fails, retries, and ends up costing more. Run the arithmetic, though, and the break-even is brutal. Against Claude Opus 5 finishing 90% of coding tickets, here is the success rate each cheaper model needs to match it on cost per completed task.
| Model | Cost per attempt | Break-even success rate |
|---|---|---|
| gpt-5.6-luna | $0.0736 | 2.6% |
| Gemini 3.8 Flash | $0.2425 | 8.4% |
| deepseek-v4-pro | $0.2741 | 9.5% |
| Claude Haiku 4.5 | $0.3986 | 13.8% |
| grok-4.6 | $0.5848 | 20.3% |
| Claude Sonnet 5 | $1.0363 | 36.0% |
| gpt-5.6-sol | $1.2933 | 44.9% |
A model 35 times cheaper needs to succeed only one time in 38 to win on tokens. That result contradicts the tidy narrative, so here it is stated plainly: retries alone almost never justify a premium model. What justifies one is everything the token bill does not contain, which the next two sections cover.
When Turn Count Beats Token Price
Token price is linear; turn count is not. Because each turn resends the conversation so far, total billed input grows with the square of the turn count. A weaker model that needs 24 turns instead of 14 on the same ticket therefore bills 2.9 times the input, not 1.7 times.
| Model | 14 turns | 24 turns | Increase |
|---|---|---|---|
| gpt-5.6-luna | $0.0736 | $0.1365 | 1.9x |
| Gemini 3.8 Flash | $0.2425 | $0.4544 | 1.9x |
| Claude Haiku 4.5 | $0.3986 | $0.7349 | 1.8x |
| Claude Sonnet 5 | $1.0363 | $1.9107 | 1.8x |
| Claude Opus 5 | $2.5908 | $4.7767 | 1.8x |
The multiplier is nearly identical across models, which is the useful finding: turn count is a workload property, not a vendor property, and it scales everyone’s bill the same way. Cutting an agent from 24 turns to 14, by giving it better tools or a tighter task description, saves about 45% regardless of which model runs it.
Meanwhile the non-token line items are the ones nobody forecasts. Anthropic charges $10 per 1,000 web searches and $0.08 per session-hour for managed agent runtime, and both are invisible in a per-token comparison. A long-running agent that searches often can spend more on searches than on thinking.
What a Migration Actually Saves
Consider a mid-sized SaaS product running two LLM workloads: a support triage pipeline at roughly 10,000 tickets a day, and an internal coding agent a team of eight uses through the week. The team is on a flagship model for both, because that is what the prototype used, and the monthly invoice has become the second-largest line in the infrastructure budget.
Working the numbers above in order, the cheapest wins come first and none of them involve changing vendors. Turning on prompt caching for the triage prefix halves that workload. Moving it to the batch endpoint, since a ticket summary written four hours later is still useful, halves it again. Only then does model choice enter, and dropping triage from a flagship to a small model changes the monthly figure by roughly an order of magnitude, from thousands to hundreds.
The coding agent is the opposite case. It is a handful of tickets a day, so its token bill is small in absolute terms, and an engineer waiting on a weaker model that needs ten more turns costs more in salary than the entire model bill saves. Notably, the right decision in the same company points in opposite directions for the two workloads, which is what makes a single company-wide model policy so expensive.
When to Optimize for LLM Cost per Task
- Your workload is high volume and low variance, such as classification, extraction, triage, or summarization at thousands of calls a day
- The token bill is already a visible line in the budget rather than a rounding error
- Latency is not user-facing, which makes batch endpoints and off-peak rates available
- A stable prompt prefix makes up most of the input, so caching has something to bite on
- You can measure task success, because cost per completed task is meaningless without it
When NOT to Optimize for LLM Cost per Task
- The workload is a handful of calls a day, where engineering time to optimize exceeds a year of savings
- A human waits on every response, since latency and quality dominate the economics
- Task success is unmeasured, in which case a cheaper model is a quality change disguised as a cost change
- The output feeds an irreversible action, such as a payment or a customer-visible email, where a failure costs more than the entire model bill
- You are still finding product-market fit and the prompt changes weekly, which invalidates every cache and every measurement
Common Mistakes with LLM Cost per Task
- Comparing vendors on the price table before turning on caching or batching, which are worth more than most vendor switches
- Assuming equal token counts across vendors, and so missing a documented 30% difference
- Forecasting from visible output tokens while hidden reasoning tokens bill at the same output rate
- Modelling a fixed context length when retrieval or conversation growth pushes requests into a higher long-context tier
- Ignoring per-call line items such as web searches, container runtime, and data residency multipliers
- Averaging a monthly invoice across all traffic instead of attributing it per route, which hides the one endpoint spending most of the money
- Treating a scheduled price change as far away, when Gemini Flash rates double on 1 January 2027
What These Tables Do Not Include
Every number above is arithmetic on list prices, and several real costs sit outside it. Quality is entirely absent: nothing here measures whether a model finishes the task, and a cheaper model that ships a bug costs more than any table can express. Rate limits are absent too, and a cheap model you cannot get capacity on has an infinite effective price.
Volume discounts, committed-use agreements and enterprise terms are excluded by design, since they are negotiated rather than published. Provisioned throughput and self-hosting are also out of scope, though at sustained high volume they change the answer completely; self-hosted serving with vLLM is where that comparison starts. Finally, the token counts in the three workloads are assumptions, not measurements. They are stated so you can replace them, and replacing them is the entire point of the script.
Conclusion
Per-token prices are the input to a cost model, not the model itself. The LLM cost per task that actually lands on your invoice is that rate multiplied by a tokenizer you did not choose, hidden reasoning you cannot see, a cache hit rate you probably have not measured, and a turn count that grows quadratically. Work those four terms in order and the cheapest wins usually arrive before any vendor switch does.
Start by instrumenting one route: log input, cached, and output tokens per request for a week, then put your real numbers into the script above. Once you have a per-task figure you trust, run a router such as LiteLLM so switching models for a single route is a config change rather than a migration. Re-read the vendor pages quarterly, because every price in this post carries a date for a reason.
