Claude Code Adds xhigh: The New Middle Gear for Devs

Lachlan Reed

[excited] Welcome to the show! I’m Lachlan Reed with James Turner, and mate, I wanna start with one tiny little word that’s gonna matter to a lot of devs: xhigh. Claude Code 2.1.111 adds an xhigh effort tier for Opus 4.7, and it sits right between high and max. Not “faster mode,” not “genius mode” -- more like that middle gear where you get noticeably more reasoning than high without copping the full token bill and latency hit of max.

James Turner

[skeptical] The phrase that jumps out to me is “between high and max.” Because that means a lot of people were living in this weird binary: either high is good enough, or you smash the red glass and go max. xhigh is basically admitting that “good enough” and “go nuclear” was a clumsy choice for real work.

Lachlan Reed

Exactly. And if you’ve done enough coding with these tools, you feel that gap. High is usually fine for routine edits -- clean up a component, rename a few functions, patch a test. But then you hit the grubby stuff: architecture reviews, some cursed async race condition, or a refactor where every file is attached to every other file like spaghetti in a lawn mower. That’s where you want the model to slow down and think harder... just not max-hard on every prompt.

James Turner

[responds quickly] “Async race condition” is the exact phrase there. Because for something like that, one missed assumption and the whole answer’s junk. So I get the appeal of “just enough extra brainpower.” You’re not asking for infinite thought. You’re asking for the model to take the problem SERIOUSLY.

Lachlan Reed

[laughs] Yeah, give it another coffee, not a full existential retreat. That’s the practical charm. If I’m doing a routine UI tweak, I don’t need max. But if I’m staring at a nasty refactor and I want cleaner reasoning paths, xhigh sounds like the setting where I’d go, “Alright, settle in, have a proper think.”

James Turner

But let me push on the other side. Does adding xhigh actually simplify the decision? Or does it create one more knob for developers to obsess over? Because devs love turning one dial into a religion. Suddenly somebody’s benchmarking low, normal, high, xhigh, max across ten prompts and making a spreadsheet instead of shipping.

Lachlan Reed

[curious] That is SUCH a developer problem. We’ll spend 40 minutes tuning the wrench before tightening the bolt. But I think this one earns its keep because it maps to a real felt gap. It’s not some mystery setting wedged in for marketing. It answers a common moment: “I need more than high, but max feels like overkill.”

James Turner

And “overkill” is the important word. Max can be worth it, sure, but if you’re reaching for it on every serious prompt, you’re basically saying the ladder has a missing rung. xhigh adds that rung.

Lachlan Reed

[reflective] Right. And once a tool gives you that middle ground, it changes your habits. You stop thinking in extremes. Not every hard problem needs the sledgehammer. Sometimes you just need a slightly sharper chisel.

James Turner

The part I actually love here is the redesigned /effort command. If you run /effort with no arguments now, it opens an interactive arrow-key slider. You move across low, normal, high, xhigh, and max, then hit Enter to confirm. That sounds minor until you’ve spent enough years in terminals to know the difference between “feature exists” and “feature is usable under pressure.”

Lachlan Reed

[warmly] Ooh, that’s a good distinction. Because a hidden config trick always feels a bit like finding a spanner in the shed after you’ve already tried fixing the bike with a spoon. If it’s interactive -- arrow keys, live choice, press Enter -- suddenly it feels like part of the workflow, not trivia from page 6 of the docs.

James Turner

Yes. “Arrow-key slider” is the thing I’d react to. That turns effort into something you adjust live while experimenting, not something you memorize as a flag and forget exists. You can feel your way through it in the terminal.

Lachlan Reed

And there are still the practical entry points too. You can launch with claude --effort xhigh, which is dead handy if you already know what session you want. Or pick it in the model picker UI if you want that visible, repeatable choice. So it’s not just one path -- it’s terminal, launch flag, and UI all lining up.

James Turner

[reflective] “claude --effort xhigh” is exactly the kind of thing teams can standardize around. But I think the interactive piece matters more for discovery. I’ve had so many CLI moments where I technically knew a feature existed because I read the docs, but it didn’t become REAL until I used it and felt the shape of it.

Lachlan Reed

[chuckles] Oh, absolutely. I’ve wrestled enough CLIs to know this pain. You read a command, nod wisely, then three days later you remember none of it. But when a terminal lets you poke at it -- move left, move right, see the options -- your brain goes, “Ahh, got it.” It’s the difference between reading a map and actually riding the trail.

James Turner

And for experimentation, that’s huge. Because effort level is not a one-time preference. It changes with the task. You might start at high, bump to xhigh when the prompt gets hairy, then go back down. A live control surface fits that reality better than editing config files every time.

Lachlan Reed

[matter-of-fact] That’s the phrase: control surface. Not just a flag. Once the model picker UI and the slash command both expose the same choice, you’re telling users, “This is a knob you’re supposed to use.” Not a secret handshake.

James Turner

And when a feature stops feeling like a secret, adoption goes up. Not because the docs got better -- though docs matter -- but because the interface finally admits what people are actually trying to do in the middle of work.