When to use xhigh effort

What this level exists for, specifically

The second-highest effort tier in the current lineup was introduced for a narrower purpose than its position near the top of the range might suggest — it targets the hardest coding and agentic work specifically, not "anything moderately difficult." Reaching for it as a general-purpose upgrade from the default, on the theory that higher is always at least somewhat better, misreads what it was actually built to solve.

The signal that a task belongs here

The clearest indicator that a task is a genuine fit is multi-step, open-ended work where the difficulty is in figuring out the right approach, not in executing a known one — an ambiguous refactor with real architectural trade-offs, a bug whose root cause requires genuine investigation across several files rather than a lookup, an agentic task that has to plan and adapt across many steps rather than follow a fixed procedure. Tasks with a clear, known correct approach don't benefit proportionally from the extra reasoning this level provides, however difficult they might look at a glance.

Why it needs deliberately different resourcing, not just a parameter change

This level requires a substantially larger max_tokens ceiling than a task run at the default would need, because it spends meaningfully more of the shared budget on thinking before producing an answer — a max_tokens value that comfortably covers a default-effort response can leave a sliver of room once thinking at this level has taken its share first, truncating the answer with no error to explain why. See max_tokens is too small once xhigh thinking is included for exactly this failure mode.

It isn't available everywhere

This level is new capability, not a renamed existing one — it doesn't exist on model generations that predate its introduction, and requesting it against an older model in the same family is rejected outright rather than silently downgraded to that model's actual maximum. If your code selects effort level dynamically and might route to an older model under some condition, that selection logic needs to know which models actually support this level before requesting it. See xhigh effort errors on Opus 4.6 and earlier for the specific failure this produces.

Testing before adopting it as a default

Because diminishing returns are documented at the top of the effort range, and overthinking a task that didn't need this much reasoning is a real, observed failure mode rather than a hypothetical one, this level is worth testing deliberately against your actual hardest tasks rather than adopting broadly on the assumption that more reasoning is a strictly safe default. A task where this level genuinely helps should show a measurable, real improvement over the default on your own evaluation — not just a plausible-sounding justification for the extra cost.

A/B comparing against the default rather than assuming an upgrade

Because the gain from this level over the default isn't guaranteed to be large on every task that looks superficially hard, the most reliable way to decide is a direct comparison on your own representative hard cases — run the same task at both the default and this level, and judge the actual difference in output quality against the actual difference in cost, rather than reasoning about it abstractly. A task where the two outputs are barely distinguishable isn't a good candidate for the extra spend regardless of how difficult the task appeared going in.

Reserving it for the tasks that actually need it, not the team that trusts it most

Once a team has a good experience with this level on a genuinely hard task, there's a natural pull toward reaching for it more broadly on the theory that it's simply the "better" setting worth using liberally. Resist that pull specifically for this level more than for most settings, since its value is concentrated narrowly on genuine top-end difficulty, and its cost is real and compounds across every request it's applied to regardless of whether that request needed it.

See effort level: xhigh for which current models support it, and choosing effort level for cost, not just quality for the budgeting side of this decision.