Low effort in Claude Code keeps you in the loop

The author of a new Claude Code guide to effort, announced on Twitter, now uses max effort for basically two jobs: runs where they want to give zero input, and hunts for security vulnerabilities. For most other work, especially when they want to stay in the loop, they reach for low effort far more often.

The full write-up lives on Anthropic's new claude.dev developer blog, with interactive explainers of benchmarks and demos. The author says they dug into evals, ran their own tests, and were quite surprised by what came out.

At a glance

• The claude.dev post takes on a practical question: what effort really does, when to change it, and why max effort is not the sensible default for every task in Claude Code.
• According to the post, on low effort Claude asks you for more context instead of spending tokens to work things out alone, and extra effort paid off most in hardware, code review and security.
• The catch: the tests are the author's own, and the per-level benchmark numbers sit in the blog's interactive explainers rather than in the announcement itself.

According to Anthropic, the mechanism behind Claude Code's effort setting goes back to extended thinking, introduced with Claude 3.7 Sonnet. Users could toggle an extended thinking mode on or off, and developers could set a thinking budget to control precisely how long Claude spends on a problem. Anthropic also made that thinking visible in raw form, saying it makes Claude's answers easier to understand and check.

The author uses low effort to stay in the loop and saves max for two jobs

According to claude.com, the effort parameter controls how many tokens Claude spends when responding to a request. It gives the model an approximation of how much compute you want spent on the task.

The bottom of the scale behaves in a way you might not expect. On low effort, per the same write-up, Claude asks you for more context rather than spending tokens figuring something out on its own. The author's own habit lines up with that, in their words:

I use effort low a lot more when I want to stay in the loop, and effort max is basically only if I want zero input or want to find security vulnerabilities.

So the two ends of the dial suit two different ways of working. Low keeps the conversation going and hands you the decisions. Max, as the author uses it, is for the moments when you would rather not be asked anything at all, or when the job is finding holes in code.

Where does extra effort pay off?

According to claude.com, extra effort gave better results where verification and edge-case testing were more useful: hardware, code review and security. Security is also one of the two cases where the author still defaults to max.

The claude.dev Blog post adds a concrete demo. Redesigning the Claude Code /config menu at low effort took 1 minute and produced an interactive sketch that conveyed the idea but did not look much like Claude Code. At max effort the same job took 28 minutes and produced a mockup that looked very much like Claude Code.

For the benchmark side, the claude.dev Blog says the author used Terminal-Bench 3.0, with the same 70 tasks for every model and GPU tasks excluded. The post calls the effort curves of Fable 5.1 and Opus 5.5 its best yet: at each level, both benchmark scores and tokens consumed tick upward. Opus 5.5 ran about three weeks later, with responses capped at 128k tokens and no GitHub or PyPI access.

What does an effort level actually change?

In the Claude Platform Docs, extended thinking is set per request with a thinking token budget, budget_tokens, and Claude thinks against it before starting its final answer. The docs set a minimum of 1,024 tokens and require the budget to be less than max_tokens, because thinking tokens count toward that limit for the turn.

The same docs describe Claude Opus 4.5 as the only extended-thinking-only model that supports effort. There the two are separate controls that must both be set: effort shapes the overall response, while budget_tokens sets thinking depth.

A third-party explainer from MindStudio describes Claude Code's four levels, low, medium, high and max, as setting how many tokens go to extended thinking before any output, with medium the default in most configurations. MindStudio says one max-effort prompt can sometimes consume 10x or more the tokens of the same prompt at low effort, depending on complexity.

Picture a contractor told how long to work before calling you. On a short allowance they phone early with questions. On a long one they measure twice and return with something finished, along with a bigger bill.

The post is open about its limits. The tests are the author's own, the announcement carries no benchmark numbers, and the Terminal-Bench runs were not identical, since Opus 5.5 ran later under a 128k cap. In our view, the most telling figure is the 1-minute low-effort sketch against the 28-minute max-effort mockup, which reads as a cost in waiting time as much as in tokens.

The scores behind the curves

The announcement does not say how wide the score gap between levels is, or how much of max's gain medium or high already captures on Terminal-Bench 3.0. If those numbers are published anywhere, it is in the interactive explainers on claude.dev. Until you have checked them, the author's split works as a starting point for your next session: low when you want Claude to ask, max when you want to walk away or audit security.