Choosing the right Claude model — Opus, Sonnet, or Haiku?
The question I get asked most: which model should this run on? A decision framework for matching model tier to task complexity, volume, and cost.
If there’s one question I get asked more than any other by engineers picking up AI tooling, it’s this: which model should I use? Claude ships in three tiers — Opus, Sonnet, and Haiku — and picking the wrong one means either overpaying for simple tasks or getting underwhelming results on complex ones. Most people pick by vibes. Here’s the framework I actually use.
TL;DR:
- Use Sonnet as your default — it handles most engineering tasks well at moderate cost.
- Escalate to Opus only for multi-step reasoning, agentic workflows, or architecture decisions.
- Use Haiku for high-volume, well-defined tasks like classification, extraction, and routing.
- Match model to task complexity, not to perceived importance — overspending on simple tasks is the most common mistake I see.
- For agentic systems, tier it: Opus for planning, Sonnet/Haiku for execution.
The lineup
| Model | Positioning |
|---|---|
| Opus | Most capable. Deep reasoning, complex multi-step tasks, agentic workflows |
| Sonnet | Balanced. Strong performance at moderate cost and latency |
| Haiku | Fastest and cheapest. High-throughput, low-complexity tasks |
Opus
The heavyweight — maximum intelligence for tasks where quality is the only metric that matters. Opus excels at deep reasoning, nuanced judgement, extended planning, and complex code generation. It handles ambiguity well and produces output that needs less human correction.
Reach for it when:
- Multi-file code generation and architectural reasoning
- Agentic workflows that plan, execute, and self-correct
- Complex analysis synthesising information from multiple sources
- A single reasoning error would cascade into a wrong outcome
- Writing that demands nuance or domain expertise
The trade: highest cost per token, slower responses, and complete overkill for tasks a simpler model handles correctly.
One opinion I’ll defend: if you’re building an autonomous agent that makes decisions without human checkpoints, Opus’s reliability on multi-step reasoning justifies the cost. The money you “save” using a cheaper model comes back as debugging time. I’ve watched it happen.
Sonnet
The workhorse — strong enough for most professional tasks, fast enough to stay interactive. Sonnet handles the vast majority of engineering work — code review, summarisation, Q&A over documentation, moderate code generation — with quality close to Opus at a fraction of the cost and latency.
Reach for it when:
- Day-to-day coding assistance (completions, refactoring, explaining code)
- Summarisation and document Q&A
- Chat interfaces where response time matters
- Well-scoped, bounded tool-use workflows
- Batch processing where volume makes Opus prohibitive
The trade: it struggles more than Opus with highly ambiguous prompts, and error rates climb on very long reasoning chains.
Sonnet is the correct default. Start here, escalate to Opus only when you observe quality gaps. Don’t start at Opus and “optimise down” — start at Sonnet and escalate up.
Haiku
The sprinter — built for speed and cost when the task is well-defined. Haiku is not a “worse Sonnet”; it’s a different tool for a different job. When the task is well-structured and the reasoning is shallow, Haiku delivers correct results at a fraction of the cost.
Reach for it when:
- Classification and routing (categorising requests, intent detection)
- Extraction from structured or semi-structured data
- Real-time applications with a tight latency budget
- High-volume pipelines processing thousands of items
- Simple transformations: formatting, translation, boilerplate
The trade: noticeably weaker on multi-step logic, disproportionately sensitive to vague prompts, and less reliable with long, intricate system prompts.
My rule of thumb: Haiku shines when you can write a prompt so clear the task is almost mechanical. If you find yourself piling on examples and edge-case instructions to compensate for its mistakes, that’s the signal to move up to Sonnet.
The decision, in three questions
- Is the task well-defined with low ambiguity?
- Yes, and volume is high or latency is critical → Haiku
- Yes, but volume is modest → Sonnet
- Does it need multi-step reasoning or self-correction?
- Yes → Opus
- No → Sonnet
- Still unsure? → Sonnet
Or the one-sentence version I use: if a junior engineer could do it correctly given clear instructions, use Haiku. If a senior engineer would handle it comfortably, use Sonnet. If it needs an architect thinking carefully, use Opus.
Comparison matrix
| Dimension | Opus | Sonnet | Haiku |
|---|---|---|---|
| Complex reasoning | ★★★★★ | ★★★★ | ★★ |
| Code generation | ★★★★★ | ★★★★ | ★★★ |
| Instruction following | ★★★★★ | ★★★★ | ★★★ |
| Speed (time to first token) | ★★ | ★★★★ | ★★★★★ |
| Speed (tokens per second) | ★★★ | ★★★★ | ★★★★★ |
| Cost efficiency | ★★ | ★★★★ | ★★★★★ |
| Agentic reliability | ★★★★★ | ★★★ | ★★ |
| Simple classification | ★★★★★ | ★★★★★ | ★★★★ |
| Long-context handling | ★★★★★ | ★★★★ | ★★★ |
Use case recipes
| Scenario | Model | Why |
|---|---|---|
| Autonomous coding agent (multi-file changes) | Opus | Must plan, execute, and self-correct without oversight |
| Code review bot in CI | Sonnet | Good judgement on code quality; moderate volume |
| Summarising meeting transcripts | Sonnet | Context understanding, not deep reasoning |
| Classifying inbound requests | Haiku | Well-defined categories, high volume |
| Generating unit tests from signatures | Sonnet | Needs to understand intent and edge cases |
| Extracting fields from documents | Haiku | Mechanical extraction, high volume |
| Architecture design from requirements | Opus | Trade-off weighing and multi-step planning |
| Translating documentation | Haiku | Straightforward transformation |
| Debugging complex production issues | Opus | Deep reasoning over logs, code, and context |
| Interactive internal chat assistant | Sonnet | Balance of quality and response time |
The money and latency part
Approximate ratios: Opus runs ~5x Sonnet on both input and output; Haiku ~0.2x Sonnet. That means Opus is roughly 25x Haiku per token. For a pipeline processing ten thousand documents a day, that’s the difference between a manageable bill and an uncomfortable conversation with whoever owns the budget.
Two things that bite people in practice:
- Latency compounds in agentic loops. An agent making fifteen tool calls on Opus feels slow. Consider Sonnet for most steps with Opus only at the planning/decision nodes.
- Prompt caching changes the economics. If you’re re-sending the same large system prompt thousands of times, enable caching. It’s free performance — ignoring it is just donating money to your provider.
Anti-patterns I keep seeing
| Anti-pattern | Why it’s wrong | Do instead |
|---|---|---|
| ”Always use Opus to be safe” | Wastes budget and latency with no quality benefit on simple tasks | Start with Sonnet, escalate on observed gaps |
| ”Always use Haiku to save money” | False economy — debugging bad output costs more than the tokens | Match capability to complexity |
| Haiku with vague prompts | Ambiguity degrades Haiku disproportionately | Sharpen the prompt or upgrade the model |
| Opus for classification | Hiring an architect to sort mail | Haiku handles it reliably |
| Never re-evaluating | Capabilities shift with every release | Re-benchmark quarterly |
When in doubt: Sonnet. It’s the right answer more often than most engineers expect.
References
- Claude models overview — capabilities, pricing, and selection guidance
- Prompt caching — cache reads at a fraction of base input cost
- Prompt engineering — when to improve the prompt vs. switch models