By Input vs Output Tokens: Claude's Cost Gap
Claude output tokens cost five times input. Here is why decoding is slower than prefill, and what that asymmetry does to a real agent bill each month.
Why output tokens cost more than input tokens
Output tokens cost five times what input tokens cost on every Claude model in the current catalogue. The cause is the shape of the computation. Reading a prompt is one pass over the model. Writing a reply is one pass per token, and each pass has to wait for the one before it.
That ratio is the same on every row of the price list, so the model you pick does not change how much of your bill is output. Your workload shape decides that. An agent step that reads 60,000 tokens and answers in 800 spends almost nothing on output. A drafting job that reads 2,000 tokens and writes 12,000 spends almost nothing on input. Both cases are worked below against Anthropic's published August 2026 rates.
Prefill runs once, decoding runs once per token
An inference server handles a request in two phases with very different costs. Prefill reads the prompt. Decoding writes the reply.
Prefill takes the whole prompt at once. Every prompt token enters the network in the same forward pass, so the attention and feed-forward work becomes a small number of large matrix multiplications covering thousands of tokens at a time. One read of the model weights out of memory serves the entire prompt. The accelerator's matrix units stay busy, which means prefill is compute-bound: the limit is how fast the chip can multiply.
Decoding cannot work that way, because token 2 depends on token 1. The token the model just produced becomes part of the input to the next step, so the steps cannot run at the same time. Each output token gets its own forward pass, and each of those passes reads the full set of model weights out of high-bandwidth memory to produce a single token. That makes decoding memory-bound: the limit is how fast weights can be moved, not how fast they can be multiplied. The same weight traffic that consumed a whole prompt during prefill buys you one token during decoding.
Serving systems fight back by batching. Many requests decode together, so one read of the weights produces one token for each request in the batch. That is why decoding is affordable at all. The ceiling is memory again. Every request in flight holds a KV cache (key/value cache, the stored attention state for each token so far), that cache grows with every token generated, and when it fills the accelerator the batch cannot grow any further.
None of that gives you an exact number, and you should not read 5x as a measured hardware ratio. It is a price, set by Anthropic, informed by that asymmetry. What you can check for yourself is the direction, and it takes about a minute.
Measure the input and output gap yourself
Install the tools on any Ubuntu box:
sudo apt update && sudo apt install -y curl jq moreutilsNow stream a short prompt that asks for a long answer, and stamp every line with the time it arrived.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s prefixes each line with the seconds elapsed since the command started. Two things are worth reading off that output. The first content_block_delta line is your time to first token, and all of prefill happened inside it. Every line after that is one small step of decoding, and the stamps keep climbing until message_stop arrives.
Now invert the shape. Put a long document in the prompt and cap the answer at a few tokens.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'The first delta takes longer than it did with the short prompt, because prefill has far more text to read. After it arrives the response is over almost immediately, because only a few tokens are left to decode. Tens of thousands of tokens went in and the clock barely moved. A few hundred came out and the clock ran the whole time.
Every non-streaming response ends with the numbers you are billed on.
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}Log all four fields per request. output_tokens includes extended thinking, so a model that thinks before it answers bills that thinking at the output rate. To price a prompt before you send it, POST /v1/messages/count_tokens accepts the same request body, returns {"input_tokens": N} without running the model, and is free.
What Claude charges per million tokens as of August 2026
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5 (to 31 Aug)",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Sonnet 5 (from 1 Sep)",
"input_usd": 3,
"output_usd": 15,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]The last column is output divided by input, and it reads 5 on every row. Haiku 4.5 bills $1 in and $5 out. Opus 5 bills $5 and $25. Fable 5, the most expensive, bills $10 and $50, and what those Fable 5 rates buy you is worth reading before you write that top row off. Moving up the range multiplies both sides by the same factor, so it changes your total and leaves your input to output split exactly where it was.
Sonnet 5 appears twice because its introductory rate expires. Through 31 August 2026 it bills $2 and $10. From 1 September 2026 the standard rate of $3 and $15 applies, which is 50% more on both sides. Every worked example below uses the August rate.
Rates change, and this page is not where you should check them. claude.com/pricing is the source of truth. What survives a price change is the method.
One caveat the price list does not show. Anthropic's documentation states that Claude 4.7 and later models use a newer tokenizer which produces roughly 30% more tokens for the same text than the tokenizer in Sonnet 4.6 and earlier. Two models compared on price per million tokens alone will flatter the newer one, because the same document is more tokens on it. Compare on cost per finished task, and count your real prompts against the model you actually plan to use. what a million Claude tokens is worth in real text covers what that volume looks like in practice.
When does output start to dominate your bill?
With output priced at 5 times input, the break-even is easy to carry in your head. Call your input tokens I and your output tokens O. Input costs I. Output costs 5 times O. Output passes half of your spend when 5 times O is larger than I, which is a token ratio of 5 input to 1 output.
So if your prompt is more than five times longer than your reply, input is the bigger line item. Below that, output is.
The data behind this chart
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]At 100 to 1, output is 4.8% of the spend, and shaving the prompt is the only work worth doing. At 5 to 1 the two sides are level. At 1 to 6, output is 96.8% and the prompt is a rounding error. Most people guess their own ratio wrong, so pull it from your logs before you optimise anything.
An agent workload: long context in, short answer out
Take one retrieval agent step: 60,000 input tokens of retrieved documents and conversation history, and an 800 token answer. That is 75 to 1, which is normal for anything that reads before it writes.
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]Output is 6.25% of that call on every model, because the ratio is fixed across the whole price list. The call costs $0.32 on Opus 5, $0.128 on Sonnet 5 at the August rate, and $0.064 on Haiku 4.5. Two hundred of those steps a day on Opus 5 is $64 a day.
The lever is obvious once you see the split. Cutting the answer from 800 tokens to 400 saves about 3% of the call. Cutting 20,000 tokens of stale context out of the prompt saves about a third of it. Tightening output length on a read-heavy agent is close to wasted effort. where a coding agent's tokens actually go breaks down what fills that prompt in the first place.
A generation workload: short prompt, long draft
Now flip the shape. A 2,000 token brief, a 12,000 token draft, a ratio of 1 to 6.
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]Output is 96.8% of this bill. Opus 5 costs $0.31 per draft against $0.062 on Haiku 4.5. That five times spread comes almost entirely from the output side, which is exactly where a cheaper model saves you the most.
The last column is the same job through the Batch API, which takes 50% off input and output. Opus 5 drops to $0.155 per draft. Batch returns results within 24 hours instead of immediately, so it fits overnight report generation and bulk classification. It does not fit anything a person is sitting and waiting for.
Model routing pays here in a way it never does on the agent step. If the verbose part of the job is mechanical, reformatting text or expanding an outline you already approved, the cheap model produces those tokens at a fifth of the price. choosing between Opus, Sonnet and Haiku covers where the quality line actually sits.
Caching discounts input, and only input
Prompt caching stores a prefix of your prompt on the server and charges a fraction of the input rate to read it again. As of August 2026 the multipliers are 1.25x the base input rate to write a 5 minute cache, 2x to write a 1 hour cache, and 0.1x to read a hit.
Output is not in that deal. There is no cached output. Every token the model writes is billed at the full output rate, every time, however much of the prompt came back as a cache hit.
Take the same agent step on Opus 5, with 55,000 of the 60,000 input tokens served from a warm cache.
The data behind this chart
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]The call drops from $0.32 to $0.0725. The output line does not move: $0.02 before, $0.02 after. Caching cuts the bill and changes its shape. Output was 6.25% of that call. It is now more than a quarter of it, which changes which lever is worth pulling next.
The first call pays the write. A 5 minute cache write costs 1.25x base input, so it pays for itself after a single hit. A 1 hour write costs 2x, so it needs two. the write and read multipliers, and where caching stops paying works that arithmetic through.
Four levers you control
- Set
max_tokensat your p95 output length, not at the model maximum. - Route the verbose steps to a cheaper model.
- Batch anything nobody is waiting for.
- Delete the instructions that inflate replies.
max_tokens is a hard ceiling, and setting it high costs nothing by itself, because you are billed for tokens produced and never for the ceiling. What a generous cap does is remove the limit on a reply that goes wrong. Pull the output_tokens distribution out of your logs, set the cap a little above the 95th percentile, and handle stop_reason: "max_tokens" in code by continuing the response or retrying. A truncation you detect costs less than a 4,000 token ramble you pay for and throw away. Extended thinking lands in output_tokens too, so set that budget from the same evidence.
Routing works when the expensive part of a step is volume rather than judgement. Keep the strong model on the decision, and hand the typing to something cheaper. Measure the routed version on your own evaluation set first, because a cheap model that needs two attempts costs more than one expensive attempt.
Batching is the only lever that discounts output. 50% off both sides, results inside 24 hours, and anything on a schedule qualifies.
The last lever is the one people skip. Phrases like "be thorough" and "explain your reasoning" set your output length on every call you will ever make. Replace them with the shape you want: "Answer in at most three sentences", or "Return only the JSON object, with no preamble". A system prompt that adds 300 tokens to every reply costs five times what the same 300 tokens cost in the prompt. keeping a running agent's costs under control covers the monitoring side, and whether the API or a flat subscription is cheaper for your pattern is worth settling before you spend a week tuning per-token spend that a subscription would have absorbed.
FAQ
Why do output tokens cost more than input tokens?
Generating them takes far more accelerator time per token. A prompt is processed in one forward pass over the whole thing, so a single read of the model weights covers thousands of tokens and the hardware is limited by multiply throughput. A reply is produced one token at a time, each token needing its own forward pass that reads the full model weights again, so the hardware is limited by memory bandwidth instead. Anthropic prices output at five times input across the entire current catalogue, from Haiku 4.5 up to Fable 5.
Does prompt caching make output tokens cheaper?
No. Prompt caching applies to input only. As of August 2026 a cache read costs 0.1x the base input rate, and cache writes cost 1.25x for the 5 minute duration or 2x for the 1 hour duration. Output is billed at the full rate on every call, whatever the cache did. That is why caching changes the shape of your bill as well as its size: once the input side collapses, output becomes the share worth attacking.
Does a high max_tokens cost me money if the reply comes back short?
No. You are billed for the tokens the model actually produces, so max_tokens is a ceiling and not a reservation. It still matters, because it is the only hard limit on a reply that runs away. Set it a little above the 95th percentile of your observed output_tokens, then handle stop_reason: "max_tokens" in code rather than shipping a silently truncated answer.
How do I find my own input to output token ratio?
Log input_tokens, output_tokens, cache_read_input_tokens and cache_creation_input_tokens from the usage object of every response, then divide the totals over a week. Above 5 input to 1 output, your money is in the prompt, so cache the stable part and trim the rest. Below that, your money is in the reply, so cap its length and move the steps that generate the most of it to a cheaper model or to the Batch API.