Guide

Claude Code effort levels: a practical guide to /effort (and Opus 5)

Q: Is the effort toggle new with Opus 5?

Not the parameter itself. output_config.effort has existed since Opus 4.5, and Claude Code has shipped /effort for earlier models. The five-level ladder is not new either — xhigh arrived with Opus 4.7, and Opus 4.7, Opus 4.8, Sonnet 5 and Fable 5 all carry the full range. What is genuinely new on Opus 5 is the rule that thinking cannot be disabled at xhigh or max, and the fact that a previously set level carries over instead of being reset to the model default.

Andrew Mercer July 29, 2026 · 8 min read

Claude Code effort levels: a practical guide to /effort (and Opus 5)

Raise effort when the model was lazy; switch models when it was ignorant. That is the whole decision, and it is Anthropic's own framing: when Claude gets something wrong, ask "did it not try hard enough, or did it not know enough?" A thoroughness gap — skipped a file, never ran the tests, abandoned the task midway — is an /effort problem. A knowledge or capability gap is a model problem. And for most tasks, Anthropic says plainly, you should just use the model's default effort level — so the useful question isn't "how high can I go", it's knowing the handful of cases where leaving the default earns its tokens.

What effort actually changes

The common misreading is that effort is a thinking dial. It isn't. Anthropic's docs are explicit that effort affects all tokens in the response, including text responses and explanations, tool calls and function arguments, and thinking (when active) — and that it "doesn't require thinking to be enabled."

In an agent loop, that shows up as a change in working style. At lower effort Claude combines operations into fewer tool calls, skips the preamble and uses terse confirmations. At higher effort it makes more tool calls, explains the plan before executing, and writes longer summaries and comments. Same model, different temperament. Anthropic also calls effort "a behavioral signal, not a strict token budget" — max doesn't buy a guaranteed number of reasoning tokens, it buys a Claude that acts like it has all the time in the world.

The five levels, by thinking behavior

Level	Thinking behavior (Anthropic's description)	Reach for it when
`max`	"Claude always thinks with no constraints on thinking depth"	One hard problem, cost is irrelevant, you'll wait
`xhigh`	"Always thinks deeply with extended exploration"	Unfamiliar codebase, long multi-file change
`high` (default)	"Almost always thinks"	Nearly everything — this is the API default
`medium`	"Moderate thinking. May skip thinking for simple queries"	Routine work on a model that's overqualified for it
`low`	"Minimizes thinking. Skips thinking for simple tasks where speed matters most"	Mechanical edits, formatting, quick lookups

Two things to file away. First, availability differs by model: Fable 5, Opus 5, Sonnet 5, Opus 4.8 and Opus 4.7 support all five, while Opus 4.6 and Sonnet 4.6 have no xhigh. If you set an unsupported level, Claude Code falls back to the highest supported level at or below the one you set — xhigh runs as high on Opus 4.6. It doesn't error, it just quietly does less than you asked.

Second, and easier to get burned by: "the effort scale is calibrated per model, so the same level name does not represent the same underlying value across models." Your medium on one model is not your medium on another. Anthropic's advice for Opus 5 specifically is to run a fresh effort sweep rather than reusing settings carried over from an earlier model.

A routing table you can actually use

Treat this as a starting point, not gospel — the honest answer is that the right level depends on your repo and your patience. But most people default too high and pay for it.

Task	Start at	Why
Rename a symbol, fix a lint error, reformat	`low`	No reasoning required; you want the edit, not the essay
Write a test for a function you can see	`low`–`medium`	Scoped, verifiable, cheap to redo if wrong
Implement a well-specified feature in familiar code	`high` (default)	The default exists for a reason
Debug something that survived two attempts	`xhigh`	The failure was thoroughness — exactly what effort buys
Multi-file refactor across unfamiliar code	`xhigh`	More tool calls and an up-front plan are the point
Architectural decision you'll live with for a year	`max`	Correctness dominates cost; use it sparingly
Long autonomous run you won't be watching	`high`–`xhigh`	Pair with background execution and notifications
Backgrind	The titlebar effort pill cycles `auto → low → medium → high → xhigh → max` without leaving the terminal, on both desktop and the phone/browser console. It's Claude-Code-only — Grindy's reasoning is pinned server-side.

How effort hits cost and usage limits

The mechanics are worth understanding because they explain both the bill and the truncation.

max_tokens is a hard cap; effort is soft guidance. Anthropic: "max_tokens is a hard cap on total output for the request, thinking and response text combined… effort is soft guidance." At high and above Claude "is more likely to exhaust the budget" — so a stop_reason: "max_tokens" means either raise max_tokens or lower effort.
Thinking tokens are billed as output tokens even when the thinking text isn't returned. usage.output_tokens_details.thinking_tokens tells you how many billed output tokens went to reasoning. On the API side, output is the expensive side of the meter — compare rates in our model pricing tracker or estimate a monthly figure with the cost calculator.
On subscriptions, effort is one of the few levers you have. Claude Code usage draws on a rolling five-hour window plus a weekly window shared across models, so switching models with /model doesn't restore access once you're limited (see usage limits). Anthropic's cost guide names lowering effort with /effort as a way to cut thinking spend, alongside disabling thinking in /config or setting MAX_THINKING_TOKENS. No published figure states how much faster max eats a plan window than medium, so anyone quoting you a multiplier is guessing.
Changing effort mid-conversation breaks the prompt cache. "The resolved effort value is rendered into the prompt, so changing it between requests invalidates cache breakpoints." Anthropic's worked example shows a request reading 3,546 cached tokens, then a following request that changed only effort from high to medium reporting cache_read_input_tokens=0 and re-writing all 3,546. Setting effort explicitly to the model's default is equivalent to omitting it and does not break the cache. Flipping levels mid-task is cheap, but it isn't free.

Setting it: every entry point, and the ones that lie to you

/effort with no argument opens an interactive slider; /effort <level> sets it directly; /effort auto resets to the model default. There's also the left/right arrows on the /model picker, a --effort launch flag, the CLAUDE_CODE_EFFORT_LEVEL env var, an effortLevel settings key (which accepts only low/medium/high/xhigh), and effort in skill or subagent frontmatter. Precedence runs env var > configured level > model default. Changes take effect immediately, without waiting for the current response to finish.

Three details that trip people up:

max doesn't persist. low/medium/high/xhigh carry across sessions; max is current-session-only unless you set it via the env var.
ultracode is not an effort level. It appears in the /effort menu, but it "is a Claude Code setting rather than a model effort level: it sends xhigh to the model and additionally has Claude orchestrate dynamic workflows for substantive tasks." Session-only, rejected by the persisted effortLevel setting and the env var, and --effort ultracode needs a recent Claude Code (older builds print Unknown --effort value 'ultracode' — check claude --version if you hit that). Where workflows are off, it just sets xhigh.
ultrathink doesn't change effort at all. The keyword anywhere in a prompt requests deeper reasoning for that turn only — "Claude Code recognizes the keyword and adds an in-context instruction. The effort level sent to the API is unchanged." And "think", "think hard", "think more" are passed through as ordinary prompt text; they are not recognized keywords. Half the prompt-engineering folklore on this dies right there.

One more: auto is a reset keyword, not a sixth level. The API accepts only low/medium/high/xhigh/max. Tools that show auto as a cycle position (ours included) are surfacing a UI convention, not an API value.

What's actually new on Opus 5

Press coverage has framed the effort toggle as an Opus 5 feature. It isn't — output_config.effort has existed since Opus 4.5 (three levels there: low, medium, high) and has been generally available across the Opus 4.6-and-later line, with the API default at high ("setting effort to 'high' produces exactly the same behavior as omitting the effort parameter entirely").

What is new on Opus 5, which launched July 24, 2026 at $5/$25 per million tokens:

Not the five-level ladder. xhigh arrived with Opus 4.7, and Opus 4.7, Opus 4.8, Sonnet 5 and Fable 5 all carry the full range. Opus 5 keeps it, with the API default at high.
Thinking cannot be disabled at xhigh or max — requests that set thinking: {"type": "disabled"} at those levels return a 400.
No model-default hold. On Fable 5, Opus 4.8 and Opus 4.7, Claude Code applies the model's default on first run and holds it across sessions until you choose explicitly. Opus 5 has no such hold: a level you previously set carries over. (Defaults are high on every model that supports effort, except Opus 4.7, which defaults to xhigh.)
A caveat worth internalizing: "Effort controls thinking volume, not visible response length: on Claude Opus 5, changing effort does not reliably shorten responses." If you want shorter answers, ask for shorter answers. And at xhigh/max, set a large max_tokens — Anthropic suggests starting at 64k.

Anthropic says Opus 5 comes "close to the frontier intelligence of Claude Fable 5 at half the price," and that "on CursorBench 3.2, at max effort, the model performs within 0.5% of Fable 5's peak score, but at half the cost per task." That's vendor-reported, and there is no published table of scores broken out by effort level — so treat any per-level benchmark delta you see as unsourced. If you want a real answer for your repo, run the comparison on your own code.

Frequently asked questions

What does the /effort setting actually change?

Effort is a behavioral signal that affects every token in the response — text, tool calls and function arguments, and thinking when it is active. Anthropic is explicit that it "doesn't require thinking to be enabled". At lower effort Claude combines operations into fewer tool calls, skips the preamble and confirms tersely; at higher effort it makes more tool calls, explains the plan first, and writes longer summaries and comments.

Should I raise effort or switch to a bigger model?

Anthropic's own heuristic is to ask whether the model did not try hard enough, or did not know enough. A thoroughness gap — it skipped a file, never ran the tests, abandoned the task midway — means raise effort. A knowledge or capability gap means pick a bigger model. Anthropic also says that for most tasks you should just use the model's default effort level.

Does higher effort burn my usage limits faster?

Mechanically, yes: thinking tokens are billed as output tokens even when the thinking text is not returned, and on subscription plans Claude Code draws on a rolling five-hour window plus a weekly window shared across models. Anthropic names lowering effort with /effort as one of the ways to cut thinking spend. No published figure states how much faster a given level consumes a plan window, so treat it as directional, not a multiplier.

Is the effort toggle new with Opus 5?

Not the parameter itself. output_config.effort has existed since Opus 4.5, and Claude Code has shipped /effort for earlier models. The five-level ladder is not new either — xhigh arrived with Opus 4.7, and Opus 4.7, Opus 4.8, Sonnet 5 and Fable 5 all carry the full range. What is genuinely new on Opus 5 is the rule that thinking cannot be disabled at xhigh or max, and the fact that a previously set level carries over instead of being reset to the model default.

Where Backgrind fits

Backgrind is a desktop overlay for macOS and Windows that PTY-wraps the CLI you already use — Claude Code, Cursor, Codex — or a hosted model (Grindy), floats it over any app including borderless-fullscreen games, and pings you only when the agent needs a decision or finishes. In BYO-CLI mode, agent content never touches our servers; we're the window, not the model.

The effort control shows up as a titlebar pill that cycles auto/low/medium/high/xhigh/max — it's sending the same /effort <level> keystrokes into the PTY that you'd type yourself, so there's no magic and nothing proprietary about it. The same pill is in the Live-mode browser console, which is the part that actually matters: dropping a long xhigh run to medium from your phone when you realise the remaining work is mechanical. The pill is Claude-Code-only; Grindy's reasoning is pinned server-side for cost control. And when one model's answer isn't enough, the Fusion council puts your own CLIs on the same question and has a chairman judge the split.

Sources

Effort parameter semantics and Opus 5 specifics: Anthropic — Effort. Per-level thinking behavior, token accounting and the prompt-cache example: Thinking, steering and cost. /effort entry points, per-model availability, ultracode and ultrathink: Claude Code model configuration and the slash-command reference. Usage windows and cost levers: Claude Code costs. Model-vs-effort routing heuristic: Anthropic — Choosing a model and effort level in Claude Code. Opus 5 pricing and the CursorBench claim (vendor-reported): Introducing Claude Opus 5.