Opus vs Sonnet vs Haiku: A Cost-vs-Capability Routing Guide

The instinct on a new Claude build is to point everything at the most capable model and move on. It works, and it quietly overpays, because most requests do not need the top tier. The opposite instinct — standardize on the cheapest model — undershoots on the requests that actually carry the product. The right answer is neither: match the model to the difficulty of each request, and make that match a configuration rather than a line of code.

This guide lays out the current Claude tiers by cost and capability, gives a practical mapping from task type to tier, and shows how to route by task through a gateway so the decision is reversible and measured. Prices and positioning below are from Anthropic’s models overview, as of October 2026; model lineups change, so treat the exact rates as a snapshot and confirm on Anthropic’s pricing page before budgeting.

The tiers, by price and capability

Four tiers, one context window. Haiku 5.5 is the fastest and cheapest, built for high-volume, latency-sensitive tasks. Sonnet 5.5 is positioned as the best combination of speed and intelligence. Opus 5.5 is the recommended default for most workloads, at moderate latency. Fable 5.1 sits above all of them for demanding reasoning and long-horizon agentic work — and is both the slowest and, at $10 / $50 per million tokens, the most expensive. Every tier shares the 1M-token context window and the June 2026 knowledge cutoff, which means you almost never pick a tier for context room; you pick it for how hard the task is and how fast you need the answer.

The jump from Haiku to Fable is roughly 100x on input price and 100x on output. That spread is the entire argument for routing: sending a Haiku-sized task to Fable is not a rounding error, it is a 100x overspend on that request.

Want cost and latency per Claude tier, with a budget cap per team?

Book a demo

Which tier for which task

Capability tiers map cleanly onto task difficulty. Use this as a starting default and adjust against your own evals.

Haiku handles the high-volume, well-bounded work: classification, routing and triage, extraction and tagging, short rewrites, simple structured output, and the “is this relevant?” filters in a RAG pipeline. These are tasks where a smaller model is not a compromise — it is the right tool, and the price and latency are the point.

Sonnet is the workhorse for most production features: drafting and editing, summarization with nuance, standard tool use and function calling, code of everyday complexity, and multi-step but not open-ended reasoning. If you are unsure, start here and measure.

Opus is the default when quality clearly matters: harder reasoning, longer tool chains, tricky code, and tasks where a wrong answer is expensive. As the recommended default it is also a safe baseline to escalate to from Sonnet.

Fable is for the genuinely hard cases — deep reasoning, long-horizon agentic workflows that chain many steps — where the extra capability earns its 100x price because a cheaper model simply fails the task. It is a scalpel, not a default.

The practical pattern is a cheap default with an escalation path: run the task on Haiku or Sonnet, and escalate to Opus or Fable only when a confidence signal, a validation check, or the task type demands it.

Route by task, not by hard-coding a model

The reason most teams overpay is architectural: the model name is a string in application code, so changing it is a deploy, and matching model to task per request is more than anyone wants to maintain by hand. A gateway removes that friction.

Point your application at a logical model name backed by a real tier, and you can change which tier serves it — or split traffic across tiers — without touching code. Add auto-routing, and the gateway scores each request and sends it to an appropriately sized model automatically. Either way the application sends one request to one endpoint; the routing decision lives in config, where you can tune it, canary it, and roll it back.

With cost and latency visible per tier and budgets set per team, the routing decision stops being a guess. You can see that a workload you were running on Opus holds quality on Sonnet, move it, and watch the cost line drop — the kind of change that is a one-line config edit instead of a cross-service refactor.

Where teams get this wrong

They standardize on one tier. All-Opus overpays on the easy majority; all-Haiku undershoots on the hard minority. Match the tier to the task.

They pick by context window. All four tiers share 1M tokens, so context is rarely the deciding factor. Choose on reasoning depth and latency.

They hard-code the model name. That makes every routing change a deploy and per-task routing impractical. Use a logical name so the tier is configuration.

They route without measuring. Down-routing to save money is only safe if you watch quality. Keep evals and per-model metrics on, and escalate where quality dips.

A worked example

A document-processing product runs three steps per file: detect document type, extract fields, and write a summary. Pointed entirely at Opus, every step pays the top rate. Routed by task, type-detection and extraction go to Haiku (bounded, high-volume), the summary goes to Sonnet (nuance without the Opus premium), and only files flagged low-confidence escalate to Opus for a second pass. The application calls one logical endpoint per step; the tiers behind them are config. The result is the same output quality on the hard files and a large cut on the easy majority — visible as a per-model cost breakdown in the gateway.

Related reading

• Multi-model routing
• What is an LLM router?
• LLM routing: cost- and quality-aware model selection
• Introducing auto-routing on the TrueFoundry AI Gateway
• LLM router

Conclusion

The Claude tiers are designed to be mixed, not chosen once. The capability curve is steep and so is the price curve, which means the cost of sending an easy task to a top tier — or a hard task to a cheap one — is large and entirely avoidable. The move is to match model to task difficulty, default cheap, and escalate on signal.

Make that match configuration rather than code, route by task through a gateway, and keep cost, latency, and quality visible per tier. Then “which model?” stops being a standing debate and becomes a dial you can turn per workload and see the result.

Match every Claude request to the right tier

Book a demo