Opus 4.8: why I default to High effort, not xHigh

Claude Code has a /effort command that sets how hard the model thinks before it answers, with levels running up to xHigh. The intuition when you first see it is obvious: max it out. More deliberation should mean better answers, so why would you ever pick anything less than the top setting. I ran Opus 4.8 at xHigh for a while on that assumption. I have since switched my default back to High, and this is why.

What reasoning effort actually trades away

Effort is not a quality dial in the sense of a strict floor that rises with the setting. It is a budget for deliberation: the model spends more time and more tokens reasoning before it commits to an answer, which means more latency and more spend per turn. On genuinely hard problems, that extra budget buys something real. On a lot of everyday coding and orchestration work, the answer at High and the answer at xHigh converge, and the extra deliberation is spent re-checking ground the model already covered. Past that point you are paying more for the same result, not a better one.

What I actually saw

I want to be upfront about what this is and is not. This is not a benchmark. I did not log timings, count tokens, or run the same prompt at both settings enough times to get a percentage I would stand behind. It is a hands-on, subjective impression built up over real sessions with Opus 4.8, on my own workload, which skews toward Next.js and TypeScript work, orchestration-style planning, and the kind of debugging that shows up in a normal week of building this site and a handful of side projects. Someone on a different kind of task could see something else entirely.

With that caveat stated plainly, here is the impression. xHigh was consistently heavier: noticeably slower to get a first response, and visibly more verbose in how the model deliberated along the way. Most of the time, the actual output, the code, the plan, the fix, landed on par with what High produced. Not worse, but not reliably better either. The extra weight did not track a matching jump in what came out the other end, on the kind of task I throw at it most days.

Where xHigh still earns its cost

None of this means xHigh is a bad setting. It means it is a setting for a specific kind of problem, not a default. The times it clearly pulled its weight were the genuinely hard ones: an architecture decision with no obviously correct answer and real tradeoffs on both sides, or a root-cause debugging session where the bug is gnarly enough that the fast, confident answer is usually wrong. Those are exactly the cases where more deliberation is doing real work rather than re-treading ground, and where I would rather pay the extra latency than get a shallower answer.

The lesson I take from this is not “xHigh is bad.” It is “reach for it deliberately, not by default.” The slider goes up to xHigh because some problems need it, not because higher is always the right answer for whatever you happen to be doing that minute.

What I do now

Day to day, I run Opus 4.8 at /effort high. That is the default for ordinary coding, planning and orchestration, the bulk of what a session actually does. When a task turns out to be one of the hard ones, an ambiguous architecture call, a bug that has resisted the obvious fixes, I escalate to xHigh on purpose, for that specific piece of work, rather than carrying the heavier setting through an entire session by habit.

The bigger habit underneath that one setting change is the one worth keeping: measure effort against your own workload instead of trusting a slider label. I do not know what Anthropic's internal guidance says about when xHigh is worth it, and I am not claiming to. What I know is what it did on my machine, on my tasks, over real use. That is a smaller claim than a benchmark, but it is the one I can actually stand behind, and it is the one that changed how I work.