Claude effort levels: max vs high
What Claude's five effort levels really do, why high is the default, and why max burns through your Pro or Max usage window without a bigger bill.
What Claude effort levels do
Claude effort levels control how many tokens the model spends answering one request, and high is the default. The effort documentation says it plainly: setting effort to "high" "produces exactly the same behavior as omitting the effort parameter entirely". If you have never touched this setting, you are already running at high, so moving the dial to high changes nothing.
The level above it is the one people ask about. max is "absolute maximum capability with no constraints on token spending". That is not a free upgrade, and the same documentation is direct about the trade: on most work it costs a lot and buys little.
Everything quoted here comes from one source, Anthropic's effort page at platform.claude.com/docs/en/build-with-claude/effort, read on 9 September 2026. There are no per-level token multipliers in this guide because the docs publish none, and a guessed multiplier is worse than no number. The last section shows you how to measure the real ratio on your own workload instead.
The five effort levels, from low to max
The page lists five levels. The short descriptions below are the documentation's own wording.
low: "Most efficient. Significant token savings with some capability reduction." The listed use case is simpler tasks that need the best speed and lowest cost, such as subagents.medium: "Balanced approach with moderate token savings." Aimed at agentic tasks that need a balance of speed, cost and performance.high: "High capability. Equivalent to not setting the parameter." Aimed at complex reasoning, difficult coding problems and agentic tasks.xhigh: "Extended capability for long-horizon work." Aimed at long-running agentic and coding tasks, over 30 minutes, with token budgets in the millions.max: "Absolute maximum capability with no constraints on token spending." Aimed at tasks that need the deepest possible reasoning.
Two details stop this being a simple ladder. The first is that effort is "a behavioral signal, not a strict token budget". At a lower level Claude still thinks on a hard problem, it just thinks less than it would at a higher level on that same problem. The second is that the general table is not the final word: the page states that "the per-model recommendations that follow override this table where they differ", and those recommendations do differ. As of September 2026 the guidance for Claude Opus 5 is to start at high and adjust from your own evaluations, while the guidance for Claude Opus 4.7 and 4.8 is to start at xhigh for coding and agentic work.
Should you set effort to max?
Usually not, and the documentation says so itself. This is the guidance for Claude Opus 4.7, in the row for max:
Reserve for frontier problems. On most workloads max adds significant cost for relatively small quality gains, and on some structured-output or less intelligence-sensitive tasks it can lead to overthinking.
Read that second half carefully, because it is the part people skip. Structured output means a response that has to match a fixed shape: JSON against a schema, a one-word classification, an edit in a set format. On that kind of task the extra thinking has nothing useful left to do, so it goes back over decisions that were already correct. More reasoning is not always better reasoning.
The guidance for Claude Opus 4.7 also gives the condition for stepping up. Use max "only when your evals show measurable headroom at xhigh". That is a test, not a preference. If you have not run the same task at xhigh and found it falling short, you do not yet have a reason to pay for max.
Which models support max, and which support xhigh?
The docs carry a one-line warning that decides this for you: "Not every model that supports max supports xhigh." The two lists are close, and they are not the same.
As of September 2026 the page lists xhigh on Claude Fable 5.1, Mythos 5.1, Fable 5, Mythos 5, Opus 5, Opus 4.8, Opus 4.7 and Sonnet 5. The max list covers all of those and adds Claude Mythos Preview, Opus 4.6 and Sonnet 4.6. So on Sonnet 4.6 the step above high is max, with nothing in between, while on Sonnet 5 you have xhigh as the middle step. The choice depends on the model in front of you, and these lists change with each release, so check the page rather than trusting a list you memorised.
Effort is also not a way to buy capability the model does not have. If the answers are wrong rather than shallow, the fix is a different model, and picking the right model for the job is a separate decision from picking the effort level. Which models you can reach at all depends on your plan, which is covered in what model access each Claude Max tier includes.
Where you set effort
On the API, effort is output_config.effort on the request. The parameter is available on all supported models with no beta header.
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-opus-5",
"max_tokens": 64000,
"messages": [{"role": "user", "content": "Refactor this module and explain the risks."}],
"output_config": {"effort": "xhigh"}
}'That max_tokens value is not padding. The docs warn that at high and above you should set a large max_tokens, because it is "a hard limit on total output (thinking plus response text)", and they suggest starting at 64k for xhigh or max. Raise effort while leaving max_tokens small and you get truncated answers, which looks like a quality drop but is a budget you set yourself.
In Claude Code the same dial has four entry points, described in Anthropic's tutorial choosing the right effort level in Claude Code:
/effortwith no argument opens an interactive slider./effort <level>sets a level directly, and/effort autoreturns to the model default.--effort <level>sets the level for one run.effortLevelin the settings file takeslow,medium,highorxhigh.CLAUDE_CODE_EFFORT_LEVELsets it from the environment.
One behaviour is worth knowing before you go looking for it: "Max uses enough resources that Claude Code makes it session-only unless you set it through the environment variable, so you cannot leave it on by accident." If max seems to keep resetting, that is the design working.
What raising effort actually costs on a Pro or Max plan
Here is the part that API pricing guides get wrong for you. On a Pro or Max subscription, raising effort does not produce a bigger invoice. The price is flat. Nothing about max reaches your card.
What it reaches is the window. Claude subscriptions meter your usage over a rolling window that resets every five hours, and effort changes how many tokens each turn produces. More tokens per turn means fewer turns before the window is spent. The cost of max is not money. It is a limit message arriving in the middle of a task, at the point where you had context loaded and momentum going.
That is a worse currency than money, because you cannot pay more to get the next hour back. If you are not sure where your window goes today, the things that quietly eat a Claude Pro limit is the place to start, and what to do once the limit message appears covers the recovery. Both get more useful once you know that effort is a lever you control.
When is the extra thinking worth the window?
Use one rule: raise effort when the cost of a wrong answer is higher than the cost of running out of window early. That splits cleanly in practice.
- Raise it when you cannot check the output yourself. A migration plan for a system you do not know well is worth more thinking than a function you will read in ten seconds.
- Raise it for long agentic runs that have to survive many steps without you. This is what
xhighis described for. - Keep the default for ordinary coding you will review anyway. Your review catches what the extra tokens would have caught, and it costs you nothing from the window.
- Lower it for mechanical work. Renaming, reformatting, and short structured answers do not improve with more reasoning, and the docs specifically name structured output as a place where more thinking can hurt.
When you do raise it, move one level and rerun the same task rather than jumping to max. Anthropic's own advice is to "go up one level, rerun, and stop when it starts finishing the things you think it should". Most of the time that stops at xhigh.
Effort applies to tool calls, so agent loops get chattier
The effort parameter affects "all tokens" in the response, not only thinking blocks. Tool calls and their arguments are output tokens too, and the docs state the consequence: "Lower effort also means fewer and terser tool calls."
The tool-use section spells out the shape of the change. At lower effort Claude combines operations into fewer calls, makes fewer of them, and goes straight to action with terse confirmation afterwards. At higher effort it makes more tool calls, explains the plan before acting, writes detailed summaries of changes, and adds more comments to code.
In an agent loop that compounds, because each extra tool call is a full round trip that resends the growing conversation as input. The output tokens are the visible part of the increase and the input tokens are the larger, quieter part, which is the same mechanism explained in where Claude Code token usage really goes. If a run at higher effort feels slower than the level change should justify, count the tool calls before blaming the model.
Why you should pick one effort level and hold it
The documentation's fifth best practice is a caching rule: "Changing the top-level effort value between requests invalidates prompt caching, so vary it across workloads rather than within a conversation that relies on cache hits." The reason is given in the same page. Top-level effort shapes the rendered prompt, so a change means the cached prefix from earlier turns no longer matches.
The practical effect is worth naming, because it is the opposite of what people expect. You switch to max halfway through a long session to get a hard step right. The cache from every earlier turn is now dead, so that turn resends the whole conversation as fresh input, at full price, on top of the extra output tokens you asked for. You paid twice for one decision. The advice in the docs is to "pick an effort level at the start and keep it constant". Sessions with a large stable prefix are exactly the ones where this hurts most, which is the same arithmetic behind the point where prompt caching starts paying for itself.
There is one exception, and it is model-specific. On Claude Fable 5.1, Mythos 5.1 and Opus 5, a per-message effort change preserves the prompt cache. It is in beta and needs the header mid-conversation-output-config-2026-07-01, and it works by adding a role: "system" message with empty content carrying the new level, which takes effect from the next user turn. Models without support return a 400 error rather than falling back quietly. On every other model, the top-level value is your only option, so pick it once.
How to measure effort on your own workload
The docs give no token multiplier per level, and there is no honest published figure to quote. Measure it instead, on a task you actually run.
import anthropic
client = anthropic.Anthropic()
prompt = "<paste a task you really run>"
for level in ["medium", "high", "xhigh", "max"]:
response = client.messages.create(
model="claude-opus-5",
max_tokens=64000,
messages=[{"role": "user", "content": prompt}],
output_config={"effort": level},
)
print(level, response.usage.output_tokens)Read the four numbers as a ratio against high. That ratio is the only multiplier worth trusting, because it came from your prompt on your model. Run it on a real task, not a toy one: a two-line question will show almost no spread, and a long agentic job will show a large one.
On a subscription there is no per-turn output-token counter to read, so the measurement is coarser and still worth doing. Work a normal week at the default and note roughly where in a session the limit lands. Then work a week one level up and compare. If the limit now arrives around the middle of your working block instead of the end, you have your answer, and you can decide which tasks deserve the higher setting rather than leaving it on for everything.
FAQ
Is high effort the same as setting no effort at all?
Yes. The effort documentation states that setting effort to "high" produces exactly the same behavior as omitting the parameter entirely, and that the API default is high. Setting it explicitly is still useful as documentation of intent, and it protects you if a future default changes, but it does not alter how the model behaves today.
Does raising effort to max cost more money on Claude Pro or Max?
No. Subscription prices are flat, so effort never changes your invoice. It changes how fast you consume the usage window that resets every five hours, because higher effort produces more output tokens per turn. The cost shows up as hitting your limit earlier in a session, not as a charge.
Which models support xhigh?
As of September 2026 the effort page lists xhigh on Claude Fable 5.1, Mythos 5.1, Fable 5, Mythos 5, Opus 5, Opus 4.8, Opus 4.7 and Sonnet 5. The max list is longer and also includes Claude Mythos Preview, Opus 4.6 and Sonnet 4.6. The docs state directly that not every model supporting max supports xhigh, so check the page for the model you are using rather than assuming the ladder is the same everywhere.
Why did my prompt cache stop hitting after I changed effort?
Because top-level effort shapes the rendered prompt, so changing it between requests does not preserve cached prefixes from earlier turns. The whole conversation is resent as uncached input on the next request. Pick a level at the start of a session and hold it. On Claude Fable 5.1, Mythos 5.1 and Opus 5 you can use the beta per-message effort change, which keeps the cache, with the header mid-conversation-output-config-2026-07-01.
Does higher effort mean more tool calls in an agent loop?
Yes. Effort applies to all output tokens, and tool calls with their arguments are output tokens. The docs describe higher effort as making more tool calls, explaining the plan before acting, and writing longer summaries, while lower effort combines operations into fewer and terser calls. Each additional call is another round trip that resends the conversation, so the input side grows as well as the output side.