Model Efficiency: When to Use Fable, Opus, Sonnet, and Haiku

There's a reflex worth resisting: reaching for the biggest model every single time. It feels safe — if the strongest model is the smartest, why use anything else? But "strongest" and "right for this task" aren't the same thing. Most of what I do in a day doesn't need the top of the range, and always using it costs me speed, burns through my usage limits faster, and sometimes even makes the answer worse. This post is about picking the model that fits the job.

The problem: the strongest model isn't free

Say the current lineup runs from a lightweight model up to the most capable one. The instinct is to pin everything to the top. Here's what that instinct ignores:

• It's slower. Bigger models — and higher "effort" settings — think longer before they answer. On the heaviest model at a high effort, a single hard task can run for minutes. That's a fine trade for a gnarly refactor; it's a terrible trade for "rename this variable."
• It burns your limits faster. On a subscription plan you have a rolling usage cap (see the earlier post on the status line). The heavier the model, the faster you eat that cap. Spend it on trivial edits and you'll hit a wall right when you need the big model for something hard.
• It costs more. On the API the price gap between tiers is several times per token. Even on a plan where you don't see a per-token bill, the "cost" shows up as how quickly your limit drains.
• It can overthink. This is the surprising one. On simple, well-scoped tasks the most capable models — especially at high effort — sometimes explore more than the task needs: extra abstractions, unrequested tidying, long deliberation over a one-line change. A smaller model, or a lower effort, just does the thing.

So the goal isn't "always strongest." It's match the model to the task — big enough to succeed, no bigger.

The lineup, in plain terms

Model names and tiers change over time, but they sort into four rough jobs. Today those are Haiku, Sonnet, Opus, and Fable — lightest to heaviest.

A useful way to read that table: Sonnet is the honest default for coding. It reaches close to the top tier on most real work while costing a fraction of it. Reach up to Opus or Fable when a task is genuinely hard or long-running, and reach down to Haiku when it's genuinely simple. The extremes are for the extremes.

If you want the actual spread, here's the API list price per million tokens (input / output). Even if you're on a plan and never see this bill, the ratios show how much heavier each step is:

Output tokens from the heaviest model cost ten times the lightest. That's the price of using it for something a lighter model would have nailed.

The second dial: effort

Model choice isn't the only lever. Most current models also take an effort setting — how hard the model works before answering. It runs from low through medium, high, xhigh, up to max. Higher effort means more thinking, more thoroughness, more tokens, and more time; lower effort means a faster, terser, more direct answer.

This matters because effort and model are independent knobs. You don't have to jump to a bigger model to get more depth — sometimes the same model at a higher effort is the better move. And often the win is the other direction:

• low — simple tasks and subagents. Fewer, more consolidated tool calls, less preamble.
• high — the sweet spot for most real work. Good depth without runaway spend.
• xhigh — the setting to reach for on the hardest coding and agentic tasks.
• max — when correctness matters more than cost or speed, and nothing less.

A practical combination: keep a capable model but drop the effort for a batch of easy edits, then raise it for the one hard problem in the session. Two dials, tuned to the task, beat one dial pinned to the top.

How this looks in Claude Code

You don't have to commit to one model for a whole session. In Claude Code:

• /model switches the active model mid-session — go light for a stretch of simple work, heavy for the hard part.
• The effort level is a setting you can raise or lower; the status line can show which one is active (again, see the status-line post), so you always know how hard the model is working.
• Some tiers offer a fast mode that trades a premium for higher output speed when latency matters more than cost.

The point is that these are cheap to change. Switching models or effort mid-session costs you a keystroke, not a restart.

A rule of thumb to steal

• Default to the balanced model (Sonnet today) for coding. It's close to the top on most tasks at a fraction of the weight.
• Reach up (Opus, then Fable) only when the task is genuinely hard or long-running — a big migration, deep debugging, an overnight autonomous run.
• Reach down (Haiku) for simple, high-volume, latency-sensitive work.
• Use effort as a second dial — high for most work, xhigh/max for the hard problems, low for the easy ones and for subagents.
• Watch your usage limits. If you're burning your cap on trivial edits with the heaviest model, that's the signal to step down.

The strongest model is a tool, not a default. Save it for the problems that actually need it, and everything else gets faster, cheaper, and — often enough — better.