Claude Code's effort, explained: spending time, not intelligence

Imagine a colleague drops a task on your desk and says: “You have twelve hours, take them.” You would read the brief twice, try the awkward cases, check your own work, maybe redo a part you are not happy with. Now picture the same colleague, the same task, but: “I need something in an hour.” You would not become dumber in that hour. You would simply aim for a good first version, hand it over, and expect to iterate together.

Nothing about your skills changed between the two scenes. Only the time you were allowed to spend, and therefore how much checking you could afford. That is exactly what the effort setting in Claude Code does.

The idea in one sentence

Effort does not make Claude smarter: it sets how much computing it spends, so how much it checks and tests edge cases.

What effort actually controls

In the post that inspired this article, Thariq Shihipar describes effort as giving the model an approximation of how much compute you want it to spend on a task, a bit like your own estimate of how hard the task is. Claude will always try to do the task reasonably. What changes with a higher effort is how much independent action it takes for judgement and verification.

The levels you will meet in Claude Code are low, medium, high, xhigh and max. On Fable 5.1 and Opus 5.5, each step up brings both a higher benchmark score and more tokens consumed. And one practical detail matters a lot: the models respond to effort without breaking the prompt cache, which is why you can change it in the middle of a conversation.

Back to the twelve-hour colleague. Taking your time does not make you more knowledgeable, and effort does not change what the model knows. It changes the shape of the work.

Where effort pays off: hidden edge cases

The clearest lesson from the source is that higher effort is best for tasks with lots of hidden edge cases. Its showcase is html-js-filter, a Terminal-Bench 3.0 task asking for an HTML sanitizer that strips every way of smuggling JavaScript into a page. Fable 5.1 went from 1/5 at low to 5/5 at xhigh.

The difference is in the behaviour, not in the knowledge. A typical low attempt took about 2 minutes: write a filter in roughly one pass, test it against a single hand-written page, done. A high-effort run took about 33 minutes: it reviewed its own first draft adversarially, read the installed parser’s source to look for bugs, ran a standard XSS test suite and finally wrote a random-document fuzzer. That is the twelve-hour colleague, in software form.

The same pattern shows up by domain. Fable 5.1’s pass rate grew a lot in hardware (34% to 75%) and security (64% to 87%), where verification matters, and much less in operations (12% to 22%), which is rulebook-style work.

What effort will not fix

Checking longer does not save a bad idea. The source lays out every Terminal-Bench 3.0 attempt by the way it failed. For Fable 5.1, going from low to max effort, out of 370 attempts, passes rose from 140 to 214 and failures from a missed case fell from 59 to 24. But failures where the model made the wrong call, such as misreading a requirement or picking the wrong reading of the problem, only went from 133 to 107.

So more effort reduces forgotten edge cases, not a bad approach. If the plan is wrong, an extra hour of careful testing just polishes the wrong thing. That is why the most useful thing you can do before turning the dial is to make sure the plan is right.

Which level for which job

There is a human side to the trade-off, too. Low effort lets Claude answer fast with a starting point while you stay in the loop. Higher effort gets more work done, but Claude also makes more assumptions on your behalf. On the underspecified prompt “build a personal fitness and workout tracker app”, low gave a log and a simple graph in 1.5 minutes; max took 67 minutes and added, among other things, a heat chart.

The author’s rule of thumb:

• Low: quick responses while you stay in the loop, such as brainstorming, sketching, easy changes.
• Medium: most regular software engineering, such as implementing a new feature.
• High: work where verification matters or edge cases lurk, such as fixing a bug in a brownfield codebase.
• Max: letting Claude work fully autonomously on hard problems, such as building and verifying an app end to end, or finding security vulnerabilities in critical software.

Try it

1. Change effort in Claude Code, even mid-conversation.

   /effort

2. Give Claude a spec and ask it to interview you on what is missing.

3. Implement in low effort, review, iterate in low if needed.

4. Verify and test in high effort.

In short

Effort is a time budget, not an IQ setting. Spend little when you want a sketch and will steer yourself; spend a lot when the danger hides in edge cases and you want Claude to check its own work. And whatever the level, get the approach right first, because no amount of extra checking will rescue the wrong idea.