Anthropic’s Claude Opus Sonnet Haiku naming scheme maps directly to a three-tier capability ladder: Opus for maximum reasoning, Sonnet for balanced workloads, and Haiku for speed-critical paths. Each name signals a fixed position on the latency–cost–intelligence curve rather than a version number, so swapping tiers is an architectural decision, not a drop-in upgrade. Understanding the boundaries between tiers lets you route requests to the right model without overpaying or under-delivering.
How the three tiers map to real workloads
Anthropic positions the tiers as distinct products, not incremental checkpoints. The naming is intentional: Opus evokes a substantial work, Sonnet a structured medium form, Haiku a compressed instant. That metaphor holds in practice.
Opus — maximum reasoning, highest cost
Opus is the flagship. It targets tasks where correctness and depth outweigh latency and spend: multi-step planning, codebase-wide refactors, legal or financial analysis, and agent loops that branch heavily. Expect 2–5× the per-token cost of Sonnet and 10–20× Haiku. Latency is correspondingly higher — often 2–3× Sonnet on the same prompt.
Use Opus when:
- A wrong answer triggers expensive human review
- The task requires holding 100k+ tokens of context across multiple turns
- You need the model to self-correct across tool calls without explicit scaffolding
Sonnet — the default for production workloads
Sonnet occupies the sweet spot for most user-facing features: chat, RAG, summarization, classification, and single-file code generation. It handles 200k context windows, follows complex instructions reliably, and runs at a price point that fits in standard per-request budgets. The current Sonnet 3.5 (and 3.5 “new”) is the workhorse most teams should default to.
Use Sonnet when:
- You need consistent quality across high volume
- Latency budgets are 1–3 seconds end-to-end
- The task fits in a single turn or a short conversation
Haiku — speed and cost at the edge
Haiku trades reasoning depth for sub-second latency and pennies-per-million tokens. It excels at classification, extraction, routing, and high-volume preprocessing where the prompt is narrow and the output format is constrained. It struggles with multi-step logic, long-context synthesis, and ambiguous instructions.
Use Haiku when:
- You process millions of short requests per day
- P99 latency must stay under 500 ms
- The task is deterministic: sentiment, PII detection, intent routing, format conversion
Why the naming matters for system design
The tier names are not marketing fluff — they are API contracts. When you specify claude-3-5-sonnet-20241022 or claude-3-haiku-20240307, you lock in a specific capability profile. Anthropic does not silently promote a Haiku request to Sonnet capacity. This predictability lets you build routing logic that is testable and auditable.
Routing by tier in practice
A common pattern: classify the incoming request, then dispatch to the cheapest tier that meets the SLA. Pseudocode:
def route_request(prompt: str, context_tokens: int, sla_ms: int) -> str:
# Heuristics — tune per your evals
if context_tokens > 100_000 or requires_multi_step_reasoning(prompt):
return "claude-3-5-sonnet-20241022" # Opus if budget allows
if sla_ms < 800 and context_tokens < 8_000:
return "claude-3-haiku-20240307"
return "claude-3-5-sonnet-20241022"This logic belongs in your gateway layer, not scattered across call sites. At n4n.ai we see teams encode this as a routing directive header so the gateway enforces the policy centrally — x-model-tier: sonnet — and falls back only when the tier is degraded.
Cost modeling per tier
Rough per-million-token blended rates (input + output, 2024 pricing):
| Tier | Input | Output | Typical blend |
|---|---|---|---|
| Opus | $15 | $75 | ~$45 |
| Sonnet | $3 | $15 | ~$9 |
| Haiku | $0.25 | $1.25 | ~$0.75 |
A 10k-request/day feature at 2k tokens/request:
- Haiku: ~$4.50/day
- Sonnet: ~$54/day
- Opus: ~$270/day
Multiply by 30 and the tier choice becomes a budget line item, not a technical detail.
Concrete example: a support triage pipeline
Consider a ticket triage system that classifies, enriches, and routes incoming support emails.
Stage 1 — Classification (Haiku)
{
"model": "claude-3-haiku-20240307",
"messages": [
{"role": "system", "content": "Classify: billing, technical, account, spam. Output JSON only."},
{"role": "user", "content": "{{email_body}}"}
],
"max_tokens": 50,
"temperature": 0
}Latency: ~200 ms. Cost: ~$0.0002 per email. Haiku handles the fixed taxonomy reliably.
Stage 2 — Entity extraction (Haiku → Sonnet fallback)
{
"model": "claude-3-haiku-20240307",
"messages": [
{"role": "system", "content": "Extract: order_id, product_sku, account_id. Null if absent. JSON only."},
{"role": "user", "content": "{{email_body}}"}
],
"max_tokens": 200
}If Haiku returns low-confidence or malformed JSON (detected via schema validation), retry once with Sonnet. This two-tier fallback captures 95%+ at Haiku cost, escalates the rest.
Stage 3 — Response drafting (Sonnet)
{
"model": "claude-3-5-sonnet-20241022",
"messages": [
{"role": "system", "content": "Draft a reply using the knowledge base snippets. Tone: empathetic, concise."},
{"role": "user", "content": "{{email_body}}\n\n{{kb_snippets}}"}
],
"max_tokens": 1000,
"temperature": 0.3
}Sonnet handles the synthesis. Opus would be wasteful here — the task is bounded, context fits, and Sonnet’s instruction following is sufficient.
Stage 4 — Escalation analysis (Opus, rare)
Only tickets flagged “complex” by a downstream classifier reach Opus:
{
"model": "claude-3-opus-20240229",
"messages": [
{"role": "system", "content": "Analyze this multi-thread conversation. Identify root cause, propose resolution steps, estimate risk."},
{"role": "user", "content": "{{full_thread}}"}
],
"max_tokens": 2000
}Opus earns its keep on the 2% of tickets that need cross-thread reasoning.
Common misconceptions
“Newer version numbers mean better across the board”
claude-3-5-sonnet-20241022 outperforms claude-3-opus-20240229 on many benchmarks, but not all. Opus retains advantages in very long context synthesis and certain multi-agent orchestration tasks. Version bumps within a tier (3.5 → 3.5 new) improve the tier; they do not collapse the tier hierarchy. Treat tier and version as independent axes.
“Haiku is just a worse Sonnet”
Haiku is a different model architecture optimized for throughput. On constrained tasks — classification, extraction, formatting — it often matches Sonnet quality at 1/10th the latency. The failure mode is open-ended reasoning, not quality per se. Benchmark your specific task before assuming Sonnet is required.
“Opus is always worth it for code”
For single-file edits, test generation, and PR reviews, Sonnet 3.5 is often indistinguishable from Opus and 3–4× cheaper. Reserve Opus for repository-scale refactors, architectural decisions, and debugging sessions where the model must hold large mental models across many turns.
“You can’t mix tiers in one conversation”
You can and should. The API is stateless — each request carries its own model parameter. A conversation that starts with Haiku classification, moves to Sonnet drafting, and escalates to Opus analysis is a valid pattern. Just maintain context explicitly (pass the history) since there is no server-side session.
“The names map to parameter counts”
Anthropic does not publish parameter counts. The names signal product positioning, not architecture. Do not assume Opus = 1T params, Sonnet = 300B, Haiku = 50B. The only reliable signals are the published benchmarks, your evals, and the price sheet.
Operational checklist for tier adoption
- Define SLAs per feature — latency ceiling, cost ceiling, quality floor.
- Build evals per tier — run your golden set against Haiku, Sonnet, Opus. Record pass rate, latency, cost.
- Encode routing policy — centralize tier selection in one module or gateway rule.
- Instrument fallback paths — log every tier escalation; alert on fallback rate spikes.
- Review quarterly — model updates shift the Pareto frontier. Re-run evals when Anthropic announces a new version.
The bottom line
The Claude Opus Sonnet Haiku naming system is a decision framework disguised as branding. Each tier is a distinct contract: Opus for depth, Sonnet for breadth, Haiku for speed. Engineers who treat the names as routing keys — not suggestions — build systems that are cheaper, faster, and easier to debug. Run your evals, codify the routing, and stop guessing.