Best Claude model for coding: which one for which task
7m read time

Best Claude model for coding: which one for which task

How I route coding work across Haiku, Sonnet, Opus and Fable, and why picking a model is a cost discipline rather than a grab for the biggest one.

The short answer: Sonnet is my default for coding work, Haiku handles the mechanical high-volume work at the lowest cost, and I keep Opus for the work where judgement counts. Fable is the fourth, the tier you reach for once you have tried Opus and hit its ceiling, and it runs on the meter. The choice is driven by which models sit inside your subscription and which one you pay for per call.

There is a reflex I catch in myself and in almost everyone I talk to: reach for the biggest model, every time, for everything. The model picker becomes a single decision made once and never revisited. Whatever sits at the top of the list is what runs your commit messages, your rename-a-variable edits, and your gnarly concurrency bug alike.

That is the expensive habit. The top model is not the problem. Most of your coding work does not need it, and one of the tiers now costs you real money per use.

So here is how I actually route work across the lineup, and why I think about it as four tiers rather than one slider from cheap to smart.

The current lineup ​

As of 13 September 2026, these are the four tiers. Prices are API list prices per million tokens. In Claude Code you switch models with /model.

TierModelAPI IDContext windowInput / output
GlueHaiku 4.5claude-haiku-4-5200K$1 / $5
DefaultSonnet 5claude-sonnet-51M$2 / $10
JudgementOpus 5claude-opus-51M$5 / $25
Break-glassFable 5.1claude-fable-5-11M$10 / $50

The map that matters is access, not benchmarks ​

You can line the models up by capability and get a tidy ladder. That ladder is real, but it hides the line that actually changes your behaviour: which models come out of your included usage, and which one you pay for directly, per call.

Three of the four sit inside your plan. You route between them freely, and the only cost is speed and tokens against a budget you already have. The fourth is metered. Every time you use it, you are spending money that would otherwise stay in your pocket.

Beyond included and metered, access has a third state: gone. A model can be pulled worldwide overnight, so the habit worth having is knowing your second choice before you need it.

That split is the spine of every decision below. Reaching for Opus when Sonnet would do wastes budget. Reaching for the metered tier when Opus would do wastes cash.

The three included tiers ​

Haiku (roughly 1x) is the glue. High-volume, low-judgement work: mechanical edits, formatting passes, generating boilerplate, the hundred small string-replacements a refactor spreads across a codebase. It has a smaller context window than the others, but for glue work you are not feeding it a monorepo. When the task is "apply this obvious change in forty places", Haiku does it fast and you barely feel the cost.

Sonnet (roughly 2x) is my default now, and this is the shift most people have not made. Sonnet used to be the compromise you accepted when Opus was too slow or too expensive, but the current Sonnet has outgrown that role. On coding and agentic work it lands close enough to Opus that for the bulk of real feature work, writing a component, wiring an endpoint, fixing a normal bug, I cannot tell you it was the cheaper model from the output alone. It is also the first Sonnet tier that takes the high effort settings, which matters more than the model choice for a lot of tasks (more on that below).

If you are still defaulting to Opus for everything, try defaulting to Sonnet for a week. You will be surprised how rarely you miss the difference.

Opus (roughly 5x) is for judgement. The tasks where being mostly right is worse than being slow: a complex refactor across module boundaries, a design decision with real consequences, a bug where the obvious fix is wrong and you need the model to actually reason rather than pattern-match its way to something plausible. This is where the extra tokens buy you something you can feel. I reach for Opus deliberately, on the tasks that earn it, not as a background default.

Effort is the second dial ​

Model choice is only half the decision. Effort is the other half, and people forget it exists.

Sonnet, Opus and the top tier all take an xhigh effort setting, and for coding and agentic work that is the setting you want. A cheaper model at high effort often beats a pricier model at low effort, and usually costs less to get there, so the real grid is two-dimensional: which model, and how hard it thinks. Turning effort down on Haiku for glue work saves tokens you would never miss. Turning it up on Sonnet for a hard task can close most of the gap to Opus without leaving your included usage.

Treat both as cost levers. The model sets the ceiling, effort sets how much of that ceiling you actually pay for on this call.

One caveat that bit me later: effort values do not survive a model upgrade. Each release recalibrates what the five labels mean, so re-measure them when a new model lands instead of carrying the numbers over.

The tier you pay for on purpose ​

Fable is the top of the lineup, and it sits outside your included usage entirely. It is paid, metered, per-use. Every call spends money directly.

That access model, more than its price ratio, is what tells you when to use it. Fable is the break-glass tier: the hardest long-horizon agentic work, the overnight run that has to hold coherence across hours and hundreds of tool calls, the problem where you have already tried Opus and it is not enough. It is genuinely more capable at that ceiling. It is also the tier where you are consciously deciding the task is worth paying for out of pocket, which is a decision you should make on purpose and not by leaving a dropdown on its default.

I choose Fable deliberately, on the rare task that clears the bar, the same way I would decide to spend money on any other tool.

How I actually decide ​

The whole thing collapses to a few questions I run almost without thinking:

  • Is this mechanical? Haiku, low effort. Do not think about it.
  • Is this normal feature work or a normal bug? Sonnet, high or xhigh. This is most of my day.
  • Does being wrong here cost me hours, or ship a subtle bug? Opus, xhigh. Judgement work earns the tokens.
  • Have I already tried Opus and hit its ceiling on something genuinely hard and long-running? Fable, and I accept I am paying for it.

This is about spending attention and budget where they change the outcome. The best number in the Opus 4.8 announcement was never the benchmark, and the same instinct applies to picking a model day to day: the capability ceiling is the least interesting part of the decision. What matters is matching the tier to the task in front of you.

This is the same discipline I keep coming back to. Speed got cheap, judgement did not: the scarce resource in AI-assisted work is judgement, knowing what a task actually needs. Model routing is that judgement applied to your own spend. And it slots straight into how you set up Claude Code and work with an agent day to day: pick the tier per task, set the effort per task, and stop paying Opus prices for commit messages.

The default that runs everything through the biggest model feels safe. It is just quietly expensive, and now that one of those tiers bills you directly, the cost of not choosing has a number attached.

(20 of 39)
1My Claude Code setup: status line, plugins and terminal2Superpowers: teaching Claude Code to think before it types3Claude Code hooks: deterministic control over AI workflows4The CLAUDE.md file: give your AI permanent memory5Stop asking your agent nicely6What's new in Claude Code: notes from the London talk7The best number in Opus 4.8 isn't a benchmark8Stale memory is worse than no memory9The agent is just a loop10Build an MCP server, then ask whether it should exist11Skill, subagent, hook, or slash command? Pick the right one12Log in to MCP servers from your shell13How to give Claude safe access to your SQL database14The day 'default' became 'Manual'15Claude Code skills: how to write one that works16How to write a proper Claude Code subagent17Claude Code permissions: the guide I wish the docs were18Sandboxing Claude Code: put your agent in a box that holds19Prompt injection defense for developers who ship agents20Best Claude model for coding: which one for which task21Refactoring legacy code with a coding agent: start with characterization tests22MCP server authentication: OAuth, scopes and rate limits23Opus 5 is here and your effort settings just expired24AI agent incident response: what to do when your coding agent goes wrong25Claude Code doctor and /doctor: checks and differences26Claude Code context management: when to /clear and when to /compact27Git worktrees for parallel coding agents: what they isolate and what they share28Claude Code plan mode: decide before the agent writes29Debugging with a coding agent: give it the search, keep the hypothesis30Claude Code checkpoints and /rewind: how to undo an agent's changes31Claude Code cross-session messaging: how to make your sessions talk to each other32Audit logging for AI agents: what Claude Code records and what deserves a human33Sharing Claude Code config across a team: what a repo can and cannot enforce34Your Claude Code session has no clock35Claude Code in a large codebase: scoping an agent to the part that matters36Recovering a Claude Code session your picker will not show you37Where Claude Code spends its time: a month of my own sessions, measured38Steering Claude Code mid-task: Esc, queued messages and /btw39Claude Code auto mode: why your Agent allow rule does nothing