Output tokens are five times the price

Almost every provider charges about five times more for output than for input. It is remarkably consistent:

Meanwhile most cost-reduction work goes into the prompt — trimming instructions, compressing context, tightening few-shot examples. That is effort spent on the cheap half of the bill.

Cutting 1,000 tokens of prompt saves what cutting 200 tokens of output saves. Nobody budgets that way, because the prompt is the part you wrote and the output is the part you receive.

Where it lands on a real workload

An extraction job, 40,000 documents a month on Sonnet 5, roughly 3,000 input tokens per document (the page image plus instructions) and 600 output tokens (the structured record):

input:   40,000 × 3,000 = 120,000,000 → 120 × $2  = $240.00
output:  40,000 ×   600 =  24,000,000 →  24 × $10 = $240.00

Output is 17% of the tokens and 50% of the bill. Halve the prompt — genuine work, and you would notice the effort — and you save $120. Halve the output and you save the same $120, which in this case means dropping fields you did not need.

The asymmetry is sharper anywhere output is long. A summarisation or drafting feature at 2,000 input and 1,500 output is already 79% output cost, and the prompt is where nobody should be looking.

Where the output tokens actually go

Four sources, in roughly descending order of how much people over-produce.

Reasoning you discard. Chain-of-thought is billed as output. If the model thinks for 800 tokens and you parse a single field out of the result, you paid for 800 tokens to keep 12. Often worth it for accuracy — but it should be a decision, not a default, and it should be measured per task rather than applied everywhere.

Fields nobody reads. Schemas accumulate. A field added for a feature that shipped two years ago is still being generated on every call. Audit against actual consumption:

-- Fields in the schema that nothing downstream has read this quarter.
-- Each one is output tokens on every single call.
select field from extraction_schema
where field not in (select distinct field from field_access_log
                    where at > now() - interval '90 days');

Pretty JSON. Whitespace is tokens. Asking for indented, key-ordered output adds roughly 10–15% to a structured response for zero information. Ask for compact output and format it yourself, for free, after it arrives.

Restating the input. A model asked to correct a document will often return the whole document. If you only need the diff, ask for the diff. This one is frequently a 10× difference on its own.

Preambles and closers

Models are conversational by default, and every "Certainly! Here is the extracted information:" is billed at output rates. So is "Let me know if you'd like me to adjust anything."

At 30 wasted tokens per call and 40,000 calls a month, that is 1.2M output tokens — $12 on Sonnet 5. Small, but it is pure waste, and it also breaks naive parsers, which is the more expensive consequence.

Use native structured output where the provider offers it. Where you cannot, prefill the assistant turn so the response has already started inside the object:

messages: [
  { role: "user", content: prompt },
  // The model continues from here. It cannot write a preamble,
  // because the turn has already begun with an opening brace.
  { role: "assistant", content: "{" },
]

The max_tokens trap

Setting max_tokens high "to be safe" costs nothing directly — you are billed for tokens generated, not tokens allowed.

It costs indirectly, in two ways. It removes the backstop on a runaway generation, so a model that starts repeating itself runs to the limit you set. And it makes every pre-flight cost estimate pessimistic, because the only honest upper bound on output is max_tokens — set it to 8,000 for a task that produces 400 and your budget guard is useless.

Set it per call site, slightly above what that call site actually needs.

What not to do

Two false economies:

Dropping to a cheaper model for output-heavy work. Sensible in isolation, but if the cheaper model needs more retries or produces output requiring correction, the arithmetic reverses. Measure end to end, including retries — which requires attributing spend per feature with the outcome column, or you cannot see the retries at all.

Truncating output to save money. A cut-off response is a failed call you paid for in full, plus the retry. This shows up as a bad max_tokens rather than as a cost decision, which is why it survives so long in production.

The reliable moves are the boring ones: generate fewer fields, generate them compactly, and stop generating reasoning you throw away.

More in when the model bill triples, prompt caching with the arithmetic, and what an AI feature costs to build. Rates from published Anthropic and Google pricing, checked 27 August 2026.