Claude Opus 5.5 effort: low, medium, high, xhigh, or max?

Short answer: start coding work on Claude Opus 5.5 at `medium`. Try `low` for mechanical, single-file work with cheap verification; use `high` for ambiguous bugs, cross-file changes, or architecture decisions. Move to `xhigh` or `max` only when a lower level fails the same acceptance checks. Anthropic made `medium` the Opus 5.5 default and recommends measuring levels on your own work.[3][4]

This is not an independent benchmark. It turns Anthropic's September 22, 2026 announcement and current technical documentation into a routing rule for real coding tasks. My editorial judgment is simple: choose effort by completed-task cost, repair turns, and verification burden, not by how impressive the answer sounds.

Quick pick

• `low`: renames, small tests, documentation, a specific lint error, or a narrow transformation.
• `medium`: an everyday feature, reversible multi-file refactor, test and type updates, or a bounded agent task.
• `high`: ambiguous debugging, a cross-service change, an architecture choice, or expensive rollback.
• `xhigh`: long research, a broad migration, or a plan that remains incomplete at `high`.
• `max`: rare work where the highest capability changes the measured outcome.

This mapping is not a quality guarantee. Effort is a behavioral signal that influences thinking depth, latency, and token use rather than a fixed token budget.[3]

Why medium is the sensible Opus 5.5 starting point

Adaptive thinking is always on in Claude Opus 5.5. The old `thinking: disabled` setting and manual `budget_tokens` mode do not work on this model; `effort` is the control for depth. The API defaults to `medium`, the context window is one million tokens, the standard maximum output is 128,000 tokens, and list pricing is $4 per million input tokens and $20 per million output tokens.[2]

Anthropic says Opus 5.5 at `medium` matched or exceeded Opus 5 at `high` in its coding and knowledge-work evaluations. It also says `low` came close on several coding evaluations at much lower cost.[4] Those are vendor measurements. They offer a useful starting hypothesis for your repository, not proof of the result.

The less obvious detail matters: effort labels do not represent the same amount of thinking across models. Anthropic says Opus 5.5 may think more per turn than Opus 5 at the same label, especially at `xhigh` and `max`.[4] Copying an Opus 5 setting is not a controlled comparison. Fix the model and effort explicitly, then run the sweep again.

When is low enough for coding?

`Low` is a good first test when a wrong result will be exposed quickly. The task does not have to be unimportant; it needs a clear verification path.

• Add a unit test that follows an existing pattern.
• Rename a symbol and update its references.
• Change a README, comment, or user-facing string.
• Fix one error already identified by a linter.
• Implement a well-specified JSON or data transformation.

Name the target file, forbidden scope, and test command in the request. Then inspect the diff and run the test and lint command. If `low` passes, raising effort merely to make the model think longer has no obvious payoff.

If tool use stops early, a caller is missed, or the agent misunderstands the boundary, tighten the prompt and acceptance criteria first. If the same gap remains, rerun from the same state at `medium`. More effort cannot repair a task that was never defined clearly.

Which work belongs on medium?

`Medium` is the sanest default for bounded work that is bigger than one step. Opus 5.5 starts there already.[2][3]

• Add an endpoint in the repository's existing architecture and error-handling style.
• Make a reversible refactor across several files.
• Complete the types, tests, and documentation after an API change.
• Plan and implement a small feature, then run the relevant checks.
• Separate two or three plausible root causes from logs.

Ask the agent for a short plan, the files it expects to change, and the verification commands before implementation. A well-bounded task at `medium` is easier to control than a vague task handed to `high`.

The low-vs-high reasoning task guide covers the cross-vendor decision. This article has a narrower job: routing the five Opus 5.5 levels around its new `medium` default.

When does high earn its cost?

Use `high` when the decision tree and failure impact grow, not when you want a longer answer.

• A production failure with an unknown root cause across several services.
• Code that changes authorization, payments, or a data boundary.
• A schema migration with data-loss risk.
• An architecture choice among several viable options in a legacy codebase.
• A multi-file change where the `medium` plan misses the same dependency twice.

Have the agent state its assumptions, evidence-gathering order, affected files, and rollback plan before it writes code. Reviewing that plan can remove more risk than paying for a deeper setting after the wrong implementation has started.

Anthropic positions Opus 5.5 for long-running agentic coding and knowledge work, and its published evaluations claim strong results at `medium` too.[1][4] Raise effort because your representative task fails at `medium`, not because the model is new.

Why xhigh and max should not be defaults

Anthropic recommends reserving `xhigh` and `max` for work where you have measured a quality gain. Higher settings can add thinking tokens, elapsed time, and cost.[3][4]

Try `xhigh` when a repository-wide investigation, broad migration, large audit, or multi-stage agent run remains incomplete at `high`. Keep `max` as the last step for the hardest, highest-value tasks. A comparison is weak unless each level receives the same repository state, prompt, tools, and acceptance checks.

A run that produces a more persuasive explanation at `max` but fails the tests is not complete. If `medium` passes the same checks sooner and leaves a smaller diff, it is the better production choice.

If model tier is still open, the GPT-5.6 Sol–Terra–Luna pillar guide separates speed, cost, and depth. The current Opus 5.5, GPT-6 Sol, and Luna cost comparison covers the model-routing decision around completed-task cost.

How should you test effort levels?

Choose three representative tasks: a mechanical edit, ordinary multi-file development, and an ambiguous investigation. Hold the starting commit, tools, prompt, time limit, and acceptance checks constant.

Run all three at `medium` first. Compare `low` on the mechanical task and `high` on the task that failed or became expensive. Add `xhigh` or `max` only if `high` still misses a measurable check.

Record more than token use:

• Did the acceptance tests pass on the first attempt?
• How many repair turns were needed?
• What were the total time and charge?
• How many files changed, and was there unrelated diff?
• How long did human review take?
• What cache reads and cache writes were billed?

Changing the top-level effort value during a conversation may invalidate the prompt cache. Anthropic offers per-message effort in beta for changing one turn while preserving the cache.[4] Do not mistake the cache cost of a mid-session setting change for the quality cost of the level itself.

Verification does not change with effort

A vendor benchmark or a higher effort level is not merge approval. Read the changed-file list and diff, run the relevant tests, lint, and build, then check security, data, and production behavior separately.

Use the seven-step coding-agent output checklist to turn a completion claim into evidence. If the execution surface is also undecided, the local-vs-cloud agent task guide separates environment and permission risks.