Choosing a Claude model and effort level in Claude Code

An anthropic post by Lydia Hallie (Claude Code team) explaining the two “make the answer better” dials in claude-code — the model setting and the effort level — from first principles. The model setting swaps which set of frozen weights handles the request; effort is how much work Claude does per turn (files read, verification, how far it pushes before checking in), not just thinking time. The post builds up the inference pipeline (tokenization → next-token probabilities → one-token-at-a-time generation) to ground a practical heuristic: when Claude fails, ask did it not know enough (switch model) or not try hard enough (raise effort)? — and check the context first, because the fix is often upstream of either dial. Distilled to a concept page at model-and-effort-selection.

Source file: raw/2026-07-12-claude-model-effort-level.md. Ten diagrams rehosted; several carry the argument: the low-vs-high-effort comparison shows the same “fix the failing test” task at ~400 tokens (read → edit → “Fixed line 42.”) versus ~2,800 tokens (read test + source + config → think → edit → run tests → re-read to verify → root-cause answer); the decision tree renders the heuristic (skipped a file / didn’t run tests → raise effort; read everything, clearly tried, still confidently wrong → switch model; neither → fix the input); the two illustrative quality-vs-tokens charts show curves converging on easy tasks and diverging on hard ones, captioned “Model picks the curve. Effort picks how far right Claude is willing to travel” and “Effort is a spending disposition, not a token target.”

Summary

What the model setting is

One API request carries system prompt + tool definitions + CLAUDE.md + history + files + your message. Server-side, text is tokenized to integers; the model computes a probability for every vocabulary token and picks from the top; weights are read-only at inference — nothing in the prompt or CLAUDE.md changes them. Context steers the prediction (well), but doesn’t teach: docs of a post-training library influence one request only. Hallucination is the weights producing a plausible-looking sequence from training patterns, not a failed lookup. Generation is one token per full pass — a 200-token response is 200 passes — which is where wait time and output cost come from. Model choice therefore sets capability range and per-token price, but not how many tokens get generated.

What effort is

All of Claude’s output — thinking, tool calls, text to you — is ordinary output tokens from the same loop at the same rate; earlier reasoning re-enters context like a read file. Effort level is sent with the request, and the behavior for each level was trained into the weights: it sets how thorough and certain Claude must be before considering the task done, reconsidered every turn. Higher effort → deeper plans, more verification, more double-checking of alternative hypotheses (illustratively ~7× the tokens on the same prompt); lower effort → Claude would rather ask you than spend tokens figuring it out. Plans are not frozen: when step 1 of a three-hypothesis debug finds the bug, the rest is skipped explicitly. The team tunes against “overthinking” in training — higher effort doesn’t artificially inflate usage on simple tasks.

The guidance

• Use the model’s default effort for most tasks; treat effort as a general preference by domain/work-type, not a per-task knob.
• Smaller models for routine, precisely-describable work; larger models for genuinely hard problems (subtle bugs, unfamiliar domains, architecture) and ambiguity — smaller models want specific instructions.
• The mnemonic: Fable is a specialist (seen problems almost no one else has; even at low effort spots what no one else would), Opus is the expert (low effort = five minutes with someone who’s seen your problem class), Sonnet is a really good generalist (high effort = a whole afternoon reading everything, ending up understanding your code thoroughly). Model ≈ how capable; effort ≈ how thorough; most real tasks need some of both.
• Token economics: on routine work the curves converge — the larger model just double-checks more expensively, so dropping down saves real money at no quality cost. On hard multi-step work the smaller model grinds toward its limit while the larger reaches the bar in fewer steps — total cost per task can come out lower on the larger model, and Fable finishes jobs Opus and Sonnet can’t reach at any effort level.
• Effort shapes but doesn’t cap consumption. The only hard cap is max_tokens (blunt, mid-stream truncation, API-facing); task budgets and “keep it brief” are advisory guidance the model is trained to follow — it wraps up near the limit rather than hitting a wall.

Key claims

• Effort controls files read, verification depth, and how far Claude pushes through multi-step work before checking in — more than “thinking time.” (model-and-effort-selection)
• Weights are fixed at inference; prompt/context steer but never teach. (pretraining, context-engineering)
• Effort-level behavior is trained into the weights; the level arrives as one more input the model responds to. (reasoning-models)
• If Claude had the context, clearly tried, and is still confidently wrong → larger model. If it skipped a file, didn’t run tests, or bailed partway → higher effort. If neither → fix the input (context, CLAUDE.md, task scoping). (model-and-effort-selection)
• Opus 4.8 at default effort produces better results for about the same tokens as Opus 4.7 at default effort (Anthropic’s own testing, at the Opus 4.8 launch).
• On tasks that stretch the smaller model, the larger model’s total cost per task can be lower despite the higher per-token price; Fable pulls furthest ahead on long multi-step work.
• max_tokens is the only hard cap; task budgets are advisory-by-training, not enforced.

Notable quotes

Effort means more than just “thinking time.” Effort level controls how much work Claude does on your request overall.

When Claude gets something wrong, your first instinct shouldn’t be to adjust a knob, but to examine the context you have provided.

The model setting is roughly how capable; the effort setting is roughly how thorough. Most real tasks need some of both.

Open questions

• No benchmark data. Both quality-vs-tokens charts are explicitly illustrative; the “~7× tokens at high effort” and “~400 vs ~2,800 tokens” figures are labeled illustrative too. The Opus 4.8-vs-4.7 claim is the post’s only empirical datapoint, and it’s unquantified (“better results for about the same number of tokens”).
• How effort interacts with loop stop conditions. The companion post‘s turn-based diagram says the loop exits when Claude judges the task complete “or the effort budget runs out” — but this post says effort shapes rather than caps consumption. Whether “effort budget” in the loop post is the same trained disposition or a separate mechanism is unclear across the two posts.
• Where “max” effort sits. The clipper description mentioned low/medium/high/max levels, but the body never enumerates them or names defaults per model — the actual level list and per-model defaults need the docs, not this post.

Pointers

• model-and-effort-selection — the concept page distilled from this source: the two dials, the failure-triage heuristic, and the token economics.
• reasoning-models — effort generalizes that page’s inference-budget-allocation story: RL taught the model when to think; effort is a user-facing dial over the same trained disposition.
• context-engineering — the “steering, not teaching” frame is the mechanism-level justification for that page’s whole discipline; also “fix the input first” as triage step zero.
• claude-code — the effort setting joins the entity page’s product surface.
• loop-engineering / 2026-07-12-loop-engineering-getting-started — companion post; model + effort named the biggest levers on what a loop costs.