Picking a Claude model is really two decisions — which model and how much effort — and the more interesting question is who should make them: a config file, a skill, a cheap router model, or the most capable model delegating downward.
Model lineups, prices, and effort semantics move fast. This reflects the state as of August 2026 — verify current details in the Anthropic models overview before hardcoding anything.
The mental model: two dials, not a ladder
The intuitive picture of model choice is a ladder: small, medium, large — climb until the task works. That picture is a generation out of date. Since the effort parameter arrived, model choice is a two-dimensional grid: which model (the capability tier) times which effort (how hard that model thinks), and the second dial is often the cheaper one to turn.
The first dial is the capability tier:
The second dial is effort — a request parameter that controls how deeply the model reasons and how many tokens it spends doing it:
The two dials are different in kind, and the difference is physical. A model's weights — the billions of parameters that compute every answer — are fixed during training and read-only by the time a request arrives; context and prompting can steer the prediction, but they cannot add capability that isn't in the weights. That is why the model dial sets a hard ceiling while the effort dial only chooses how thoroughly the model works beneath it. Anthropic's guide to models and effort in Claude Code compresses it into one line: "the model setting is roughly how capable; the effort setting is roughly how thorough."
The grid matters because the same model at different effort levels behaves like different models. Opus 5 at low effort makes fewer, more consolidated tool calls, writes less preamble, and answers fast; at xhigh it plans, verifies its own work, and runs long. Before reaching for a bigger model, it is usually worth asking whether the current one just needs a different effort setting — and before reaching for a smaller one, whether lowering effort would capture most of the saving without changing tiers.
The lineup
Four models cover essentially every use case today. Prices are per million tokens (MTok) of input/output on the Anthropic application programming interface (API):
| Model | Capability | Input $/MTok | Output $/MTok | Context | Sweet spot |
|---|---|---|---|---|---|
| Fable 5 | $10 | $50 | 1M | Hardest reasoning, long-horizon autonomous work | |
| Opus 5 | $5 | $25 | 1M | Agentic coding, multi-file refactors, deep review | |
| Sonnet 5 | $3 | $15 | 1M | Everyday coding and agents — near-Opus quality at half the price | |
| Haiku 4.5 | $1 | $5 | 200K | Classification, extraction, high-volume simple tasks |
A few things the table doesn't show. Sonnet 5 is the surprise of this generation: on many coding and agentic benchmarks it reaches what used to be Opus-tier quality, which makes it the right default rather than the compromise. Opus 5 earns its price on the hard end — long autonomous sessions, gnarly refactors, code review with high recall — and, unusually, it stays accurate at low effort, which makes a cheap fast pass genuinely viable. Fable 5 is not the default upgrade path; it is the tier you reach for when the task is at the edge of what models can do at all, and its always-on thinking and pricing reflect that. Haiku 4.5 is not a lesser Sonnet — it is a different tool, built for the enormous volume of work where a large language model (LLM) is overkill: labeling, routing, extraction, reformatting.
The metaphor from the Claude Code guide makes the tiers tangible: Fable is "a specialist who's seen problems almost no one else has", Opus is "the expert", Sonnet is "a really good generalist" — and the effort dial decides how much time any of them spends on your problem. The cross-combinations are where the two-dial grid clicks into place. Opus at low effort is five minutes with an expert: sharp pattern recognition, but a quick surface read. Sonnet at high effort is the generalist taking the whole afternoon: a thorough working-through of the code, without the exotic pattern recognition. Fable at low effort is the specialist glancing at the problem — and sometimes the glance alone spots what nobody else would. None of these is universally better; they are different purchases.
The effort dial
Effort deserves its own table, because it controls more than most people expect. It is tempting to read it as "thinking time", but as the same guide puts it, effort "controls how much work Claude does on your request overall — including the number of files read, tools used, and how many steps it takes before it checks back in with you". Mechanically it is a learned behavior, not a hard limit: the level rides along with the request and the model was trained to respond to it, everything it produces — thinking, tool calls, text — is ordinary output tokens billed identically, and the same prompt at high effort can generate roughly seven times the tokens it would at a low setting. Turning the dial changes the whole shape of the work, not just the depth of the reasoning:
| Effort | Cost/latency | What it buys | Use for |
|---|---|---|---|
low | Terse, direct, consolidated tool calls | Subagents, lookups, latency-sensitive chat | |
medium | Balanced reasoning | Routine work; often the cost/quality sweet spot | |
high | The default — solid reasoning depth | Most intelligence-sensitive work | |
xhigh | Deep planning and self-verification | Hard coding and agentic tasks (Claude Code's default) | |
max | Everything the model has | Correctness-over-cost moments; can overthink simple tasks |
The practical rule: pick the model by the ceiling the task needs, then pick the effort by how close to that ceiling this particular request actually is. A capable model at low effort is frequently better than a weaker model at max effort — it keeps the ceiling available for the requests that need it, and on current models the low settings punch well above their weight. And the ceiling is not a metaphor: in Anthropic's testing, Fable "finished jobs Opus and Sonnet can't reach at any effort level" — no amount of the second dial substitutes for the first when the task is beyond the model.
Two refinements from the same guide are worth internalizing. First, the defaults are the intended resting point: "most of the time, you shouldn't be thinking about either setting." The default effort is "the level where Claude will scale its token usage according to what most people would want to spend on a task", a capable model at high effort "won't artificially inflate usage for simple tasks", and the dial is best treated as a standing preference for a domain of work — a manual override, not a per-request decision.
Second, when a result disappoints, don't reach for either dial first — check the inputs. Most failures are upstream: an ambiguous prompt, a missing tool or skill, pertinent files never provided. Only once the context is right does the clean diagnostic apply: did the model not try hard enough, or did it not know enough? Skipped files, unrun tests, a refactor abandoned halfway — that is an effort gap; turn the effort dial. A model that is confidently wrong no matter how much context you give it — that is a capability gap; turn the model dial.
The matrix
Putting both dials together, this is the decision table I actually use:
| Task | Model | Effort | Why |
|---|---|---|---|
| Classification, extraction, tagging | Haiku 4.5 | low | High volume, well-defined output; capability ceiling is low |
| Chat, lookups, short answers | Sonnet 5 | low–medium | Fast and cheap, with headroom if the conversation deepens |
| Everyday coding, scoped features | Sonnet 5 | high | Near-Opus quality at Sonnet cost |
| Hard agentic coding, multi-file refactors | Opus 5 | xhigh | Where the Opus premium pays for itself |
| Code review — fast pass | Opus 5 | low | Opus 5 stays accurate at low effort; cheap pre-merge check |
| Code review — thorough pass | Opus 5 | high–xhigh | High recall on real bugs |
| Long-horizon autonomous runs | Fable 5 | high–xhigh | Sustained coherence over hours of tool use |
| Correctness-critical one-offs | Opus 5 / Fable 5 | max | When being wrong costs more than the tokens |
| Subagent grunt work (search, mechanical edits) | Haiku 4.5 / Sonnet 5 | low | Scoped, verifiable, and reviewed by the orchestrator |
A caveat on how to use this: the matrix is routing policy — for systems that wire a model and effort per route ahead of time. Working interactively, the better habit is the defaults-first one from the previous section: start from each model's default effort and reach for the dials only when a result misses.
One trap to avoid when reading the matrix against the price list: price per token is not cost per task. On routine stretches, dropping to a smaller model saves real money at no quality cost — but on hard tasks the relationship inverts, because a larger model reaches the quality bar in fewer steps, fewer retries, and fewer follow-up corrections, so the total cost per task can come out lower despite the higher rate. Optimizing the per-token column of the lineup table is exactly how teams end up paying more.
That table is a policy. Which raises the real question: where should that policy live, and who should execute it?
Who should pick the model?
There are four candidate mechanisms, from dumbest to smartest:
- Hardcoded config. Each route in the application pins a model and effort. Zero runtime cost, fully auditable, and blind to anything unusual.
- A skill (deterministic policy). The matrix above written as instructions — a routing table the executing model applies. Still no extra LLM call; the policy is versioned text you can review and edit.
- A router agent. A dedicated cheap model classifies each request and dispatches it to the right tier. One extra LLM call per request.
- Top-down delegation. The most capable model owns the task and decides, mid-flight, which parts to hand down to cheaper models.
The two architectural extremes look like this:
The difference that matters is not who makes the first decision — it is who remains accountable for the result. In the bottom-up design, once the router sends a request to Haiku, no capable model ever sees it. In the top-down design, the cheap model only ever works on a scoped subtask, and its output flows back through the orchestrator, which can catch a bad result and redo it.
Can a small model pick the right model?
Yes — but only for a specific shape of problem, and not in the way one might hope.
The evidence for the bottom-up router is real. Anthropic's own Building Effective Agents lists routing as a core workflow pattern: classify the input, dispatch to a specialized handler — explicitly including "routing easy/common questions to smaller, cost-efficient models like Claude Haiku … and hard/unusual questions to more capable models". And RouteLLM, the router framework from the LMSYS (Large Model Systems) team, showed that a trained router choosing between a strong and a weak model could cut strong-model calls by about 40% while keeping over 95% of the quality on a multi-turn benchmark (MT-Bench) — with the full framework open-sourced.
But look at the fine print, because both sources carry the same caveat. Anthropic scopes the pattern to tasks "where there are distinct categories … and where classification can be handled accurately". RouteLLM's routers are not small models judging difficulty — they are classifiers trained on tens of thousands of human preference comparisons, learning statistical surface patterns that correlate with where the weak model historically failed.
That distinction is the whole answer: a small model can classify a request, but it cannot assess difficulty it doesn't understand — to know a problem is too hard for you, you generally have to be able to almost solve it. Ask Haiku "is this refactoring question hard?" and it will pattern-match on surface features; the requests it misjudges are precisely the deceptively-hard ones — the category where routing errors hurt most. And the failure is silent: the user gets a confident answer from the wrong tier, and nothing in the system knows.
Compare the error costs. When a top-down orchestrator wastes Opus on an easy question, the failure mode is a slightly higher bill and a correct answer. When a bottom-up router sends a hard question to Haiku, the failure mode is a wrong answer that nobody reviews. Downgrade errors cost money; upgrade-that-never-happened errors cost correctness — and only one of those failure modes announces itself.
So the honest verdict on the cheap router: use one when the traffic is high-volume and genuinely classification-shaped — distinct categories, recognizable from surface features, with an escalation path for low-confidence cases. Support triage, content moderation, intent detection. Do not use one as a general-purpose difficulty judge.
Top-down: how the real systems do it
For open-ended work, the pattern that ships in production is the opposite: the capable model sits at the top and delegates downward. Anthropic's agents guide calls it orchestrator-workers — a central LLM that "dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes results", recommended precisely "for complex tasks where you can't predict the subtasks needed".
Claude Code is the case study worth stealing from, because it answers the agent-versus-skill question in passing. Look at how subagents work there:
- Each subagent is a text file with frontmatter — and the model choice is a config field:
model: haikupins a cheap model to a role like exploration;model: sonnetto a mid-tier task. The docs list "control costs by routing tasks to faster, cheaper models like Haiku" as a headline reason subagents exist. - The decision of when to delegate is made by the main, capable model, reading each subagent's description. Nobody asks Haiku whether the task is hard; Opus decides that a search task fits the cheap explorer, hands it a scoped brief, and reviews what comes back.
- Nowhere in the loop is there an extra LLM whose only job is picking models.
That is the answer to "should it be an agent or a skill?". The routing policy belongs in deterministic, versioned configuration — a skill, an agent definition, a table like the matrix above — and the routing judgment belongs to the most capable model in the loop, applied top-down at delegation time. A dedicated router agent adds a per-request LLM call, a new failure point, and an un-reviewable decision, and buys you nothing that a config field plus a capable orchestrator doesn't already provide — unless you're operating at the high-volume, classification-shaped scale where a trained router earns its keep.
Putting it together
Three rules compress everything above:
- Turn the effort dial before the model dial. Same model at
lowvsxhighspans much of the range people switch models for, without losing the ceiling. - Never let a model you wouldn't trust with the task decide who gets the task. Small models classify; they don't judge difficulty. If a cheap router runs in front, it should be trained or rule-constrained, with escalation on doubt.
- Policy in config, judgment at the top. Write the matrix down as a skill or agent definition; let the most capable model in the loop apply it when it delegates. That way every model choice is either auditable text or a decision made by something smart enough to catch its own mistakes.
References
- Anthropic — Building Effective Agents
- Ong et al., RouteLLM: Learning to Route LLMs with Preference Data — arXiv
- LMSYS Org — RouteLLM: An Open-Source Framework for Cost-Effective LLM Routing
- Claude Code docs — Create custom subagents
- Anthropic docs — Effort parameter
- Anthropic — Claude model and effort level in Claude Code