How does token pricing differ across Claude's Haiku, Sonnet, and Opus tiers?

## The pricing shape Anthropic publishes, for each Claude model, a price per million input tokens and a separate, higher price per million output tokens. Two independent things move the number you pay: 1. **Which tier you call.** Rates rise from Haiku to Sonnet to Opus. The multiplier between adjacent tiers has historically been in the low single digits to roughly five-fold, but the exact figures change with every release and every price revision — quote the structure in an interview, not memorised numbers, and check the current pricing page before building a budget. 2. **How many tokens of each kind you spend.** Output is the expensive kind. At each tier the output rate has typically been about five times the input rate, so a change in response length moves your bill roughly five times harder than the same change in prompt length. ## Why the token mix often beats the tier The common mistake is to reason about cost as "Opus is expensive, Haiku is cheap" as if it were a per-request price. It is not. Work the arithmetic: - A retrieval-augmented call that stuffs 100,000 tokens of documents into the prompt and asks for a 200-token answer is **input-dominated**. Its cost is essentially the prompt, and dropping a tier saves you the tier ratio on that prompt — real, but the prompt itself is the problem. Retrieving fewer, better chunks may save more than the downgrade does. - An agentic loop that runs twenty turns, each producing a few thousand tokens of reasoning and tool arguments, is **output-dominated**. Here the tier ratio bites hardest, because it multiplies the already-expensive output rate. So the first move in any cost investigation is to measure, not to guess: read `usage.input_tokens` and `usage.output_tokens` off real responses, aggregate them per endpoint, and only then decide whether the lever is the tier, the prompt, or the number of turns. ## Extended thinking and hidden output Where extended thinking is enabled, the model's reasoning tokens are billed as output tokens and count against the response budget. A workload that looks input-heavy on paper can turn output-heavy once thinking is switched on, and the thinking budget becomes a first-class cost knob alongside the tier. If your bill jumped without a traffic change, a thinking-budget or prompt change is as likely a culprit as the model. ## The other cost levers on the same model Dropping a tier is not the only, or even the first, lever: - **Prompt caching** discounts repeated prefix content — long system prompts, tool definitions, a fixed document set — dramatically on cache hits, at the cost of a surcharge on the write. For a workload where every request shares a big prefix, this often beats a tier downgrade and costs you nothing in quality. - **The Message Batches API** processes asynchronous work at a discount relative to the same model called synchronously. If a job does not need an answer in real time — nightly enrichment, bulk classification, backfills — this is nearly free money. - **Prompt engineering for brevity.** Asking for structured, short outputs instead of prose cuts the expensive side of the bill directly. - **Turn count.** In agent loops, each turn resends the accumulated conversation, so cost grows superlinearly with turns. Cutting the loop from twelve turns to six can halve the bill more reliably than any model swap. ## Putting a number on a tier swap The honest way to evaluate a downgrade is a two-column estimate over real traffic: ``` monthly_cost(tier) = requests x (avg_in x in_rate(tier) + avg_out x out_rate(tier)) ``` Compute it for both tiers using your measured averages, then set the saving against the measured quality delta on a held-out eval set. If the saving is 15% of a small bill and the eval shows a two-point accuracy drop on a task that touches customers, the downgrade is a bad trade; if the saving is 70% of a large bill with no measurable delta, it is obvious. The number that makes the decision is a ratio of two measurements, never a vibe about which model is "better". ## Cascade arithmetic One subtlety catches teams that route small-first and escalate: an escalated request pays for **both** calls, plus the tokens spent re-sending the prompt to the larger model. If your escalation rate is high, the cascade costs more than calling the big model once. Cascades only pay when the cheap tier resolves the large majority of traffic and the check that decides escalation is itself cheap.