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 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.
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 3x) 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.
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.