Start Claude Opus 5.5 at medium effort for a scoped task. Try low when speed matters and the work is mechanical; move to high when a representative task repeatedly misses a requirement or needs deeper investigation. Reserve xhigh and max for work whose added completion value pays for more output tokens and elapsed time. This is a starting rule, not a quality ranking for your codebase. Anthropic makes medium the Opus 5.5 default and recommends an effort sweep on your own evaluations.
Effort is a behavioral signal, not a token allowance. It influences thinking, visible text, and tool calls; a lower setting can still reason through a hard problem. A high setting can also spend more without finishing the task. Measure success per completed task, including retries, rather than judging a single answer's length. If you are choosing the model itself or checking its price and migration requirements, see our Opus 5.5 overview.
Which of the five levels should you try?
Opus 5.5 accepts low, medium, high, xhigh, and max. The table turns Anthropic's level descriptions into a test order; its examples are workload hypotheses, not measured breakpoints.
| Level | Good first test | What would justify keeping it? |
|---|---|---|
low | Small edits, extraction, or other tightly specified work | The same acceptance checks pass with less time and fewer billed tokens. |
medium | Ordinary, bounded coding or agent tasks; the Opus 5.5 default | It completes the task without costly repair turns. |
high | A multi-file fix or investigation that medium leaves incomplete | It improves first-pass completion enough to offset extra thinking and tool use. |
xhigh | Long-running, capability-sensitive agentic work | It resolves failures that remain at high, within your time and cost budget. |
max | The rare task where maximum capability matters more than token economy | Its incremental completed-task value exceeds its large extra cost. |
The order is not a promise that every step helps. Anthropic describes xhigh as suited to long-horizon work and max as unconstrained token spending. If a check can expose a missed caller or broken integration, add that check before paying for more reasoning on every turn. Anthropic's Claude Code cost guide gives a similar example: a test reaching the client can catch a change that otherwise stops at the server handler.
Do not carry an old implicit default into a comparison. Opus 5 defaults to high; Opus 5.5 defaults to medium. If you change the model name while omitting effort, you have changed both model and effort. Set the level explicitly when you want a fairer migration experiment. Anthropic also cautions that Opus 5.5 may spend more thinking at a level with the same name, so equal labels still do not guarantee equal token counts. Read the Opus 5.5 effort guidance.
Set effort on the route you actually use
In Claude Code, enter /effort high to change the level for the next request. Run /effort status to see the current setting. Replace high with the level you intend to test. Anthropic's Claude Code instructions document both commands. A setting change inside an existing session clears its cached conversation, so the next request can incur a cache write over the conversation. Set a trial level near the beginning of a session when possible; account for a mid-session switch when comparing costs.
For the direct Messages API, put the level in output_config.effort. This minimal Python SDK request follows Anthropic's API example:
pythonimport anthropic client = anthropic.Anthropic() response = client.messages.create( model="claude-opus-5-5", max_tokens=4096, messages=[{"role": "user", "content": "Review this migration plan for missing steps."}], output_config={"effort": "medium"}, )
Use a sufficiently large max_tokens for demanding work: this is the hard cap on thinking plus response text, whereas effort is only a signal about how much work to do. A request with too little output room can end before the task is done even at max. Adaptive thinking is always on for Opus 5.5. Do not send the old thinking.type: "disabled" or thinking.type: "enabled" with a thinking budget; those settings produce HTTP 400 on this model. Anthropic's effort documentation and Opus 5.5 changes specify these limits.
If an API conversation must change levels while keeping a warm prefix, Anthropic offers per-message effort in beta for Opus 5.5. Send the mid-conversation-output-config-2026-07-01 beta header and an effort-only system message with an empty content array and output_config.effort; the new level starts at the next user turn. Changing top-level output_config.effort between requests instead breaks the prior cached prefix. This distinction is specific to the supported API route and does not make Claude Code's /effort cache-preserving. Follow the per-message API example and placement rules before using the beta in production.
What does the benchmark say, and what does it leave open?
Artificial Analysis reports the following for its Intelligence Index v4.3.2, with default fallback enabled. The dollar figure is its weighted average cost per benchmark task, not the price of your typical prompt, a Claude Code subscription charge, or a guarantee that one level wins in your repository. Each row links to that level's independent model measurement.
On this particular index, moving from medium to high adds 3 score points while the weighted task cost rises $0.48, about 36%. Moving from xhigh to max adds 2 points while cost rises $2.52, about 73%. These are calculations from the published rows, not marginal prices for an individual task. The composite score combines ten evaluations; it cannot tell you whether a specific bug fix, review, or tool loop succeeds. The provider, fallback behavior, test mix, and figures may change. Use the table to pick levels to test, then decide from your own completion criterion.
Run a small effort sweep without fooling yourself
Choose several recent tasks that represent your actual mix: for example, a mechanical edit, a cross-file fix, and a longer investigation. For each, save the same starting files, prompt, available tools, and acceptance checks. Run at medium, then compare low on the straightforward case and high on the case that failed or required repairs. Add xhigh or max only where a harder task still fails and its value makes an expensive trial sensible. Rotate task order if a warm cache or external service could favor one run.
Record completed tasks, required repair turns, elapsed time, output tokens (including billed thinking), uncached input, cache reads, and cache writes. A run that is cheaper per request but needs three retries can cost more per completed task. A more expensive first turn can be worth it if it avoids a full rerun. Conversely, an impressive answer that does not pass the same checks is not a completed task. Anthropic's cost guide explains why turns and cache hit rate matter in long Claude Code sessions.
For a direct API estimate, apply the published Opus 5.5 rates to your measured token categories. At standard rates per million tokens, uncached input is $4, output is $20, a five-minute cache write is $5, a one-hour write is $8, and a cache read is $0.20. For example, 100,000 uncached input tokens plus 20,000 output tokens cost $0.80 before cache writes and other charges: 0.1 × $4 + 0.02 × $20. If a level change also rewrites 100,000 tokens into a five-minute cache, that adds $0.50 at the published rate. These are arithmetic examples, not results of a paid run; actual routes, subscriptions, and additional features may bill differently.
Keep the lowest level that reliably passes your checks within the time budget. If medium misses a cross-file dependency, test high with the same acceptance criteria. If high only adds narration or repeated tool calls, return to medium and improve the task's checks. That decision is more useful than assigning one permanent effort level to every Opus 5.5 request.
