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. 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.
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."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.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."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.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."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.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.
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."
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.
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.
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."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.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.
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.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.
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.