Jonathon's AI Wiki

Model vs. Effort — What Each Setting Actually Does (Claude Code)

9 min read

Source: ai-research/claudedevs-model-vs-effort-explainer-2026-07-12.md — first-party @ClaudeDevs long-form X article (2026-07-08, x.com/ClaudeDevs/status/2074900291062034618), written by @lydiahallie (Lydia Hallie), member of technical staff on the Claude Code team; surfaced via the user’s bookmarks (raw/x-bookmarks-recent-digest-2026-07-13.md). Corroborated 2026-07-16 by ai-research/claude-blog-model-and-effort-level.md, the canonical republish at claude.com/blog/claude-model-and-effort-level-in-claude-code (published 2026-07-07, per the dated related-posts sidebar on Anthropic’s steering-Claude-Code post — the blog itself doesn’t carry a visible dateline) — surfaced via a direct link in the loop-engineering post. Direct-diffed against the X-article: same underlying piece (identical structure, examples, and framing throughout) but reworded sentence-by-sentence, not a byte-identical copy — an editorial adaptation for the blog format. No claims changed; adds 7 embedded diagrams (confirming the X-thread’s “graphs above” reference was real, though their visual content still isn’t captured by text extraction) and the two doc links folded into the max_tokens bullet below. Refreshed 2026-07-17 with a token-frugality checklist from raw/x-bookmarks-recent-digest-2026-07-18.md (@shannholmberg bookmark) — folded the subagent-effort-inheritance and cheap-orchestrator points into Key Takeaways / Try It.

Claude Code exposes two settings that both seem to “make the answer better”: the model and the effort level. This first-party explainer pins down what each one actually controls — the model swaps which set of frozen weights (and per-token price) handles the request; effort is a trained-in input that sets how thorough and how certain Claude must be before it considers the task done — and gives a concrete decision heuristic for which one to change when results disappoint. It is the canonical successor to the conference-talk framing in The Thinking Lever, written for the Fable 5 / Opus 4.8 / Sonnet 5 lineup.

Key Takeaways

  • Effort is more than “thinking time.” It controls how much work Claude does on the request overall: how long it thinks, how many files it reads, how much it verifies, and how far it pushes through a multi-step task before checking in. At low effort Claude would rather ask you for context than spend tokens figuring things out on its own.
  • Effort is a trained-in input, not a throttle. The effort level is sent to the model alongside the prompt; behavior at each level is baked into the weights during training. It sets the confidence bar for “done,” re-weighed every turn. Higher effort raises double-checking, but doesn’t artificially inflate usage on simple tasks — “overthinking” is specifically trained against as it degrades effectiveness.
  • The model setting swaps frozen weights and the per-token price — nothing else. It does not decide how many tokens get generated (that’s effort plus the task). Context can steer a model’s predictions but never teaches it: docs in context influence one request; the weights retain nothing. Hallucinated APIs are plausible token sequences from training patterns, not failed lookups.
  • The decision heuristic: when output is wrong, check the context first (prompt clarity, tools, skills). If context was fine — did it not know enough, or did it not try hard enough? Not knowing enough is a model problem; not trying hard enough is an effort problem (skipped a file, didn’t run tests, didn’t double-check → raise effort, especially if you’d set it below default).
  • Specialist / expert / generalist framing: Fable 5 is the specialist you call when everyone else is stuck (even at low effort it spots what others can’t — that recognition is what you pay for); Opus is the expert (low effort = five minutes with someone who’s seen your problem class before); Sonnet is the strong generalist (high effort = the generalist with the whole afternoon who reads everything and double-checks). Model ≈ how capable; effort ≈ how thorough.
  • Token economics flip with task difficulty. On routine work, the smaller model matches quality at lower cost (the larger one just adds verification steps at a higher per-token price) — drop down for routine stretches. On hard multi-step work the equation inverts: the larger model reaches the quality bar in fewer steps, so cost per task can come out lower on the pricier model — and Fable 5 “finished jobs Opus and Sonnet can’t reach at any effort level” (Anthropic’s testing).
  • Subagents inherit the parent’s effort — budget it there, not just on the main turn. Subagents run at the session’s effort/thinking configuration unless you lower it (first-party-confirmed: v2.1.198 made subagents and context compaction inherit the session’s extended-thinking config, per the CLI reference), so a swarm dispatched at max can spend a whole usage window in a single message. Keep delegated/parallel work at a lower effort than the orchestrating turn — and for long runs, consider a cheaper model as the orchestrator, calling the expensive one only for the hard-reasoning step. ^[inferred — operational usage-stretching guidance from @shannholmberg’s bookmarked checklist (raw/x-bookmarks-recent-digest-2026-07-18.md); the effort-inheritance mechanism it relies on is first-party-corroborated in the CLI reference (v2.1.198), and the cheap-orchestrator split is one of the topologies in Cheap-Executor Delegation]
  • Defaults are tuned: use the model’s default effort for most tasks and treat effort as a standing preference, not a per-task dial. Anthropic’s testing: Opus 4.8’s default effort produces better results for about the same tokens as Opus 4.7’s default on the same task.
  • max_tokens is the only hard cap (a blunt mid-stream truncation, mostly relevant to API developers). Task budgets and “keep it brief” prompts are soft, trained-to-follow guidance — Claude wraps up as it nears the limit rather than hitting a wall.

The one-line summary

Effort changes how much work Claude does. The model changes what Claude knows.

How this extends the wiki’s existing coverage

  • The Thinking Lever (Bleifer, May 2026) explained test-time compute, adaptive thinking, and the effort dial for the Opus 4.7 generation. This article is the July-2026 first-party sequel: it adds the non-thinking dimensions of effort (file reads, verification depth, check-in distance, ask-vs-explore preference), the “trained-in input” mechanism, and the model-vs-effort decision heuristic Bleifer’s talk left implicit.
  • The routine-vs-hard cost crossover gives first-party confirmation to the community-derived economics in Cost & Intelligence Levers and Cheap-Executor Delegation — “frontier model as judgment-minority” is exactly the “specialist you save for what needs it” framing here.
  • The “check context before touching either setting” rule is the same upstream-first discipline as Troubleshooting Claude and the effort table in Prompting Claude Fable 5.

The cost axis effort hides: fan-out (2026-08-25 addition)

A field report worth folding into the effort decision. An r/ClaudeCode user (score 20, 18 comments) asked for an xhigh /code-review on a 430-line script and reports Claude immediately attempting to spawn 10 Fable-level subagents; stopped at five, ~200k tokens were already gone.

Unverified, single report. But it names a cost axis this article’s framing does not: effort does not only make one model think longer, it can multiply how many models get spawned. The bill is closer to effort × agents × model price than to effort alone, and the multiplier is invisible at the moment you choose the flag.

The practical adjustment: scale review effort to the size of the diff, not to how much the change matters to you. A 430-line script does not need a panel. Reserve xhigh/max fan-out for changes where the blast radius genuinely justifies parallel independent review.

The routing question when the cheaper model is a different vendor (2026-08-25)

This article’s decision is in-family — which Claude model, at which effort. A related decision has the same shape but crosses a provider boundary: when to hand a job to a much cheaper third-party model inside the same harness.

The heuristic that source offers is compatible with this one and worth borrowing: send work where there is a clear target, a definition of done, worked examples in the repo, and tests that can judge the result; keep work where the hard part is deciding what the job should be, where there is hidden state, or where a risky trade-off needs weighing. Its diagnostic is unusually crisp — if you would have to hand over the entire conversation transcript for the other model to continue, the job is too unbounded to delegate. See Running a Cheap Model Beside Your Expensive One.

Try It

  1. Adopt the heuristic verbatim. Next time a result disappoints: (1) re-check prompt/tools/skills context; (2) if context was fine, classify the failure — didn’t know (subtle bug, unfamiliar domain, confidently wrong regardless of context) → bigger model; didn’t try (skipped file, no tests run, no double-check) → higher effort.
  2. Stop per-task effort fiddling. Set effort once as a domain preference (per this article, the default is tuned to what most people want to spend) and only override deliberately.
  3. Route by the crossover. Routine stretch → drop a model tier at no quality cost. Genuinely hard multi-step work → the pricier model is often cheaper per task, not just better. Pair with the advisor strategy to get the specialist’s judgment at minority-share prices.
  4. Prefer soft budgets over max_tokens. Task budgets and brevity asks are trained-to-follow guidance; max_tokens truncates mid-stream.
  5. Lower effort on subagents before a fan-out. They inherit the orchestrating turn’s effort, so drop it for delegated/parallel work — a max-effort swarm can spend a usage window in one message. For long unattended runs, orchestrate with a cheaper model and reserve the expensive one for the hard-reasoning subtask.

Open Questions

  • Does effort deterministically drive subagent count? One unverified field report suggests xhigh code review fans out to ~10 agents regardless of diff size. Neither the mechanism nor a documented cap is published.

  • Partially resolved 2026-07-16: the canonical blog republish confirms the graphs are real embedded diagrams (7 in that post — message assembly, tokenization, weights, effort-per-turn, and the routine-vs-hard-work cost curves) — but they ship as images with no alt text, so the exact curve shapes (and whether they’re per-model benchmark data) remain uncaptured by text extraction.

  • The article names no canonical effort-level list — the Thinking Lever taxonomy question (“extra high” vs low/medium/high/max/xhigh) remains open.

Graph View

Backlinks