Output Tokens Cost 5x More Than Input — And Most Teams Budget as If They Don't

There is a pricing asymmetry baked into every major LLM API that most teams underestimate until they see their first large invoice. Output tokens cost dramatically more than input tokens -- and the gap is not small.

On Anthropic's current pricing, the multiplier is exactly 5x across every model tier. Claude Sonnet 4.6 charges $3 per million input tokens and $15 per million output tokens. Claude Opus 4.7 charges $5 per million input and $25 per million output. Claude Haiku 4.5 charges $1 per million input and $5 per million output. The ratio is identical regardless of which model you choose: every output token costs five times what an input token costs.

This is not an accident. Output tokens are computationally expensive to generate. The model produces them one at a time, autoregressively, with each token requiring a full forward pass through the network. Input tokens are processed in parallel. The infrastructure cost is genuinely asymmetric, and the pricing reflects it.

Why Teams Get This Wrong ¶

Most teams budget for LLM costs by estimating their prompt size and multiplying by the input price. This produces a number that feels manageable. Then the bill arrives.

The mistake is treating output tokens as a rounding error. For many use cases, they are not. Consider a customer support bot that reads a 2,000-token conversation history and writes a 400-token response. The input is 5x longer than the output, but the output costs 5x more per token -- so the two sides of the bill are equal. Now add retrieval: inject 3,000 tokens of context, and suddenly your inputs dominate again. But for tasks with long outputs -- report generation, code synthesis, detailed analysis -- the output cost can easily exceed the input cost by 2x or more.

The 5x multiplier means that generating 200 tokens of output costs as much as ingesting 1,000 tokens of input. Most teams only notice this after they have already built and deployed a feature that generates verbose responses by default.

What Drives Output Token Count ¶

Output length is often treated as a fixed property of the task. It is not. It is a function of your prompt.

Models default to thoroughness. Ask a question without constraints and you will get a complete, structured, well-reasoned answer that is two to three times longer than you need. Add the instruction "be concise" and the model will often halve its output with no loss of usefulness. Add a specific word limit and it will hit it reliably.

Common output inflation patterns:

Each of these patterns is controllable through prompting. The cost savings from explicit output constraints are immediate and require no infrastructure changes.

The Cache Offset ¶

Anthropic's prompt caching changes the input-side economics significantly. Cached input tokens cost 10% of the standard input price -- $0.30 per million for Sonnet 4.6 versus $3.00. If your system prompt and few-shot examples are static, caching them reduces your input bill by 90%.

But caching does nothing for output tokens. The output price is fixed. This makes output length optimization more important as you adopt caching, not less. The more you reduce input costs through caching, the larger the output token share of your total bill becomes.

Practical Reduction Strategies ¶

You do not need to sacrifice response quality to reduce output costs. You need to specify what you actually want.

For classification tasks: instruct the model to return only the label, not an explanation. Cost reduction: 80-95%.

For extraction tasks: return JSON with only the requested fields. Prohibit commentary. Cost reduction: 60-80%.

For summarization: set a word limit. Models respect explicit constraints. Cost reduction: 40-60%.

For code generation: ask for the code only, no explanation unless requested. Cost reduction: 50-70%.

These are not compromises. A classification endpoint that returns a label is more useful than one that returns a label plus three paragraphs of reasoning. The reasoning costs money and usually gets thrown away by the calling application.

What to Measure ¶

Before you optimize, measure. Most teams do not know their average output length per endpoint, which means they cannot prioritize where to focus.

Pull your API logs for the last 30 days and compute average output tokens per call, segmented by use case. You will almost certainly find that 20% of your endpoints generate 80% of your output tokens. Those are your targets.

Then run A/B tests with constrained prompts. The win rate is typically high and the cost reduction is immediate. You do not need a new model, a new architecture, or a new vendor. You need a tighter prompt.

See how GotContext measures and compresses your token spend ->