Skip to content

Sonnet vs Haiku vs Opus: How to Pick the Right Claude Model for Coding

Problem

When I first got Claude Pro, I flipped between Sonnet, Haiku, and Opus by feel. I defaulted to “whatever I opened the session with” and paid Opus prices for tasks Sonnet would have done correctly.

I asked myself: is there a routing rule I can follow on every prompt so the budget stops being a surprise?

The answer was yes. Sonnet handles 80% of real coding work fine, Haiku is the right tier for bulk reads and transformations, and Opus is for the things that actually need long-horizon reasoning. The trick is making the rule deliberate, because Claude Code has no built-in router.

In this post, I will show the three routing rules I use on every prompt.

Environment

  • Claude Pro plan ($20/month)
  • Claude Code CLI on macOS
  • Sonnet 4.6, Haiku 4.5, Opus 4.8

The routing mental model

Most users on a Pro plan flip between models by feel. I used to do the same. The result was either a 4pm cap or wasted Opus tokens on a docstring rewrite.

The community converged on a clear rule. The original poster (score 81) said: “I rely on Sonnet 4.6 for heavy lifting with 200k context window. I offload structuring, docs, and sub-agents to Haiku, and save Opus strictly for planning and complex problems.”

Sndman11 (score 32) put it more bluntly: “For Opus specifically, only use it when you genuinely need multi step reasoning or strategy. Most editing, formatting, and summarizing work is overkill for Opus. Sonnet handles 80% of real work fine.”

I made this rule visual so I do not have to re-derive it every session.

TaskComplexity routing flow: ROUTINE to Spark, MODERATE to GPT-5.4 High with Spark fallback, COMPLEX to Fable with GPT-5.4 High fallback

The complexity of the task picks the model. That is the rule.

How to solve it?

I use three rules in order: by task type, by session mode, by phase.

Rule 1: Route by task type

I ask one question before every prompt: what kind of work is this?

Routing by task
- Is the answer already in the code or docs? -> Haiku
- Am I writing/editing real product code? -> Sonnet
- Am I deciding how the system should be shaped? -> Opus

Haiku handles read-only or transformation tasks: summarize a file, reformat JSON, write tests against an existing function, generate boilerplate. Sonnet is the default coding loop. Opus is for hard decisions and planning.

Rule 2: Route by session mode

In Claude Code, the model switch is one command:

Model switch commands
/model sonnet # default for the session
/model opus # switch the current session to Opus
/model opusplan # plan with Opus, execute with Sonnet

/model opusplan is the built-in pattern for “decide, then build.” ZyxilWCW (score 1) recommended it directly: “use /model opusplan.”

Here is the workflow in practice:

OpusPlan example
> /model opusplan
> Add a CSV export endpoint to /api/reports that
> streams 100k rows, validates each, and writes to S3.
> Plan first, then implement.
# Opus drafts the plan; Sonnet writes the code.

I treat /model opusplan as the default for any non-trivial feature. It gives me Opus-quality planning with Sonnet-cost implementation.

Rule 3: Route by phase

Even within a single project, the right model changes by phase:

Phase-based routing
- Plan with Opus
- Implement with Sonnet
- Review and refactor with Sonnet
- Docstrings the reviewer just asked for -> Haiku
- Next architecture question -> fresh Opus session

CriticalTemperature1 (score 1) reinforced the pattern: “Spend most of your time planning and then once you’ve gotten a really good plan, then you can just give the plan to a cheaper model and get it done very quickly.”

Pair the model switch with a HANDOFF

If I need to switch models mid-task, I write a HANDOFF first. Mixing model “personalities” mid-task is what loses working memory.

HANDOFF before a model switch
> Write HANDOFF-2026-06-29-1430.md summarizing:
> - the in-progress refactor of the auth middleware
> - the agreed approach (session cookies + rotating refresh)
> - open TODOs and known gotchas
# Switch to a fresh Sonnet session and paste the file
# as the first message. Avoids paying for a long context
# twice and avoids mixing model "personalities" mid-task.

The reason

I think the key reasons the routing rule matters are:

  • Cost multiplier is large. The cost difference between Haiku and Opus is roughly 4x per token. Multiplied across a hundred prompts a day, that is the difference between a plan that lasts a week and one that dies at 3pm.
  • No built-in router. Anthropic gives you three tiers but does not pick for you. The rule has to be deliberate, otherwise you default to “whatever I opened with.”
  • Opus pays off on hard problems, not daily work. Ok_Candle_5902 (score 2) said: “using Opus slowed me down on daily usage, but also compacted time I expended coding.” The honest trade-off is that Opus is more expensive per prompt but cheaper per finished feature on hard problems.
  • /model opusplan is not the same as opus. OpusPlan only uses Opus for the planning step, not for the whole session. Using opus when you meant opusplan is the most common cost mistake I see.

Common mistakes

  • Starting every session in Opus because “I might need the smart one.”
  • Using Sonnet for a 30-file architecture review that needs long-horizon reasoning.
  • Switching models mid-session without first writing a HANDOFF file, losing the working memory of the previous model.
  • Believing /model opusplan is the same as /model opus. It is not; OpusPlan only uses Opus for the planning step.

When an all-Opus workflow is fine

lynneff (score 2) made the case for a focused all-Opus session: “20 quid a month plan opus 4.8 high for everything, i get about 90 minutes work done hit the playtime limit.”

That works for short, focused sessions where the project state is small and the value of long-horizon reasoning is high. The moment the project grows past a few hours of work, tiered routing pays off.

Summary

In this post, I showed how to route work across Haiku, Sonnet, and Opus in Claude Code. The key point is: Sonnet by default, Haiku for bulk, Opus for strategy, and /model opusplan whenever the next step is “decide, then build.” Pair it with a HANDOFF file whenever you switch models, and the budget problem largely solves itself.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments