How to Choose Between Claude Haiku, Sonnet, and Opus

The default pick for production AI work is now Claude Sonnet 5. It handles the large majority of real tasks well, it lands near Opus quality on coding and agentic work, and it costs Sonnet money (currently discounted to $2 / $10 per million tokens through 2026-08-31, against a list price of $3 / $15). Haiku 4.5 is still the right pick when you have high volume and forgiving accuracy requirements (classification, extraction, summarisation of short text). Claude Opus 5 is the right pick when you need the strongest reasoning available at Opus pricing: complex agentic coding, multi-file features, larger refactors, long-horizon plans. And there is now a fourth tier above Opus, Claude Fable 5, at $10 / $50 per million tokens, for the most demanding reasoning and longest-horizon agentic work. I'll walk the cost math, the latency profile, the capability gaps, the new effort dial, and a concrete decision matrix for routing prompts across the four tiers.

The wrong question is still "which model is the best." The right question is still "what's the cheapest tier that gets this specific task done well enough." An app that runs everything on Opus 5 pays roughly 1.7× a pure-Sonnet bill (and far more than a routed one) for a quality lift you probably can't measure on most tasks. An app that runs everything on Haiku makes mistakes the user notices. The win is routing.

What has changed since I first wrote this is that tier is no longer the only dial. The effort parameter now sets how hard a model works on a given request, and on the 5-family models it moves cost and latency as much as a tier change does. So there are two dials to turn, and you should turn the cheap one first.

Jump to:

• The current pricing (August 2026)
• The effort parameter: the second dial
• Latency profile per tier
• Capability gaps: where each tier wins
• The default: start with Sonnet 5
• When to drop to Haiku
• When to step up to Opus 5
• When Fable 5 is worth it
• Decision matrix
• Cost math: routing across tiers
• FAQ

The current pricing (August 2026)

Sonnet 5 is running an introductory price of $2.00 / $10.00 per million tokens through 2026-08-31, after which it reverts to the $3 / $15 list price above. Budget on the list price, enjoy the discount while it lasts.

The previous generation is still available at the same prices if you have a pipeline you don't want to disturb: claude-sonnet-4-6 at $3 / $15, and claude-opus-4-8, claude-opus-4-7, and claude-opus-4-6 at $5 / $25. Opus 5 is priced identically to Opus 4.8 and is a clear step up on deep reasoning and long-horizon agentic work, so for new work there is no cost argument for staying on 4.8. Pin an older model only when you have already validated a pipeline against it and want to freeze it for reproducibility.

Haiku is the odd one out on limits. It is the only current model with a 200K context window rather than 1M, and a 64K max output rather than 128K. If a task needs a genuinely large context or a very long single response, Haiku is out before you even get to a quality argument.

Cache writes cost 1.25× input for the 5-minute TTL, 2× for the 1-hour TTL, and cache reads cost roughly 0.1× input. One gotcha worth knowing: the minimum cacheable prefix is not consistent across models, and it does not shrink monotonically as models get newer. It is 512 tokens on Opus 5 and Fable 5, 1024 on Sonnet 5, and 4096 on Opus 4.6 and Haiku 4.5. A 2K-token system prompt caches fine on Opus 5 and Sonnet 5 and silently does not cache at all on Haiku 4.5, with no error, just a cache-read count that stays at zero. Prompt caching is covered in How to Cut LLM API Costs with Prompt Caching.

For generation-heavy workloads, output cost is where the budget goes, a typical content-generation task has a 5:1 to 10:1 output-to-input token ratio (lower for classification and extraction, where input dominates). Opus 5 output costs $25 per million tokens versus Sonnet 5's $15, about 1.7×, and Fable 5's $50 is 3.3× Sonnet. Blanket use of the top tier is rarely the right call.

If latency genuinely doesn't matter, the Batch API runs the same models at 50% of these prices. That discount stacks with every routing decision below.

The effort parameter: the second dial

This is the piece the old version of this article predates, and it is arguably as important now as picking a tier.

Every current model takes an effort setting inside output_config:

output_config: { effort: "low" }  // low | medium | high | xhigh | max

The default is high. Lower it and the model thinks less, calls fewer tools, writes less preamble, and finishes faster and cheaper. Raise it and it explores more before answering.

Two things make this worth wiring into your code rather than leaving at the default:

• On Opus 5 and Sonnet 5, low and medium are unusually strong. They are not the crippled settings the names suggest. A lot of routine work that you would previously have pushed down a tier for cost reasons is better served by staying on the tier and dropping effort. That is the primary cost and latency lever on these models.
• For hard coding and agentic work, xhigh is the recommendation on Opus 5 and Sonnet 5, not high and not max. max exists for cases where correctness beats cost outright, but it can overthink simple tasks and show diminishing returns.

Related, thinking is now adaptive rather than budgeted. You set thinking: { type: "adaptive" } and the model decides how much to think per request. The old fixed budget_tokens field is gone on the 5-family and on Opus 4.7/4.8, and sending it returns a 400. So do the sampling parameters: temperature, top_p, and top_k are rejected on those models, and you steer with prompting instead. On Opus 5 and Sonnet 5, thinking is on by default when you omit the parameter, which is a change from 4.7 and 4.8, where omitting it meant no thinking. If you sized max_tokens tightly around an answer on an older model, revisit it, because thinking and response text share that budget.

My rule: pick the tier first on capability, then sweep effort downward on your own evals until quality stops holding. Most routes land lower than the high default, and the saving is real.

Latency profile per tier

Time-to-first-token and tokens-per-second vary by region, traffic, prompt size, output length, effort setting, and service tier, and Anthropic does not publish official figures. Treat the ranking below as solid and anything numeric as ballpark. The one place I have durable measurements is Haiku 4.5, which is the same model it was a year ago; for the 5-family I'd rather give you a ranking than invent precision.

Effort now moves latency more than a tier change does. Opus 5 at low can return faster than Sonnet 5 at xhigh. If you are tuning for a latency target, sweep effort before you swap tiers.

Two other levers worth knowing. Fast mode (speed: "fast") is available on Opus 5 and Opus 4.8, on the Claude API only, and runs the same model at higher output throughput for $10 / $50 per million tokens. It is the escape hatch when you want Opus quality inside an interactive latency budget and are willing to pay Fable-tier prices for it. And Fable 5 has thinking permanently on, which you cannot disable, so its floor latency is higher than the other tiers by design.

For interactive UX where the user is watching tokens stream, Haiku feels instant, Sonnet 5 feels responsive, Opus 5 feels thoughtful, and Fable 5 feels like it went away to work. For background workflows where latency isn't user-visible, none of this matters. For real-time chat, it matters a lot.

Capability gaps: where each tier wins

After running every kind of prompt across these tiers in production, the practical capability map:

Haiku 4.5 is reliably good at:

• Classification (sentiment, topic, intent)
• Field extraction from structured documents
• Short summaries (paragraph to 1-2 sentences)
• Yes/no questions with a reasonably worded context
• Simple translation
• Code completion within a single function

Haiku 4.5 visibly struggles with:

• Multi-step reasoning (more than 2-3 steps)
• Long-context synthesis, and its 200K window caps it before its reasoning does
• Hard refactors across many files
• Anything that needs "thinking carefully"

Sonnet 5 is the workhorse:

• All of Haiku's strengths, plus
• Multi-step reasoning well past what Sonnet 4.6 handled
• Long-context analysis across a 1M-token window
• Code generation that runs on the first or second try
• Most agentic workflows, and the gap to Opus here is much narrower than it used to be
• Most chatbot use cases

Sonnet 5 gives ground to Opus 5 on:

• Deeply nested logical reasoning ("if A then B, but only if not C, unless D, in which case E")
• Very long-horizon planning where each step compounds
• Code refactors that touch architectural concerns across many files

Opus 5 wins on:

• Complex agentic coding, multi-file features, and larger refactors, where it is a genuine step up on Opus 4.8 at the same price
• Code review and bug-finding, where it manages high precision and high recall at once, rather than trading one for the other
• Plans that need to be right because each step is expensive
• Novel problem-solving where there is no obvious template
• Holding quality at low and medium effort, which is a real cost lever rather than a footnote

Fable 5 sits above all of them on the most demanding reasoning and the longest-horizon agentic runs. It also comes with constraints the others don't have, which are covered below.

The default: start with Sonnet 5

For any new endpoint, prompt, or pipeline: start with Sonnet 5 at the default effort. Measure quality on a representative sample. Then ask, in this order:

1. Is the quality acceptable? Try dropping effort to medium or low and re-measure. Keep the cheapest setting that holds.
2. Is the quality high-but-overkill, and does cost or latency matter more than the margin? Try Haiku.
3. Is the quality not good enough? Raise effort to xhigh first. If that doesn't close it, step up to Opus 5.

The effort step is the one people skip. Dropping a tier changes the model's capability ceiling; dropping effort just stops it doing work the task didn't need. Try the second before the first.

You'll find that for roughly 70% of endpoints Sonnet 5 is the right answer. You'll move some down to Haiku for cost reasons and some up to Opus 5 for quality reasons. That distribution is the win.

Don't pick the tier on intuition, measure. Run the same 50 prompts through each tier and each effort level, score the outputs against a ground truth or an LLM-as-judge, and pick on data. Building an eval suite for this is covered in How to Write LLM Evals That Catch Regressions.

When to drop to Haiku

Drop to Haiku when:

• The task is structural classification. "Is this a refund request, a billing question, or a feature request?", Haiku handles this perfectly at a third of Sonnet's list price.
• You're extracting fields from a structured source. "Pull the order ID and the total from this email", Haiku reads this fine.
• You have high volume. Anything running thousands of times an hour is worth a Haiku eval just to see if it survives the downgrade. A two-thirds cost cut at high volume is real money.
• Latency is user-facing. Streaming UX where the user is watching tokens feels noticeably better on Haiku, and nothing else comes close on tokens per second.

Don't drop to Haiku when:

• The task involves multi-step reasoning.
• The task involves long context. Haiku's window is 200K, not 1M, and it degrades on dense content well before that.
• The task needs a long single response. Haiku caps output at 64K tokens against 128K elsewhere.
• The task is novel. Haiku is great at tasks it has seen, weaker at unusual ones.
• You were planning to lean on prompt caching for a short prefix. Haiku's minimum cacheable prefix is 4096 tokens, so a modest system prompt that caches happily on Sonnet 5 or Opus 5 silently won't cache here.

Before dropping a tier, try Sonnet 5 at low effort. On plenty of "Haiku-shaped" tasks the quality difference against Haiku is larger than the price difference, and you keep the 1M window.

When to step up to Opus 5

Step up to Opus 5 when:

• Sonnet 5 is producing wrong answers on the same prompt repeatedly, at xhigh effort. Not "slightly off", visibly wrong. Run the same prompt 5 times. If 3 or more outputs are wrong at the top effort setting, Sonnet is at its limit and more effort won't fix it.
• The cost of a wrong answer is high. Financial decisions, medical summaries, legal drafting, anywhere a mistake is expensive to fix.
• The task requires architectural thinking. Multi-file refactors and cross-cutting changes are where Opus 5's lead over Sonnet is widest.
• You are reviewing code or hunting bugs. Opus 5 manages high precision and high recall together, which most models make you choose between.
• The plan is long and each step is expensive. Agentic workflows where running the wrong tool costs you minutes or dollars per step. The cost of Opus is small compared to the cost of running 12 bad tool calls.

Opus 5 vs Opus 4.8: for any new work, reach for Opus 5. It is a step change on deep reasoning, agentic execution, and long-horizon work, at exactly the same $5 / $25 as Opus 4.8, with the same 1M context. It is a drop-in upgrade in the pricing sense. Two things do change: thinking is on by default when you omit the parameter, and disabling thinking is only allowed at effort high or lower, so a route that combined disabled thinking with xhigh on 4.8 will now return a 400. Pin Opus 4.8 or 4.7 only for reproducibility on an already-validated pipeline.

Don't step up to Opus 5 when:

• The task is high-volume and quality is "good enough" on Sonnet 5. The cost adds up fast.
• The task is latency-sensitive and you haven't tried Opus 5 at low or medium yet. Those settings are strong, and they may put Opus inside your latency budget without fast mode.

When Fable 5 is worth it

Fable 5 is Anthropic's most capable widely released model and sits a full tier above Opus, at $10 / $50 per million tokens, with the same 1M context and 128K max output. It exists for the tasks at the very top of your difficulty range: the hardest reasoning, and long-horizon autonomous agentic runs where the model works for a long stretch without correction.

Reach for it when Opus 5 at max effort still isn't getting there, and the outcome is worth 2× the Opus bill. That is a narrow set of tasks, and I'd argue that if you cannot name the specific request that Opus 5 fails, you don't need Fable yet.

It also comes with real constraints, and you should know them before you wire it in:

• Thinking is always on and cannot be disabled. Sending thinking: { type: "disabled" } returns a 400. You control depth with effort only. This sets a floor on latency and cost per request.
• No assistant prefill. If you were prefilling the last assistant turn to force a shape, that pattern is gone (it also 400s on Opus 5 and the 4.6-and-later family). Use structured outputs or a system prompt instruction instead.
• It requires 30-day data retention. Fable 5 is not available under zero-data-retention. If your organisation is configured for ZDR, every Fable request returns a 400, no matter how well-formed the payload is. That one costs people an afternoon of debugging the request body.
• Its safety classifiers can decline a request. You get a successful HTTP 200 with stop_reason: "refusal" rather than an error. Benign work adjacent to cybersecurity and research biology occasionally trips it. Code that reads response.content[0] without checking stop_reason first will break. This applies to Opus 5 as well, so it's worth handling in shared code rather than a Fable-specific branch.

There is also a Claude Mythos 5 with the same specifications, available only through Anthropic's invitation-only Project Glasswing. Mentioning it for completeness, but it is not something you can go and use.

Decision matrix

Cost math: routing across tiers

Concrete example. A customer-support AI handles 100,000 queries a day. Assume each call is about 1K input tokens and 500 output tokens. The per-call cost on each tier, at list prices:

• Haiku 4.5, (1,000 × $1 + 500 × $5) / 1,000,000 = $0.0035 per call
• Sonnet 5, (1,000 × $3 + 500 × $15) / 1,000,000 = $0.0105 per call ($0.0070 at the introductory price)
• Opus 5, (1,000 × $5 + 500 × $25) / 1,000,000 = $0.0175 per call
• Fable 5, (1,000 × $10 + 500 × $50) / 1,000,000 = $0.0350 per call

Without routing, every query goes to Sonnet 5:

100,000 calls × $0.0105 = $1,050/day.

With routing, Haiku handles 60% (simple lookups, classification), Sonnet 5 handles 35% (real questions), Opus 5 handles 5% (escalations that need harder reasoning):

• 60,000 × $0.0035 (Haiku) = $210.00
• 35,000 × $0.0105 (Sonnet 5) = $367.50
• 5,000 × $0.0175 (Opus 5) = $87.50

Total: $665/day. That's a $385/day saving (about 37%) just from routing, with arguably better outcomes on the Opus-routed escalations.

The routing logic itself can be a Haiku classifier ("which tier should handle this prompt?"). A short classification call costs about $0.0004, running it on all 100,000 calls adds roughly $40/day, dwarfed by the $385/day the routing saves.

One caveat on comparing Sonnet 5 to Sonnet 4.6. Sonnet 5 uses a new tokenizer, and the same text produces roughly 30% more tokens than it did on Sonnet 4.6. The per-token price is unchanged, so the sticker looks identical, but a given request can cost more. If you are migrating a workload and want an apples-to-apples number, re-run count_tokens against claude-sonnet-5 on a representative sample rather than reusing counts measured on 4.6. The same applies to any max_tokens ceiling you tuned on the old model, which may now truncate the equivalent output.

Layer the other levers on top of routing. Prompt caching cuts the cached portion of input to roughly 0.1×. The Batch API halves everything if the work can wait. And the effort dial trims spend inside whichever tier you land on. Applied together these compound rather than compete.

What to do next

For the cost-optimisation companion technique that stacks with model routing:

• How to Cut LLM API Costs with Prompt Caching, once you've picked the right tier, caching the stable prefix is the next 90% off. Mind the per-model minimum prefix sizes above.

For the evaluation infrastructure you need to actually pick a tier on data instead of vibes:

• How to Write LLM Evals That Catch Regressions covers the test-suite pattern for measuring quality differences across tiers, and it is the same harness you'll use to sweep effort levels.

External reference: the Anthropic model documentation is the canonical source for current capabilities, context windows, and pricing.

FAQ

See also

• How to Build RAG with Embeddings and Vector Search: the retrieval pattern that lets you use a cheaper Claude model (Haiku) without sacrificing answer quality
• How to Build an LLM Agent with Tool Use: when the workload is tool calls in a loop, the model choice math changes
• How to Cut LLM API Costs with Prompt Caching: the cost picture for each Claude model shifts dramatically once prompt caching is in play
• How to Stop an LLM from Hallucinating: a stronger tier reduces hallucination but does not remove it, this is what actually does
• How to Run a Local LLM with Ollama: when none of Haiku, Sonnet, Opus, or Fable fit your privacy or cost budget, a local model is the fallback
• How to Get Reliable JSON from an LLM: how the choice of model interacts with structured-output reliability