Jonathon's AI Wiki

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

6 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).

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).
  • 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.

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.

Open Questions

  • The post references cost/quality curve graphs (“the graphs above”) that the text-only fetch could not capture — the exact curve shapes (and whether they’re per-model benchmark data) are undocumented here.
  • 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