Claude API Pricing: A Model-by-Model Cost Breakdown

The four prices on every Claude API call

Before any model number means anything, you have to know what gets metered. A single Claude API request is billed across up to four token types, each at its own rate:

• Input tokens — everything you send: the system prompt, conversation history, tools and the user message.
• Output tokens — everything the model generates, including its reasoning. On every model this is 5x the input rate, so verbose generations dominate the bill.
• Cache write — the one-time cost of storing a prompt prefix so later requests can reuse it. At 1.25x the input rate, it is more than fresh input — you pay a premium to cache.
• Cache read — reusing that stored prefix on a later request, at roughly a tenth of the fresh input rate (and even less on the larger models). This is where caching pays back.

A long agent loop that re-sends the same context on every step is mostly cache reads if you cache well, and mostly fresh input if you do not. Same workload, very different bill — the real cost math is here.

Claude API prices, model by model

Here are the current per-million-token (MTok) rates for every model on the Claude Developer Platform.

• Opus 5.5 is the frontier tier — reserve it for hard reasoning and agentic work where quality pays for the price.
• Sonnet 5.5 is the workhorse: strong on most tasks at a fifth of Opus output cost.
• Haiku 5.5 is for high-volume, latency-sensitive work — but note the 100K-token cliff: prompts above 100K tokens are billed at the 5x tier.
• Fable 5.1 is the most expensive per token; use it only where its specific strengths are needed, and see when to use it vs Opus.

Notice the shape, not just the numbers: every tier holds the same ratios — output 5x input, cache write 1.25x input, cache read a small fraction of it — so all four prices move together once you know a model's input rate.

The discounts and multipliers that change your bill

The rate card is the starting point. Several modifiers move the real number up or down, and most teams forget at least one.

Caching and batching pull the bill down; residency, fast mode and the cache-write premium push it up. The two upward multipliers are easy to trigger by accident: US-only inference adds 10% to every token, and Opus 5.5 fast mode doubles the rate — turning $4/$20 into $8/$40. If you can tolerate a 24-hour turnaround, batching stacks on top of caching — the trade-offs are in Claude Batch API vs real-time.

How prompt caching math actually works

Caching is the most misunderstood line on the bill because it costs more before it costs less. A cache write is 1.25x the input rate — a 25% premium over sending those tokens once — so you only come out ahead when the prefix is read back enough times to earn that premium down.

The break-even is faster than most people expect. A fresh prefix costs 1x input every time. Caching it costs 1.25x once, then ~0.05x of input on each read (Opus and Sonnet). So the first reuse recovers the write premium, and from the second on you pay roughly 5% of the uncached path. In practice:

• Reused 0 times (or after the window expires): pure loss — you paid the premium for nothing.
• Reused once: roughly break-even — the write premium cancels the single saving.
• Reused 2+ times within the window: clear win — each extra read is near-free against a fresh send.

So caching rewards stable, repeated context — a fixed system prompt, a tool schema, a re-queried document — and punishes bursty, one-shot traffic with gaps longer than the five-minute default lifetime. Cache what repeats; leave the volatile tail fresh. Full worked math: Claude prompt caching: the real cost math.

Three worked cost examples

List prices are abstract until you push a real workload through them. Here are three common shapes — a chat assistant, a RAG feature, and an agentic loop — each costed with and without the obvious optimisation. All figures are monthly, real-time (non-batch).

1. A customer-support chat assistant (Sonnet 5.5)

A support bot with a 2,000-token system prompt and tool schema, a 1,000-token rolling conversation per turn, and a 300-token answer — at 500,000 turns a month.

• No caching: input is 3,000 × 500,000 = 1,500 MTok at $2 = $3,000; output is 300 × 500,000 = 150 MTok at $10 = $1,500. Total ~$4,500/month.
• Caching the 2,000-token system+tools prefix: reads are 1,000 MTok at $0.10 = $100; fresh input (the 1,000-token conversation) is 500 MTok at $2 = $1,000; output stays $1,500. Total ~$2,600/month — a 42% cut from caching a prefix that never changes.

2. A RAG feature (Sonnet 5.5)

A Retrieval-Augmented-Generation feature that sends a 50,000-token context and generates a 1,000-token answer, 100,000 times a month.

• No caching: input is 50,000 × 100,000 = 5,000 MTok at $2 = $10,000; output is 1,000 × 100,000 = 100 MTok at $10 = $1,000. Total ~$11,000/month.
• With a cached 45,000-token prefix (shared instructions and frequently re-queried documents): 4,500 MTok read at $0.10 = $450, plus 500 MTok fresh input at $2 = $1,000, plus $1,000 output. Total ~$2,450/month — before the small cache-write overhead.
• On Haiku 5.5 instead, cached: the same shape drops to a few hundred dollars — if the task tolerates the smaller model and the context stays under the 100K-token cliff.

3. An agentic loop (Sonnet 5.5 vs Opus 5.5)

A tool-calling agent that runs 12 steps per task, re-sending ~25,000 tokens of accumulated context and generating ~600 tokens on each step — across 20,000 tasks a month (240,000 steps).

• Sonnet 5.5, no caching: input is 25,000 × 240,000 = 6,000 MTok at $2 = $12,000; output is 600 × 240,000 = 144 MTok at $10 = $1,440. Total ~$13,440/month.
• Sonnet 5.5, caching the stable ~22,000-token prefix: reads are 5,280 MTok at $0.10 = $528; fresh input (the ~3,000 new tokens per step) is 720 MTok at $2 = $1,440; output stays $1,440. Total ~$3,400/month — the single biggest saving in the whole post, because an agent re-sends the same context dozens of times.
• Opus 5.5, no caching: the identical shape is 6,000 MTok at $4 = $24,000 input plus 144 MTok at $20 = $2,880 output — ~$26,880/month, roughly 8x the cached-Sonnet number. Running the loop on a frontier model you did not need is the most expensive mistake on this page.

One more agentic multiplier to budget for: multi-agent teams that fan work out to sub-agents can consume roughly 7x the tokens of a single agent — price it before you ship. Model selection is covered in the Opus vs Sonnet vs Haiku routing guide.

Choosing a model by cost: a simple framework

The worked examples all point the same way: the model is the first-order lever, and the right default is the cheapest model that passes your quality bar — not the most capable one available. Anchoring each tier's output price against Haiku as 1x shows the stakes.

A workable rule: start one tier below where you think you need to be, and escalate only on measured failure. Pick the cheapest model, run your real evaluation set, and promote a task only where quality actually drops below the bar — not on a hunch. Most teams that do this find Sonnet 5.5 handles the bulk of traffic and Opus is needed for a minority of genuinely hard requests. Routing each request to the right tier automatically, rather than hard-coding one model everywhere, is what turns this framework into real savings.

Controlling API spend across a team

The rate card tells you what a token costs. It does not tell you which team, feature or developer spent it — the question finance actually asks once more than one app is calling the API. Native reporting meters per key, but a key is not a feature: when three teams share one key it cannot answer 'what did the RAG feature cost' or 'whose agent is driving the Opus bill'.

Routing Claude API traffic through the TrueFoundry AI Gateway puts every call on one metered path: spend attributed per team, application, developer and model; model policy so an expensive tier is a deliberate choice; and spend limits that hold before the invoice, not after. Because the gateway sees every request, it is also where the model-selection framework above becomes enforceable by policy rather than by trust. The same view covers your coding agents too — one cost picture across tools. The gateway adds roughly 3–4 ms of overhead and is OpenTelemetry-compliant.

This matters even more off the first-party API: when Claude is billed through Amazon Bedrock, Google Vertex or Microsoft Foundry, the spend lands on your cloud bill and Anthropic's dashboards do not see it at all. A gateway (or OpenTelemetry instrumentation) is then the only place per-team attribution can live.

Want Claude API spend broken down per team and per feature — not one line item?

TrueFoundry AI Gateway

Gotchas worth knowing

• Output is the expensive half. At 5x the input rate, a chatty generation costs more than a large prompt — cap output length and rein in verbose reasoning.
• Cache writes are not free. At 1.25x input, caching only pays back when a prefix is reused at least twice within its lifetime.
• The 100K-token cliff on Haiku 5.5 quietly moves you to the 5x tier — a long-context Haiku job can cost more than you modelled, sometimes more than Sonnet on a shorter prompt.
• The default cache lifetime is five minutes. Bursty traffic with gaps keeps missing it; a longer-lived cache is worth configuring for steady workloads.
• Fast mode and residency are silent 2x and 1.1x multipliers — easy to toggle on and easy to forget. Audit them against the base rate card.
• List price is not your invoice. Multipliers, cache mix and contracted rates all move the real number — measure actual spend, do not estimate.

Related reading

• Claude Code Pricing Explained — the subscription side of Claude pricing
• Claude Prompt Caching: the Real Cost Math — when caching saves money and when it does not
• Opus vs Sonnet vs Haiku: a Cost-vs-Capability Routing Guide — the biggest single lever on your bill
• Claude Batch API vs Real-Time — the 50% cost lever for async work
• Centralising Cost Control Across AI Coding IDEs — one spend view across API and agents

Conclusion

Claude API pricing reads like a short rate card, but the number you actually pay is set underneath it: which model each request uses, how long the output runs, whether the prefix is cached, and whether the job could have been batched. None of those are on the pricing page — they are decisions in your code, and the worked examples show the same workload swinging 4x to 8x on them alone.

And once more than one team is calling the API, the rate card stops being the hard part. Knowing who spent it — and being able to cap it before the invoice — is what turns a predictable price into a controllable one.

Put your Claude API traffic behind one cost and control plane.

Book a demo