Haiku, Sonnet, Opus & the Quality/Latency/Cost Triangle
CoreSelect among Claude model tiers against quality/latency/cost tradeoffs · Difficulty 2/5
Explanation
The Three Tiers
| Tier | Positioning | Typical use |
|---|---|---|
| Haiku | Fastest, cheapest, lightest | High-volume, latency-sensitive, simpler tasks -- classification, extraction, routing |
| Sonnet | Balanced workhorse | Most production application logic; strong quality at reasonable cost/latency |
| Opus | Most capable, highest cost/latency | Hardest reasoning, complex agents, high-value work |
Right-Sizing
Right-sizing means matching model capability to a task's actual difficulty and value -- not defaulting to the most capable model "to be safe." Paying Opus prices and latency for a simple routing step that Haiku handles just as correctly is a waste; conversely, running a genuinely hard reasoning task on the cheapest tier can cripple quality.
The Tradeoff Triangle
Quality, latency, and cost trade against each other -- improving one usually costs another. There is no universally "best" tier; the right choice is anchored on the specific requirement (a latency SLA, a cost-per-request ceiling, a quality bar) rather than chosen in the abstract.
Mixed-Model Architectures
A single workflow rarely needs one model throughout. Mixed-model architectures route cheap, well-defined steps to Haiku and hard reasoning/orchestration steps to Sonnet or Opus -- often the best overall cost/quality balance. Adaptive-thinking support also varies by tier, so a step that needs that capability constrains which tiers are viable for it.
Common exam traps
- "Always pick the most capable model to be safe." This is the wrong answer on this exam -- it wastes cost and latency; right-sizing per task/step is the intended reasoning.
- Treating model choice as a single, workflow-wide decision rather than a per-step decision that a mixed-model design can optimize independently.
Key Takeaways
- Haiku = fastest/cheapest for high-volume simple tasks; Sonnet = balanced workhorse; Opus = most capable for hard reasoning/high-value work
- Right-size model capability to task difficulty and value rather than defaulting to the most capable tier
- Quality, latency, and cost trade against each other -- anchor the choice on the specific requirement
- Mixed-model architectures route each workflow step to the tier that fits its own difficulty/cost/latency profile
Glossary Terms
The recurring architectural tension where an integration decision that improves accuracy (e.g., reranking, retrieving more chunks) typically adds latency and cost, and vice versa. The architect's job is not to eliminate the tradeoff but to make it explicit and justify the chosen configuration against whichever constraint the stated requirement names as dominant. Prompt caching a stable repeated context is the rare exception that improves cost and latency with no accuracy loss.
The fastest and most cost-effective Claude model tier, optimized for high-throughput, low-latency tasks like classification, extraction, and simple Q&A. Carries a 200K-token context limit (vs 1M on Sonnet/Opus) and is the recommended first-pass router in tiered pipeline architectures.
The practice of directing requests to different Claude model tiers based on assessed complexity and requirements. A common pattern uses a fast, cheap model (Haiku) to classify task complexity, then routes to Sonnet or Opus accordingly.
The most capable Claude model tier, excelling at complex multi-step reasoning, nuanced analysis, and high-stakes creative tasks. Highest accuracy but most expensive and slowest. Best suited for tasks where output quality outweighs cost and latency concerns.
The balanced Claude model tier offering the best trade-off between capability, speed, and cost for most production applications. The recommended default for new systems — handles the majority of complex tasks effectively without Opus-level expense.
Related Concepts
Model-Version Pinning & Eval-Gated Upgrades
A newer model release can change behavior in ways that break prompts tuned for an older version, even with an unchanged API contract
Extended & Adaptive Thinking as a Compute/Quality Lever
Extended thinking is an explicit reasoning budget spent before answering; adaptive thinking/effort levels vary reasoning depth by task difficulty automatically