Why Claude Output Tokens Cost 5x More Than Input

Why output tokens cost more than input tokens

Output tokens dey cost five times pass input tokens for every Claude model wey dey the current catalogue. Na the way computation dey happen cause am. Model dey read prompt with one pass. But when e dey write reply, e dey make one pass for every token, and each pass must wait for the one before am.

That ratio dey the same for every row for the price list, so the model wey you choose no change how much of your bill go be output. Na the shape of your workload decide that. An agent step wey read 60,000 tokens and answer with 800 go spend almost nothing for output. A drafting job wey read 2,000 tokens and write 12,000 go spend almost nothing for input. We go work through both cases below against Anthropic's published rates, checked on 9 October 2026.

Prefill dey run once, decoding dey run once for each token

Inference server dey handle request for two phases wey get very different cost. Prefill dey read prompt. Decoding dey write reply.

Prefill dey take the complete prompt at once. Every prompt token dey enter the network for the same forward pass, so attention and feed-forward work become small number of large matrix multiplications wey cover thousands of tokens at one time. One read of model weights from memory dey serve the complete prompt. Accelerator matrix units dey stay busy, so prefill na compute-bound: the limit na how fast the chip fit multiply.

Decoding no fit work like that because token 2 depend on token 1. The token wey model just produce become part of input for the next step, so the steps no fit run at the same time. Every output token get its own forward pass, and each pass dey read the complete set of model weights from high-bandwidth memory to produce one token. That make decoding memory-bound: the limit na how fast weights fit move, no be how fast dem fit multiply. The same weight traffic wey process one complete prompt during prefill dey produce only one token during decoding.

Serving systems dey reduce this problem with batching. Many requests dey decode together, so one read of the weights dey produce one token for every request inside the batch. Na why decoding dey affordable at all. The limit still na memory. Every request wey dey run dey hold KV cache (key/value cache, the stored attention state for every token so far). That cache dey grow with every token wey dem generate, and when e fill the accelerator, the batch no fit grow again.

All this no give you exact number, and you no suppose read 5x as measured hardware ratio. Na price wey Anthropic set, based on this difference. Wetin you fit check by yourself na the direction, and e go take about one minute.

Measure the input and output gap by yourself

Install the tools for any Ubuntu box:

sudo apt update && sudo apt install -y curl jq moreutils

Now stream one short prompt wey dey ask for long answer, then put the time wey each line arrive for am.

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 dey put the seconds wey don pass since command start for front of each line. Two things dey important for this output. The first content_block_delta line na your time to first token, and all the prefill happen inside am. Every line after that na one small decoding step, and the timestamps keep increasing until message_stop show.

Now turn the shape around. Put one long document inside the prompt and limit the answer to 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 take longer than when short prompt dey, because prefill get plenty more text to read. After e arrive, response finish almost immediately, because na only few tokens remain to decode. Tens of thousands of tokens enter, but the clock barely move. Few hundred come out, and the clock run throughout.

Every non-streaming response dey end with the numbers wey dem use bill you.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Log all four fields for each request. output_tokens include thinking tokens, so if model think before e answer, dem bill that thinking for output rate. To price prompt before you send am, POST /v1/messages/count_tokens accept the same request body, return {"input_tokens": N} without running the model, and e free. E no be the only part of the API wey cost nothing, and which parts of the Claude API dem no dey bill you for worth checking before you budget your first project.

Wetin Claude dey charge per million tokens as of October 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10,
    "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 na output divided by input, and e read 5 for every row. Haiku 4.5 dey charge $1 for input and $5 for output. Opus 5 dey charge $5 and $25. Fable 5, wey cost pass, dey charge $10 and $50, and wetin those Fable 5 rates fit buy you worth reading before you dismiss that top row. As you move up the range, both sides multiply by the same factor. So your total changes, but the split between input and output stay exactly as e be.

Sonnet 5 dey charge $2 for input and $10 for output. Anthropic launch am with that rate as introductory pricing until 31 August 2026. The price suppose rise to $3 and $15 on 1 September. But on 10 August 2026, Anthropic make $2 and $10 the standard price. The increase no happen, so the rate for every worked example below na the rate wey you pay today.

Anthropic don release newer models since this page first go live. Now claude.com/pricing list the four models above as legacy models wey still dey available. The new ones keep the same 5x ratio. Opus 5.5 dey charge $4 and $20, Sonnet 5.5 dey charge $2 and $10, Fable 5.1 dey charge $10 and $50, while Haiku 5.5 dey charge $0.10 and $0.50 for prompts up to 100,000 tokens. The rate rise to $0.50 and $2.50 above that. Every Opus 5 figure below na 20% lower for Opus 5.5.

Rates dey change, and you no suppose check dem for this page. claude.com/pricing na the source of truth. Wetin remain after price change na the method.

One caveat wey the price list no show. Anthropic documentation talk say Claude 4.7 and later models dey use newer tokenizer. E dey produce roughly 30% more tokens for the same text than the tokenizer for Sonnet 4.6 and earlier. If you compare two models only by price per million tokens, the newer one go look better than e really be, because the same document become more tokens for that model. Compare cost per finished task instead, and count your real prompts against the model wey you actually plan to use. The same problem dey between providers, because their tokenizers differ from each other by more than that. So costing one real job for both Claude and ChatGPT go tell you more than putting the two rate cards side by side. wetin one million Claude tokens worth for real text explain wetin that volume look like for practice.

When output dey start to dominate your bill?

Since output price na 5 times input price, you fit remember the break-even point easily. Make we call your input tokens I and output tokens O. Input cost na I. Output cost na 5 times O. Output pass half of your total spend when 5 times O bigger than I. This mean say token ratio na 5 input to 1 output.

So if your prompt long pass your reply more than five times, input na the bigger cost item. Below that point, output na the bigger one.

[
  {
    "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
  }
]

For 100 to 1, output na 4.8% of the total spend, so na only prompt reduction worth doing. For 5 to 1, both sides cost the same. For 1 to 6, output na 96.8%, and prompt cost almost no longer matter. Many people dey guess their own ratio wrongly. Check your logs first before you optimise anything.

Agent workload: long context enter, short answer commot

Make one retrieval agent step: retrieved documents and conversation history get 60,000 input tokens, while the answer get 800 tokens. That one na 75 to 1, and na normal for anything wey dey read before e write.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5",
    "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 na 6.25% of that call for every model, because the ratio no change across the whole price list. The call cost $0.32 for Opus 5, $0.128 for Sonnet 5, and $0.064 for Haiku 4.5. Two hundred of those steps every day for Opus 5 na $64 per day.

The main lever dey obvious once you see the split. If you cut the answer from 800 tokens to 400, you save about 3% of the call. If you remove 20,000 tokens of stale context from the prompt, you save about one-third of the cost. Reducing output length for an agent wey mostly dey read na almost wasted effort. where a coding agent tokens dey really go explain wetin dey fill that prompt from the start.

A generation workload: short prompt, long draft

Now make we turn the shape around. Na 2,000 token brief and 12,000 token draft, with ratio of 1 to 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5",
    "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 na 96.8% of this bill. Opus 5 cost $0.31 per draft, compared with $0.062 for Haiku 4.5. Most of that five-times difference come from output, and na exactly there cheaper model dey save you the most money.

The last column show the same job through Batch API, wey cut input and output cost by 50%. Opus 5 come down to $0.155 per draft. Batch return result within 24 hours instead of immediately, so e fit work for overnight report generation and bulk classification. E no fit work for anything wey person dey wait for directly.

Model routing dey pay for this workload, unlike the agent step. If the verbose part na mechanical work, like reformatting text or expanding outline wey you don already approve, the cheap model go produce those tokens at one-fifth of the price. choosing between Opus, Sonnet and Haiku explain where the actual quality line dey.

Caching dey discount input, and na input only

Prompt caching dey store one prefix of your prompt for server, then e charge small fraction of input rate when e read am again. As of 9 October 2026, multipliers na 1.25x of base input rate to write 5 minute cache, 2x to write 1 hour cache, and 0.1x to read one cache hit for the models wey this page price. The newest models dey read cache hits for less: 0.05x for Opus 5.5 and Sonnet 5.5, and 0.025x for Fable 5.1.

Output no dey inside this arrangement. No cached output dey. Every token wey model write dey billed at full output rate every time, no matter how much of the prompt return as cache hit.

Use the same agent step for Opus 5, with 55,000 of the 60,000 input tokens served from warm cache.

[
  {
    "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 drop from $0.32 to $0.0725. The output line no move: $0.02 before, $0.02 after. Caching dey cut the bill and change the way e dey break down. Output be 6.25% of that call before. Now e pass one quarter of am, and this change which lever make sense to pull next.

The first call dey pay for the write. 5 minute cache write cost 1.25x base input, so one cache hit don cover the cost. 1 hour write cost 2x, so e need two hits. the write and read multipliers, and where caching stops paying work through that arithmetic.

Four levers wey you fit control

1. Set max_tokens for your p95 output length, no be for the model maximum.
2. Route the verbose steps go cheaper model.
3. Batch anything wey nobody dey wait for.
4. Delete instructions wey dey make replies longer.

max_tokens na hard ceiling. Setting am high no cost anything by itself, because dem dey bill you for tokens wey dem produce, not for the ceiling. Generous cap just remove the limit from reply wey go wrong. Pull the output_tokens distribution from your logs, set the cap small above the 95th percentile, and handle stop_reason: "max_tokens" for code by continuing the response or retrying. Truncation wey you detect dey cost less than 4,000 token ramble wey you pay for then throw away. Thinking dey enter output_tokens too and e count against max_tokens, so use the same evidence size the cap. For models with adaptive thinking, reduce the effort level if thinking dey chop off the reply.

Routing dey work when volume, not judgement, na the expensive part of a step. Keep the strong model for the decision, then give the typing work to something cheaper. First measure the routed version with your own evaluation set, because cheap model wey need two attempts fit cost pass one expensive attempt.

Batching na the only lever wey dey reduce output price. 50% off for both sides, results within 24 hours, and anything wey dey follow schedule qualify.

The last lever na the one wey people dey skip. Phrases like "be thorough" and "explain your reasoning" set your output length for every call wey you go ever make. Replace dem with the exact shape wey you want: "Answer in at most three sentences", or "Return only the JSON object, with no preamble". System prompt wey dey add 300 tokens to every reply cost five times wetin the same 300 tokens cost for the prompt. keep running agent cost under control cover the monitoring side, and whether API or flat subscription cheaper for your pattern good make you settle am before you spend one week tuning per-token spend wey subscription for don absorb. For one developer, the matter mostly depend on whether Claude Pro's $20 per month and the usage limits wey come with am cover the work wey you for otherwise dey meter. If you don already dey hit those limits mid-session, work out which window you dey wait for come first, because the fix from there fit be smaller model, lighter context, extra usage credits, or moving that work go metered API. If metered API later prove say e cheaper home for that work, drop to smaller plan or cancel am leave the month wey you don already pay for intact, so switching no cost you anything as you dey leave. If the plan wey you dey compare with Pro na ChatGPT own, instead of metered API, the two subscription ladders priced side by side show which one cheaper for coding work. If na team dey ask the question instead of one developer, note say Claude Enterprise combine per-seat fee with tokens metered at these same API rates, so every lever for this page still apply to the metered half of that bill.

FAQ

Why output tokens dey cost pass input tokens?

To generate dem dey need plenty more accelerator time for each token. Dem process prompt for one forward pass over the whole thing, so one read of the model weights fit cover thousands of tokens, and na multiply throughput dey limit the hardware. Dem produce reply one token at a time. Each token need im own forward pass wey go read the full model weights again, so na memory bandwidth dey limit the hardware. Anthropic price output five times pass input across the whole current catalogue, from Haiku 5.5 reach Fable 5.1.

Prompt caching dey make output tokens cheaper?

No. Prompt caching na for input only. As of 9 October 2026, cache read cost 0.1x of the base input rate for most models (0.05x for Opus 5.5 and Sonnet 5.5, 0.025x for Fable 5.1), and cache writes cost 1.25x for the 5 minute duration or 2x for the 1 hour duration. Dem bill output at the full rate for every call, no matter wetin the cache do. Na why caching dey change the shape of your bill as well as the size: once the input side reduce well well, output become the part wey worth reducing.

High max_tokens fit make me pay money if the reply come back short?

No. Dem bill you for the tokens wey model actually produce, so max_tokens na ceiling, e no be reservation. E still matter because na the only hard limit for reply wey fit continue too long. Set am small above the 95th percentile of your observed output_tokens, then handle stop_reason: "max_tokens" for code instead of shipping answer wey truncate silently.

How I fit 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 for every response, then divide the totals over one week. If input-to-output ratio pass 5 to 1, na prompt dey use your money, so cache the stable part and reduce the rest. If e fall below that, na reply dey use your money, so limit im length and move the steps wey generate most of am go cheaper model or the Batch API.