Claude is not one price. The Anthropic API lists three model tiers whose input prices differ by nearly nineteen times — $0.80 versus $15 per million tokens — output tokens cost five times what input tokens cost on every tier, and the number that finally lands on your invoice is then reshaped by prompt caching, batch discounts and how much context your application re-sends with each call. Read the anthropic api price list against your actual workload and the right tier is usually obvious within an hour; read it as a single headline number and you will either overpay by an order of magnitude or ship something that cannot afford its own success. The same arithmetic applies to any AI API you put behind a product: the tier decision is the bill.
It matters now because of how modern workloads consume tokens. A chatbot sends the conversation once per turn; an agent that runs thirty tool-calling steps sends a growing transcript thirty times, with the system prompt riding along on every request. Workloads that cost “a few cents per call” in a demo become thirty stacked context windows in production, and the tier you picked casually in the playground is now multiplied by your busiest hour. Per-million pricing also reads as abstract right up until the first invoice arrives, which is why the teams who budget well are the ones who do the multiplication before launch rather than after.
What the price list actually says
Anthropic prices the API per million tokens, separately for input and output, across three tiers. At the top, the Opus tier (Opus 4.1 on the list as captured for this piece) bills $15 per million input tokens and $75 per million output tokens. The Sonnet tier (Sonnet 4) is $3 and $15. The Haiku tier (Haiku 3.5) is $0.80 and $4, with the previous-generation Haiku 3 still listed below it at $0.25 and $1.25. One surcharge sits outside the tiers: Sonnet requests longer than 200,000 tokens of context bill at $6 and $22.50 per million — double the input price, half again on output.
Two patterns in that table do more work than any single number. First, output is priced at exactly five times input on every tier, which is the list telling you where the compute actually goes. Second, the steps between tiers are large — roughly four times from Haiku to Sonnet, five times from Sonnet to Opus — so tier choice swings the bill further than any other lever you control.
Why output tokens decide your bill
The five-to-one output multiplier means token counts alone do not predict cost. Take a summarizer running on Sonnet: a 2,000-token document goes in, a 500-token summary comes out. The input costs 2,000 ÷ 1,000,000 × $3, or $0.006. The output costs 500 ÷ 1,000,000 × $15, or $0.0075. The summary is a quarter of the tokens but 56 percent of the cost of the call.
Multiply that across a million calls and the pattern becomes the whole budget: anything that shortens outputs — tighter instructions, a hard cap on response length, structured output instead of prose — cuts the bill faster than trimming the prompt ever will. Retries belong in the same column, because a retry pays for a second output too.
Which tier fits which workload
Map tiers to jobs, not to vibes. The Haiku tier is for high-volume, short-output, mostly mechanical work: classification, routing, extraction, filling fields from documents. The Sonnet tier is the production default — coding assistance, drafting, tool use, the traffic that faces users — and most teams should start there and step down where the work proves easy. The Opus tier is for the minority of calls where a wrong answer costs more than the price spread: hard reasoning, multi-step planning, the agent steps whose failure triggers a human.
The spread is easiest to see at monthly volume. Say an application consumes 30 million input tokens and 9 million output tokens in a month. On Haiku 3.5 that is $24 plus $36, or $60. On Sonnet, $90 plus $135, or $225. On Opus, $450 plus $675, or $1,125. Same product, same traffic, a nearly nineteen-fold range — which is why the useful question is not “is Claude expensive” but “which of these three products is this particular job.”
One decision rule keeps it honest: if a cheaper tier fails often enough that you retry, add the retry rate to its price before comparing. A tier that needs a second attempt on a third of its calls is effectively a third more expensive than its list price — and that is before counting the users who leave while it tries again.
The modifiers that move the real number
Two multipliers sit next to the table, and both point in your favor if your traffic has shape.
Prompt caching prices a repeated input prefix at a tenth of the list rate. A cache write costs 1.25 times the base input price; every read afterwards costs 0.1 times, and the cache refreshes each time it is hit, with a default lifetime of about five minutes. The effect scales with how static your context is. A 10,000-token system prompt sent with 10,000 requests in a day is 100 million input tokens at list price — $300 on Sonnet. With caching enabled it is one write at 1.25× plus 9,999 reads at 0.1×, which comes to about $30. Ninety percent off the input line, from a flag.
The batch API halves the price of both input and output for asynchronous work — jobs that can wait up to 24 hours. Nightly digests, backfills, evaluation runs and anything that processes yesterday’s data has no business paying interactive rates.
How to estimate the bill before you ship
You can get close enough to budget from with four lines of arithmetic and a prototype. First, log the usage object the API returns on every response — input tokens and output tokens per call, no guessing. Second, split the average into its parts: system prompt, conversation history, fresh user input, and expected output length. Third, multiply by daily volume and by the tier’s two prices. Fourth, subtract the modifiers: which prefixes are cacheable, which jobs are batchable.
Worked example. A support assistant handles 20,000 conversations a day, each carrying 500 input tokens of history and system prompt and producing 400 output tokens, on Sonnet. Input: 10 million tokens × $3 = $30 a day. Output: 8 million tokens × $15 = $120 a day. Total: $150 a day, call it $4,500 a month. Now the modifiers: if the static prefix is cached and 90 percent of input tokens become cache reads, the input line falls to about $5.70 a day — $3 for the fresh tenth, $2.70 for the cached ninth, with the 25 percent write premium a rounding error next to the saving — and the day drops to roughly $126. The nightly job that digests the day’s transcripts goes through batch at half price. The estimate will still be wrong in the ways volume is always wrong — spikes, long tails, a prompt that grows — so re-run it monthly against logged usage.
The takeaway
The verdict: the price list describes three different products, and “what does Claude cost” has three right answers. Haiku is a utility — buy it by the barrel for mechanical volume. Sonnet is the default production tier, and where a new workload should land first. Opus is a specialist you summon for the calls whose failure costs more than the spread. Getting this right is worth more than any other optimization available to you: one tier down cuts the token line by roughly three-quarters, caching takes up to ninety percent off a static input prefix, and batch takes half off anything that can wait until tomorrow. Read the list against your workload — tokens per call, output share, retry rate, cacheable prefix — and the cost question stops being a guess and becomes four rows in a spreadsheet.
Sourcing note: every price in this article is Anthropic’s published list price for the Claude API — the per-model input/output table, the Sonnet long-context surcharge, the caching multipliers and the batch discount — as shown on Anthropic’s pricing documentation (docs.claude.com) and its pricing page (anthropic.com/pricing), captured on 2026-09-07. Those pages change as models are added and retired, so confirm against the live pages before budgeting. All per-call and monthly figures are arithmetic derived from those list prices at the stated token volumes; none are measured production benchmarks.
