Claude API Pricing Across Haiku Sonnet and Opus Tiers

I've spent enough time staring at Anthropic invoices to know the sticker price on Haiku, Sonnet, and Opus tells you almost nothing by itself. Three tiers, three different cost bets, and the math only gets interesting once you stop reading the per-token rate and start asking what a real workload spends over thirty days.

What the per-token rates actually mean at production volumes

Nobody runs one token through a system. A rate sitting alone on a pricing page tells you little; what matters is the bill at the end of the cycle, once you multiply real call volume against real usage patterns.

Output tokens cost more than input tokens on every tier, and that gap widens fast once volume shows up. A pipeline generating long outputs (code, drafted documents, multi-step agent replies) ends up paying a lopsided share of its bill on the output side. A pipeline that mostly reads, like document Q&A or RAG with big retrieved chunks, pays most of its bill on input instead. Same token count, very different invoice, depending on which direction the tokens flow.

Take a classification job running a few thousand calls a day, tagging support tickets, routing requests, that sort of thing. Swap it from Sonnet to Haiku and the savings aren't a rounding error, they're a multiplier. The jumps aren't evenly sized either: Haiku to Sonnet is one real step up in cost, Sonnet to Opus is a bigger one, and teams get surprised by that second jump more often than the first.

I won't hand you a dollar figure, because it depends on your traffic and I'd be guessing. The method is what matters: track daily call volume, average input tokens per request, average output tokens per request, and which tier handles each workflow. Multiply it out per workflow, never in aggregate. That alone tells you more than any pricing page will.

How prompt caching and batch processing change the effective cost of each tier

Two levers move the effective cost of any tier. Skip either one and you're comparing prices you were never going to actually pay.

Batch processing is the easy lever. Anything that doesn't need a live response, eval runs, bulk document processing, an overnight analysis job, gets a real discount in batch mode, and it applies evenly across all three tiers.

Prompt caching is trickier, and it changes the shape of the decision more than the size of it. A cache hit reads at a small fraction of the standard input rate, real money once you've got a stable system prompt or a document that gets reused across many calls. Writing to the cache costs a bit more than a normal input read, so it only pays off once that cached content gets hit repeatedly. Anthropic offers two cache durations, short and long; the long window costs more upfront to write but wins out if the same context keeps getting reused over hours or days.

Nobody mentions this part upfront, but caching savings scale with the tier itself. Cache a big system prompt on Opus and you save more per hit, in raw dollars, than caching that same prompt on Haiku, simply because Opus starts from a higher base rate. Caching matters most at the top of the ladder, even though Haiku's baseline was already cheap.

There's also Fast Mode on Opus, a pricier variant for teams that need frontier-level output without frontier-level latency. It's a premium stacked on the base Opus rate, worth paying only when speed itself is the actual bottleneck, not just a nice-to-have.

Stack batch and caching on the right tier and you can land well under the sticker price. Treat the listed rates as a starting point for comparison, not a forecast of your invoice. Tier selection and cost optimization aren't two decisions made one after the other; they're the same decision, just viewed from different angles.

The context window picture across tiers and why it matters less than it used to

Context window size used to actually limit which model you could reach for. That's mostly over.

Every current Claude tier handles large context windows at standard pricing. Some older Sonnet generations, before 4.6, tacked on a surcharge once you crossed a certain prompt length. The current generation dropped that: one flat rate across the whole window, on both Sonnet and Opus.

Practically, that means long-context work, big codebases, long document sets, runs fine on a mid-tier model now, with no length tax showing up on the invoice. Reaching for Opus on a long-context task should come down to one question: does the task need Opus-level reasoning. Context length stopped being the bottleneck years ago. Capability is the only thing left worth arguing about.

One more thing, worth knowing if you're building production infrastructure: Anthropic has said dateless model IDs from the 4.6 generation onward are pinned snapshots. Your pipeline's behavior won't shift under you because a model got swapped out overnight without anyone telling you.

What kinds of tasks genuinely require Opus versus where Sonnet or Haiku is sufficient

Routing everything to the top-tier model "just to be safe" is the single most common mistake I run into in production AI. It sounds cautious on paper. In practice it treats capability and quality as the same axis, and they aren't.

Haiku handles more than most people give it credit for: classification and intent detection, structured extraction from short predictable inputs, summarizing short documents, reformatting text into JSON, answering constrained questions against a fixed knowledge base. All of that runs fine on Haiku.

Sonnet earns its price on tasks with more moving parts, general coding and code review, reasoning over moderately complex inputs, customer-facing responses that need nuance but not frontier judgment, RAG pipelines built on substantial retrieved context.

Opus is for tasks where being wrong actually costs something. Complex multi-step agentic workflows, where one bad reasoning step cascades into the next, belong here. So do enterprise decisions where the output drives something valuable enough that the price gap between tiers becomes noise by comparison. On coding specifically: Sonnet 4.5 benchmarks strongly, so the bar for justifying Opus on a coding task sits higher than most teams assume walking in.

And underneath all of it sits a catch: "this task requires Opus" is a hypothesis. Testing it against your own outputs on your own data is the only way to actually know. Assume it instead, and you'll overpay for months without ever noticing.

How cost differences compound across a multi-workflow production system

A production AI system is almost never one workflow. It's ingestion, classification, generation, evaluation, summarization, each with its own token profile and its own capability floor. Route them all to the same tier and you overspend on some while shortchanging others. There's no version of "one tier fits all" that comes out efficient across five different task types.

Agentic systems make this worse. A single user turn can trigger several model calls back to back: one to pick a tool, one to interpret what came back, one to generate the final response. Each call carries its own complexity profile, and each could reasonably live on a different tier. Route them all identically and you've baked the inefficiency straight into the architecture.

Spend has a way of surprising organizations that scale usage faster than they scale visibility into that usage. Token volume climbs fast once a feature ships broadly, and without cost broken out per workflow, it's genuinely hard to see where the money's going. It's a recognizable pattern: a handful of high-volume automated workflows quietly driving most of the spend, nobody watching that particular meter, and the annual budget gone well ahead of schedule.

The fix isn't a one-time audit. Tier assignments made at design time need revisiting once real usage data comes in. A workflow that looked like it needed Sonnet on day one might turn out Haiku-sufficient at scale, and sometimes it runs the other direction entirely.

Building a routing strategy from the tier structure rather than a fixed model assignment

Routing treats tier selection as a live decision, made continuously, rather than something you configure once and walk away from. Four inputs feed that decision:

• Task type and complexity: pattern-matching, or genuine multi-step reasoning?
• Latency requirement: a synchronous user-facing reply, or a background batch job?
• Quality threshold: what does a wrong or low-quality output actually cost here?
• Volume: how many requests hit this path daily, and how does that scale the gap between tiers?

The practical rule: default to the lowest tier that clears your quality bar, and escalate only when the task or a live signal earns it. Those signals come from two places. Offline, build curated evaluation sets per task type and test each candidate tier against them before shipping anything. Online, run a lightweight model as a quality checker in production, flagging anything below threshold for re-routing to something stronger.

None of this works without infrastructure behind it. You need a routing layer that sends requests to different tiers without touching application code, observability broken out per workflow instead of blended into one aggregate number, and the ability to change routing rules without a redeploy. Teams running multiple providers alongside Claude can apply the same discipline across the whole stack, routing on cost, quality, and latency across providers rather than just within Claude's own tiers. An LLM gateway is the natural home for that logic; it sits between the application and the providers, applies routing rules at request time, and collects the observability data that lets you keep refining those rules over time. Done right, the application stops carrying routing logic and provider credentials as its own problem, and that job moves into the infrastructure layer.

What to evaluate before committing a workflow to a specific tier

Before locking a workflow to a tier, run the actual task against Haiku, Sonnet, and Opus on your own data. Measure the output, not a benchmark score.

Published benchmarks are fine for building a shortlist, and that's about all they're good for. They tell you almost nothing about how a model handles your specific codebase, your document format, your customer's tone. A model that tops a coding benchmark can still underperform on your particular style of code, and the only way to find that out is by testing it yourself.

A real evaluation looks like this: define a quality rubric specific to the task (correctness, format compliance, tone, factual accuracy, whatever applies), build a sample of real inputs that includes edge cases rather than just the easy ones, and run that sample across all three tiers. Measure quality and cost per request side by side. Whichever tier clears your threshold at the lowest cost, that's your routing target.

For a lot of workloads, Haiku and Sonnet land at comparable quality, and cost ends up the only variable separating them. Worth knowing, but check it against your own task; don't take it on faith from a pricing page or a benchmark chart.

Set a trigger to redo the evaluation: volume growth, a prompt change, any hint of quality slipping in production. Build the routing rules so they can change without touching application code, because the evaluation will eventually show that some of your original tier assignments were wrong. Fixing that should cost an hour, not a redeploy.

Track cost per workflow from day one. If all you can see is the aggregate bill, you can't tell which workflow is driving the spend, and you can't tell which routing change would actually move the needle. That visibility is the whole game here, and most teams don't build it until after the bill's already surprised them.