Anthropic’s xhigh: Claude Code’s New Default Gear

Lachlan Reed

Welcome to the show — James, I need to start with a setting that feels like finding a missing gear on an old trail bike: Anthropic just added xhigh for Claude Code on Opus 4.7, and it's now the DEFAULT.

James Turner

[curious] The word default is doing a lot of work there. xhigh sits between high and max, right? Which tells you the old jump from high to max was probably too chunky if people needed a whole new rung in the ladder.

Lachlan Reed

Exactly. High could be a bit too shallow for proper agentic coding work, but max could feel like, mate, turning a race car onto a gravel road — heaps of token burn, more latency, and suddenly you're paying premium prices for a job that didn't need the full orchestra.

James Turner

[responds quickly] The phrase I latch onto there is agentic work. Because this isn't "write me a helper function." This is more like a multi-step schema migration where step three only makes sense if step two didn't break some hidden assumption from step one.

Lachlan Reed

Yeah, that's the sweet example. Or a subtle PR security review — not the obvious "hey, you forgot auth" stuff, but the sneaky edge case where one permission check looks fine alone, then you trace it across three files and realize the whole thing leaks sideways. That's where high might not dig deep enough, but max is a bit of a sledgehammer.

James Turner

[skeptical] And that's the tension right away: is xhigh the missing sweet spot... or is it one more dial that makes developers FEEL responsible while the bill quietly creeps upward in the background?

Lachlan Reed

[laughs softly] Yep. The old "I've optimised the workflow" story, and then you check the tab later and nearly spit your coffee. I've done that with cloud defaults before. You tick one innocent-looking box and suddenly your app's running like it's servicing the Olympics.

James Turner

Mine was logging. Not AI — logging. I left a verbose mode on for, I think, a weekend, and by Monday I had a bill that looked like the app had developed a gossip problem. So when I hear "xhigh is now the default for Opus 4.7 in Claude Code," I hear convenience and risk in the same sentence.

Lachlan Reed

[warmly] And to be fair, there is real convenience here. Anthropic also changed the workflow around effort selection. If you run /effort with NO arguments now, it opens an arrow-key slider with low, medium, high, xhigh, and max. You don't have to remember the exact string and type it from memory like you're entering a cheat code from 2004.

James Turner

The arrow-key slider is small, but that's a legit UX shift. Because when something becomes interactive instead of memorized, people actually USE it. It's the difference between "there is a setting" and "this setting exists in my brain when I need it."

Lachlan Reed

Spot on. And there are a few entry points. You can launch straight from the CLI with claude --effort xhigh. You can pick it in the model picker. Or you can set it persistently through /config, which now writes to ~/.claude/settings.json.

James Turner

[matter-of-fact] ~/.claude/settings.json is the memorable bit for me, because that's where this stops being a one-off choice and becomes policy. A team can say: for serious Opus 4.7 sessions, our default is xhigh. Then nobody has to remember to re-assert it at the top of every new task.

Lachlan Reed

And that's a real time saver. Tiny, but real. Anyone who's ever reset the same dev environment setting ten times knows defaults are where time either gets saved or quietly bled out. It's like setting your editor to use spaces or tabs — sounds boring until you waste an afternoon fixing the mess.

James Turner

[calm] But here's the catch: xhigh is Opus 4.7-only. Not Sonnet, not Haiku. And if you switch models, the effort setting resets to whatever that model actually supports. So this is not a universal "Claude got smarter" button. It's a specific mode on a specific model.

Lachlan Reed

That's an important little gotcha. Because if you're bouncing between models, you might think you're still in xhigh land when you've actually dropped back to a different supported effort level. Easy mistake. Very human mistake. Even a kangaroo could trip over fresh code there. [chuckles]

James Turner

[slight laugh] And Anthropic is pretty explicit about the intended use: intelligence-sensitive agentic tasks. That's their lane for it. But "more reasoning" almost always cashes out as more tokens and more latency. There isn't some magic free lunch where the model thinks harder for the same price and same speed.

Lachlan Reed

Right. Better reasoning chains usually mean longer chains. More internal work, more generated analysis, more waiting. So if you're using xhigh for every little file tweak, you're basically bringing a crane to move a desk chair.

James Turner

The budget surprise gets sharper because xhigh is now the default for Max subscribers in Auto mode. That means some people may see higher spend without ever making a conscious "yes, I want more expensive reasoning" decision. The default made it for them.

Lachlan Reed

[reflective] And that's where accountability comes in. If the tool gets better by default, lovely. If the spend rises by default too, you've gotta look. Anthropic's safeguard here is /usage — that replaces the old /cost and /stats commands. So /usage is now the place to check whether your shiny better defaults are actually changing consumption patterns.

James Turner

/usage replacing both /cost and /stats is good design, honestly. One command, one dashboard in your head. Because if you split "how much am I using?" from "what is this costing me?" people tend to check neither until it's too late.

Lachlan Reed

[questioning tone] So when is xhigh actually worth it? I'd say the strong cases are where reasoning compounds. Migrating legacy code. Designing a new API surface. Reviewing PRs with subtle security implications. Large-codebase reviews where one wrong assumption cascades into three more and suddenly you're patching ghosts.

James Turner

The phrase "one wrong assumption cascades into three more" is exactly it. That's the kind of task where deeper effort can pay for itself, because catching the first bad assumption prevents a whole chain of bogus edits. Especially in legacy refactors, where every module has some weird haunted-house backstory.

Lachlan Reed

[laughs] Ah yes, the beloved legacy comment from 2017: "don't touch this." Terrifying. But for short interactive tasks, one-off file edits, or quick questions? xhigh is usually overkill. The latency tax alone can outweigh the quality bump. Sometimes you don't need a philosopher-mechanic. You just need a spanner.

James Turner

Let me try to say it back. [pauses] If the task is branching, stateful, and each decision changes the next decision, xhigh makes sense. If the task is narrow, obvious, and easy to verify fast, go cheaper and faster. Is that basically the rule?

Lachlan Reed

Almost — the missing bit is consequence. A task can be small but high-stakes. Like a short PR with subtle security implications. That's still a candidate for xhigh because the cost of being wrong is bigger than the wait. So it's not just size. It's dependency chain plus blast radius.

James Turner

[thoughtful] That's the real skill then. Not knowing the feature exists — knowing when deeper reasoning is actually needed, versus when you're just soothing your own anxiety with a more expensive setting.

Lachlan Reed

And that's the question I can't shake: once a team gets used to a just-in-case higher-effort default, do they become more careful coders... or just more expensive ones?

James Turner

[softly] Check /usage and you'll find out pretty fast. See you next time.