Welcome to the show!
I'm Lachlan Reed with James Turner.
James, imagine you're deep in a refactor,
you've got this lovely long Claude Code session going,
and then somewhere around the 200K-token mark the thing suddenly starts
acting like it had a little bump on the head.
That 200K number is the whole bug,
right?
Because Claude Code 2.
1.117 was treating Opus 4.
7 like it had a 200, 000-token
window, when Opus 4.
7's native context is actually 1 MILLION.
Exactly.
Five times off.
Bit of a shocker.
So `/autocompact` could kick in at roughly 200K instead of letting the
session stretch out toward 1M.
Which means long sessions were getting compacted about five times too
early.And early compaction is not just cosmetic.
Once the tool summarizes and compresses context,
the model is no longer reading the raw thread in the same way.
It's reading a reduced version sooner than it should.
Yeah,
and that's the bit that stings.
I've had this happen in coding tools where you're halfway through
a giant cleanup -- renamed three services,
moved config, fixed tests -- and then the assistant starts proposing
the OLD structure back at you.
Not totally wrong, just wrong enough that you go,
"Mate...
were you not here ten minutes ago?""Were you not
here ten minutes ago"
is the perfect description.
Because a premature summary doesn't look like a crash.
It looks like confidence with missing memory.Yes!
That's why it feels like gaslighting.
You know you already settled the dependency direction or the naming
convention,
and suddenly the tool's like, "Have you considered the exact thing we rejected 40
minutes back?"
And now you're doubting your own notes.
The token waste matters too.
If compaction fires at 200K instead of near 1M,
you're forcing the model to re-read summarized context much earlier and
potentially more often.
So you lose fidelity AND you may burn tokens re-establishing state.
Right.
It's like replacing a full workshop manual with a sticky note way too
early.
The sticky note might say "engine partly disassembled, check carburetor"
-- useful, sure -- but if you're rebuilding the whole trail bike,
that's not enough detail to trust with your knuckles.And
because the mismatch was specific,
this wasn't some vague "AI forgot stuff" complaint.
It was a concrete accounting bug: Opus 4.
7 had a 1M-token native window,
but Claude Code was budgeting like it only had 200K.
Which is honestly
reassuring in a weird way.
Bad, yes.
But fixable bad.
Not mystical bad.
The practical effect of the fix is pretty
straightforward: if you're on a premium plan using Opus 4.
7,
your sessions should now stay coherent for WAY longer before autocompaction
triggers.
And "way longer" here means the difference between a proper multi-hour
work session and one that starts wobbling before lunch.
That matters for debugging especially.
If you've spent an hour narrowing a bug to,
say, one race condition in a queue worker,
losing the earlier elimination steps is brutal.
The queue-worker example
is good because the lost context isn't just facts.
It's rejected paths.
"We already ruled out Redis config." "We already confirmed the timeout isn't
network."
Those negatives are expensive to rediscover.
Same with architecture planning.
If you've spent pages agreeing on constraints -- legacy database stays,
API shape can't break mobile, rollout has to be gradual -- and then autocompact
fires early, the conversation changes shape.
The model may still sound clever,
but it's now reasoning from a compressed version of those constraints.
That's
the tension I keep coming back to: autocompact is useful when it's correct.
I actually LIKE it as a feature.
But when it fires early, it's kind of disastrous because nothing visibly
explodes.
The tool doesn't say "failure." It silently swaps a rich history for
a thinner one.Yep.
A loud failure at least has the decency to ruin your afternoon honestly.
A silent one just makes the work feel slippery.
And this bug was narrow.
Opus 4.
6 and Sonnet 4.
6 were never affected because they genuinely use
200K context windows.
So 200K was correct there.
The mismatch only hit Opus 4.
7,
where the native window is 1M.
That distinction is worth underlining.
If someone says, "Hang on, my Sonnet 4.
6 session compacted around 200K and seemed fine,"
yeah -- that's because 200K is the real ceiling there.
No funny business.So this isn't "autocompact bad."
It's "wrong context accounting bad."Bingo.
If the speed limit on the road is 100 and your brakes kick in at 20,
the brakes aren't evil.
They're just firing at the wrong bloody time.
There's another update tucked
in here, and this one's more about answer quality than memory.
On Opus 4.
6 and Sonnet 4.
6, Pro and Max subscribers now default to `high`
effort instead of `medium` automatically.
No config change needed.
And the key token there is `high`.
Higher effort usually means slightly higher token usage per response,
but also more deliberate reasoning before Claude answers.
For code generation, debugging,
architecture decisions -- that's often where the extra thinking pays
off.
I like that you said "slightly higher token usage" and not magic.
Because there is a tradeoff.
You are paying for more thought.
The question is whether that should be the DEFAULT.
I'm mostly yes on
that.
For serious dev workflows, defaulting to better reasoning feels right.
Most people don't open Claude Code to get the fastest mediocre answer.
They open it because a wrong migration plan or a shallow debugging path
costs more than a few extra tokens.Mostly agree...
but I can hear the indie devs grinding their teeth already.
If you're doing lots of quick iterations,
cost creep is real.
Tiny per-response bumps add up,
especially if you're in there all day poking at a big repo.
Sure,
but there's context on the context -- different context,
sorry.
API key, Team, and Enterprise users were already on `high` by
default since v2.
1.94.
So this isn't some totally new experiment.
It's bringing Pro and Max into line with what another chunk of the ecosystem
already had.
That v2.
1.94 detail matters.
It tells you Anthropic had already decided `high` was the sane default
for other user groups.
So for Pro and Max, this is less a leap and more catching up.
Exactly.
And I think serious coding tasks benefit from more internal deliberation.
If the model takes a beat and avoids a bogus refactor,
that's worth more than shaving off a little token spend.
Maybe.
Though I still reckon defaults should fit the widest daily use,
not just the heaviest one.
Some people want a sharp pocketknife,
not a whole workshop every time they ask for a regex.Fair.
But when the tool is aimed at coding,
I'd rather the default bias toward "thoughtful" than "cheap and hasty."So,
practical stuff.
Update with `npm install -g @anthropic-ai/claude-code@latest`,
or just let auto-update do its thing.
Then inside a session, use `/context` to confirm Claude Code is tracking
the correct window size.
That `/context` command is the bit I'd tell everyone
to remember.
Don't just trust vibes.
Check the actual reported window.
If you were manually disabling autocompact on Opus 4.
7 as a workaround,
you can re-enable it now because the bug is fixed and it should behave
properly.
And for effort settings,
use `/effort` to inspect what's active.
If you need tighter cost control,
explicitly set `medium` for that session,
or lock `defaultEffortLevel` in your project's `CLAUDE.
md`.I love that
there are knobs, but this whole update raises a bigger question for me.
When a tool quietly fixes a deep session-management bug
and also changes a quality default,
how much do you trust the defaults versus checking under the hood every
single time?
The phrase "quietly fixes" is the one that sticks with me.
Because the best version of software is invisible -- stuff just works.
But invisible changes also mean power users have to decide where blind
trust ends.
Yeah.
I don't wanna babysit every setting like a nervous mechanic listening
for a weird rattle.
But I also don't wanna be the mug who assumes the dashboard is right
while the engine light's been unplugged.Maybe that's the real
modern
developer skill now: not just using smart tools,
but periodically auditing what they think the world looks like.
Context window, effort level, compaction behavior -- the hidden state
matters.
And if hidden state matters,
defaults stop being boring.
They become a design philosophy.
Are they there to protect most users,
optimize quality, control cost,
or reduce support tickets?
Sometimes those are the same thing...
sometimes not even close.Which is a pretty good note to leave
hanging.
Check the settings, sure -- but also ask what the defaults are trying
to optimize for, and whether that's actually YOUR workflow.
Nice one.
Cheers for listening, folks.