The Short Answer

The effort setting tells Claude how much work a task deserves. The data and charts in this guide come from Anthropic’s Thariq’s article, “Using Claude Code: Spending your effort” (original on X, interactive version on claude.dev). Penchan has reorganized the advice and examples around the kinds of tasks beginners often face.

In a hurry? This chart is enough to get started:

Which effort level should you use?

What Does effort Change?

Imagine asking a friend to review a document. If you say, “Give it a quick look,” they will skim it and hand it back. If you say, “This goes to print tomorrow, so please check it carefully,” they will go line by line and fix a few things that seem awkward. effort is that instruction. In Thariq’s observation, it controls how much Claude verifies its own work, tests edge cases, and makes decisions for you.

An edge case is an unusual situation that rarely comes up but can cause errors when it does, such as blank input, a huge file, or an unexpected symbol.

So higher effort brings two changes: Claude checks its work more times and makes more decisions for you. The first is usually helpful. The second depends on how much you want to stay in control.

Match the Level to Your Task

Think about which of these best describes your work:

LevelYour task looks likeTrade-off
lowFix a typo, revise a paragraph, or brainstorm a few ideasShorter wait and relatively low token use
mediumAdd a feature to an existing tool according to a written specModerate wait and token use
highFix a bug that only appears in a particular situationA noticeably longer wait and more tokens
maxHand Claude a complete small tool to build without supervising itLonger wait and relatively high token use

xhigh, which is not in the table, falls between high and max. Try it when you want more care than high without waiting as long as max.

A token is a unit used to measure the text AI processes. You can roughly think of it as a word count: the more tokens used, the more it costs and the faster you use up your plan’s allowance. You do not have to pick a level upfront. Enter /effort in Claude Code to change it at any point in a conversation.

How big is the trade-off? Thariq tested the same request, “Build a personal fitness tracking app.” The low run took about 1.5 minutes, while the max run took about 67 minutes. The max version included quite a few extra features Claude decided to add on its own.

How long the same request takes

When Is Higher Effort Worth It?

The test is simple. Ask yourself three questions:

  1. Would it be costly if this went wrong?
  2. How many unusual situations could come up?
  3. Will you be watching and correcting Claude as it works?

If your answers to the first two are “costly” and “many,” and your answer to the third is “no,” higher effort is worth it. For simple tasks that are easy to check and that you will supervise, low or medium is enough. The extra wait may not buy you much.

Thariq analyzed results from Terminal-Bench 3.0, a community-created benchmark. The data points in the same direction. For example, one task was to write an HTML filter that blocks every way of sneaking in JavaScript. Fable 5.1 passed 1 out of 5 attempts at low, and all 5 at xhigh. Here is Fable 5.1’s pass rate from low to the highest effort level, by field:

Where higher effort makes a clear difference

The gains were substantial in security (64% → 87%) and hardware (34% → 75%), where repeated verification matters. The increases were smaller in operations (12% → 22%) and media (18% → 30%). The benchmark’s operations task was to complete a company’s monthly trade statistics filing by following the rules. Penchan’s reading is that extra rounds of checking help less with work that follows a set procedure step by step.

When Higher Effort Cannot Help

Higher effort mainly strengthens checking; it does not guarantee a better approach. In a reply to his post, Thariq said that unless a request is very ambiguous, Claude follows almost the same approach at different effort levels. His analysis also found that higher effort can reduce failures caused by missed edge cases, but cannot rescue a method that was wrong from the start.

What higher effort improves

Fable 5.1 ran 370 attempts at low and 370 at max. The number of passes, bugs missed by tests, and requirements overlooked all improved. The one exception was choosing the wrong interpretation when a request had two possible meanings: that happened 25 times at low and 47 times at max. At higher effort, Claude makes more assumptions for you. When a request is ambiguous, higher effort will not automatically choose the right interpretation. If it picks the wrong one, it will spend more time building the wrong thing.

The fix is on your side:

  • Describe what the finished result should look like, such as which screens it should have and where the data should be stored.
  • List what not to do so Claude does not add things on its own.
  • When a sentence could mean two things, choose one and say so.
  • Start with low or medium to get a first version. Once the direction is right, switch to high for a thorough verification pass. (Thariq does this when building new features.)

Thariq also found that when he first wrote a detailed spec and gave it to different models at different effort levels, the results were much more alike. Write the spec clearly before choosing an effort level.

Penchan’s take

Penchan runs an AI team that splits up the work, with effort roughly set like this:

  • Daily coordination and task assignment: high
  • Routine development from a written spec: medium
  • Strategy and system architecture decisions: xhigh

This allocation changed after reading Thariq’s article. effort buys more checking; a clear request sets the direction. For work with a clear spec, medium is plenty. Save higher levels for tasks where mistakes are costly and many unusual cases may come up.

Further Reading

References