Jonathon's AI Wiki

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

12 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. Extended 2026-09-29 with a skills-at-low-effort rule from Chris of buildgreatproducts.com (raw/Claude_Fable_5.1_is_Amazing._Here_s_Everything_You_Need_to_Know.md) and Nate Herk’s model walk-down (raw/Build_Sell_with_Codex_5+_Hour_Course.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).
  • 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.

How the effort setting behaves in Claude Code (release notes, August–September 2026)

The “set it once as a standing preference” advice above got product support: effort is now stored per model, admins can cap it, and new models start fresh. From the anthropics/claude-code release notes (digests: W35 · W36 · W37 · W39 · W40):

  • Per-model memory (v2.1.251, 2026-08-28). /effort saves your default effort level per model, so each model keeps its own setting when you switch.
  • Session-only changes (v2.1.257, 2026-09-01). s in /effort changes effort for the current session only, matching /model; --effort lifts a new model’s default-effort hold for that session only rather than permanently.
  • Admin cap (v2.1.267, 2026-09-09). maxEffortLevel — top-level, or per model under modelSettings — caps effort on every provider including Bedrock, Vertex and Foundry; users can still pick a lower level. The same release fixed effort: frontmatter on custom commands, skills and subagents being ignored on models whose default effort is still pinned (Opus 4.7, Opus 4.8, Fable 5).
  • New models start at their default (v2.1.280, 2026-09-22). An effort level saved before /effort became per-model no longer applies to newly released models such as Opus 5.5; they start at their default until you pick. Opus 4.7, Opus 4.8 and Fable 5 stop holding their launch-default effort over /effort in -p or the Agent SDK, a project, managed or --settings effortLevel, or a per-model level.
  • Ultracode is no longer an effort level (v2.1.284, 2026-09-28). It is its own toggle in /effort (Tab, or /effort ultracode [on|off]), no longer forces xhigh, and stays on at any effort level. See Dynamic Workflows.
  • Thinking-off edge cases. Opus 5 requests at xhigh/max with thinking turned off are sent as high instead of failing (v2.1.251); Alt+T and /config no longer offer to turn thinking off on models that can’t (v2.1.281). Changing effort mid-session on Fable 5.1 no longer invalidates the prompt cache (v2.1.260).

Practical: if a team keeps hitting usage limits from high-effort fan-out (see the section above), maxEffortLevel is now the admin-side control.

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.

Skills make low effort viable (2026-09-29 addition)

Practitioner opinion from Chris (buildgreatproducts.com), “Claude Fable 5.1 is Amazing” (raw/Claude_Fable_5.1_is_Amazing._Here_s_Everything_You_Need_to_Know.md):

  • His split. Fable 5.1 on high is “a great sweet spot for heavier tasks and coding work”; Fable 5.1 on low is “a great daily driver or for knowledge work.”
  • The rule worth keeping: “codify your tasks into skills that you’re doing on a repeated basis,” then “run skills on low effort because the skill is really instructing the AI with exactly what it needs to do.”
  • His reading of Anthropic’s launch charts. Low and high are the sweet spots, and Fable 5.1 on low is “as good if not better in agentic terminal coding than Fable 5 on high.” He notes community reports on real-world cost have been mixed: “a lot of people have been saying otherwise.”
  • Why it fits this article’s heuristic. Effort buys exploration and verification. A skill writes the method and the definition of done down in advance, so there is less left for effort to buy.
  • The same idea across models. Nate Herk’s “walk it down” step runs a working skill on successively cheaper models (in Codex: Astra, then Sol, Terra, Luna) and keeps the cheapest one that gives the same output (raw/Build_Sell_with_Codex_5+_Hour_Course.md). See Build & Sell with Codex course.

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.
  6. Turn repeat tasks into skills, then lower their effort. Run the skill at low and at high effort and keep low if the output matches (Chris). Then walk the model down the same way until quality drops (Nate Herk).

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