Why Claude Output Tokens Cost 5x More Than Input

Why output tokens dey cost pass input tokens

Output tokens cost five times wetin input tokens cost for every Claude model wey dey the current catalogue. Na the way computation dey happen cause am. Reading prompt na one pass through the model. Writing reply na one pass for every token, and each pass must wait for the one before am.

That ratio na the same for every row for the price list, so the model wey you pick no change how much of your bill go come from output. Na the shape of your workload decide that. Agent step wey read 60,000 tokens and answer with 800 spend almost nothing for output. Drafting job wey read 2,000 tokens and write 12,000 spend almost nothing for input. We go work both cases below with Anthropic published August 2026 rates.

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 the prompt. Decoding dey write the reply.

Prefill dey take the complete prompt at once. Every prompt token dey enter the network for the same forward pass, so the attention and feed-forward work become small number of large matrix multiplications wey cover thousands of tokens at a time. One read of the model weights from memory dey serve the whole prompt. The 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 the 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 full model weights from high-bandwidth memory to produce one token. This 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 whole prompt during prefill dey produce only one token during decoding.

Serving systems dey reduce the 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 ceiling 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 system generate, and when e fill the accelerator, the batch no fit grow again.

None of this give you exact number, and you no suppose treat 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 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 stamp every line with the time e arrive.

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 every line. Two things dey important for that 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 stamps go keep increase until message_stop show.

Now reverse the shape. Put one long document for the prompt, then 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 much more text to read. After e arrive, response don finish almost immediately, because 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 end with the numbers wey dem use calculate your bill.

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

Log all four fields for every request. output_tokens include extended thinking, so if model think before e answer, dem bill that thinking with 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 never bill you for dey worth checking before you budget your first project.

Claude dey charge how much per million tokens as of August 2026

[
  {
    "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 na output divided by input, and e dey show 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 worth reading before you dismiss that top row. As you move up the range, both sides multiply by the same factor. So your total cost change, but the input-to-output split remain exactly the same.

Sonnet 5 dey appear two times because the introductory rate get expiration date. Up to 31 August 2026, e dey charge $2 and $10. From 1 September 2026, the standard rate of $3 and $15 go apply. This one na 50% more for both sides. Every worked example below use the August rate.

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

One caveat wey the price list no show. Anthropic documentation talk say Claude 4.7 and later models use newer tokenizer. This tokenizer 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, you go make the newer one look better than e be. The same document go contain 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. wetin one million Claude tokens mean for real text explain wetin that volume look like for practice.

Wen output start to dey take bigger part of 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 your 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 token ratio na 5 input to 1 output.

So, if your prompt long pass your reply by more than five times, input na the bigger cost item. If e no reach that ratio, 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 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 matter. Plenty people dey estimate their own ratio wrongly, so first get am 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 na 75 to 1, and e 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 (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 na 6.25% of that call for every model, because the ratio dey fixed across the whole price list. The call cost $0.32 for Opus 5, $0.128 for Sonnet 5 at the August rate, 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 clear once you see the split. If you cut the answer from 800 tokens to 400, e go save about 3% of the call. If you cut 20,000 tokens of stale context from the prompt, e go save about one-third of the cost. Tightening output length for a read-heavy agent nearly na wasted effort. where a coding agent's tokens actually go breaks down wetin dey fill that prompt for the first place.

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 (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 na 96.8% of this bill. Opus 5 cost $0.31 for each draft, compared with $0.062 for Haiku 4.5. This five-times difference dey come almost entirely from the output side. Na exactly there cheaper model fit save you the most money.

The last column show this same job through Batch API, wey reduce input and output cost by 50%. Opus 5 drop to $0.155 for each draft. Batch dey return results 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.

Model routing dey useful here in a way wey e no dey for the agent step. If the verbose part of the job na mechanical work, like reformatting text or expanding outline wey you don already approve, the cheap model go produce those tokens for one-fifth of the price. how to choose between Opus, Sonnet and Haiku cover where the real quality line dey.

Caching dey reduce input cost, and na only input

Prompt caching dey store one prefix of your prompt for server, then charge small part of input rate when e read am again. As of August 2026, the multipliers na 1.25x of the base input rate to write 5 minute cache, 2x to write 1 hour cache, and 0.1x to read when cache hit.

Output no dey inside that arrangement. Cached output no dey. Every token wey model write dey bill at the full output rate every time, no matter how much of the prompt come back 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 cost drop from $0.32 to $0.0725. The output line no change: $0.02 before, $0.02 after. Caching reduce the bill and change the way e dey split. Output be 6.25% of that call. Now e pass one quarter of the total, and that 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 make am pay for itself. 1 hour write cost 2x, so e need two hits. the write and read multipliers, and where caching stops paying explain the calculation and where caching stop making financial sense.

Lever 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 long.

max_tokens na hard ceiling. Setting am high no cost anything by itself, because dem dey bill you for tokens wey dem produce, and never for the ceiling. Wetin generous cap dey do na to 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 go cost less than 4,000-token ramble wey you pay for and throw away. Extended thinking dey enter output_tokens too, so set that budget from the same evidence.

Routing dey work when volume, no be judgement, na the expensive part of a step. Keep the strong model for the decision, then give the typing to something cheaper. Measure the routed version with your own evaluation set first, because cheap model wey need two attempts go cost more than 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 on schedule qualify.

The last lever na the one wey people dey skip. Phrases like "be thorough" and "explain your reasoning" dey set your output length for every call wey you go ever make. Replace dem with the 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 go cost five times wetin the same 300 tokens cost for the prompt. keep cost of running agent under control cover the monitoring side, and whether API or flat subscription cheaper for your pattern worth settling 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 $20 per month and the usage limits wey come with am cover the work wey you for otherwise meter. If you dey already 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 turn out to be cheaper place for that work, move to smaller plan or cancel am leave the month wey you don already pay for intact, so switching no cost you anything as you comot. 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 much more accelerator time for each token. Dem dey process prompt for one forward pass over everything, so one read of model weights fit cover thousands of tokens, and na multiply throughput dey limit the hardware. Dem dey produce reply one token at a time, and every token need im own forward pass wey go read the full model weights again, so na memory bandwidth dey limit the hardware. Anthropic dey price output five times pass input across the whole current catalogue, from Haiku 4.5 reach Fable 5.

Prompt caching dey make output tokens cheaper?

No. Prompt caching na only for input. As of August 2026, cache read dey cost 0.1x of the base input rate, while cache writes dey cost 1.25x for the 5 minute duration or 2x for the 1 hour duration. Dem dey 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 don reduce sharply, output become the part wey make sense to reduce.

High max_tokens fit make me spend money if the reply short?

No. Dem dey 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 without stopping. Set am small above the 95th percentile of your observed output_tokens, then handle stop_reason: "max_tokens" for code instead of sending answer wey cut off quietly.

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