1
00:00:00,000 --> 00:00:00,963
Welcome to the show!

2
00:00:00,963 --> 00:00:03,207
I'm Lachlan Reed with James Turner.

3
00:00:03,207 --> 00:00:06,806
James, imagine you're deep in a refactor,

4
00:00:06,806 --> 00:00:09,847
you've got this lovely long Claude Code
session going,

5
00:00:09,847 --> 00:00:14,873
and then somewhere around the 200K-token
mark the thing suddenly starts

6
00:00:14,873 --> 00:00:17,415
acting like it had a little bump on the
head.

7
00:00:17,415 --> 00:00:21,559
That 200K number is
the whole bug,

8
00:00:21,559 --> 00:00:21,879
right?

9
00:00:21,879 --> 00:00:30,417
Because Claude Code 2.

10
00:00:21,879 --> 00:00:30,417
1.117 was treating Opus 4.

11
00:00:21,879 --> 00:00:30,417
7 like it had a 200, 000-token

12
00:00:30,417 --> 00:00:36,717
window, when Opus 4.

13
00:00:30,417 --> 00:00:36,717
7's native context is actually 1 MILLION.

14
00:00:30,417 --> 00:00:36,717
Exactly.

15
00:00:36,717 --> 00:00:38,399
Five times off.

16
00:00:38,399 --> 00:00:39,278
Bit of a shocker.

17
00:00:39,278 --> 00:00:45,077
So `/autocompact` could kick in at
roughly 200K instead of letting the

18
00:00:45,077 --> 00:00:46,959
session stretch out toward 1M.

19
00:00:46,959 --> 00:00:51,518
Which means long sessions were getting
compacted about five times too

20
00:00:51,518 --> 00:00:55,874
early.And early
compaction is not just cosmetic.

21
00:00:55,874 --> 00:00:58,665
Once the tool summarizes and compresses
context,

22
00:00:58,665 --> 00:01:01,863
the model is no longer reading the raw
thread in the same way.

23
00:01:01,863 --> 00:01:06,400
It's reading a reduced version sooner
than it should.

24
00:01:01,863 --> 00:01:06,400
Yeah,

25
00:01:06,400 --> 00:01:08,400
and that's the bit that stings.

26
00:01:08,400 --> 00:01:12,848
I've had this happen in coding
tools where you're halfway through

27
00:01:12,848 --> 00:01:16,011
a giant cleanup -- renamed three services,

28
00:01:16,011 --> 00:01:20,216
moved config, fixed tests -- and then the
assistant starts proposing

29
00:01:20,216 --> 00:01:22,335
the OLD structure back at you.

30
00:01:22,335 --> 00:01:25,616
Not totally wrong,
just wrong enough that you go,

31
00:01:25,616 --> 00:01:30,360
"Mate...

32
00:01:25,616 --> 00:01:30,360
were you not here ten minutes
ago?""Were you not

33
00:01:25,616 --> 00:01:30,360
here ten minutes ago"

34
00:01:30,360 --> 00:01:32,124
is the perfect description.

35
00:01:32,124 --> 00:01:34,926
Because a premature summary doesn't look
like a crash.

36
00:01:34,926 --> 00:01:39,200
It looks like confidence with missing
memory.Yes!

37
00:01:39,200 --> 00:01:41,118
That's why it feels like gaslighting.

38
00:01:41,118 --> 00:01:45,522
You know you already settled the
dependency direction or the naming

39
00:01:41,118 --> 00:01:45,522
convention,

40
00:01:45,522 --> 00:01:51,073
and suddenly the tool's like, "Have you
considered the exact thing we rejected 40

41
00:01:45,522 --> 00:01:51,073
minutes back?"

42
00:01:51,073 --> 00:01:55,517
And now you're doubting your own notes.

43
00:01:51,073 --> 00:01:55,517
The token waste matters too.

44
00:01:55,517 --> 00:01:59,841
If compaction fires at 200K instead of
near 1M,

45
00:01:59,841 --> 00:02:03,974
you're forcing the model to re-read
summarized context much earlier and

46
00:02:03,974 --> 00:02:05,129
potentially more often.

47
00:02:05,129 --> 00:02:10,400
So you lose fidelity AND you may burn
tokens re-establishing state.

48
00:02:05,129 --> 00:02:10,400
Right.

49
00:02:10,400 --> 00:02:14,863
It's like replacing a full workshop
manual with a sticky note way too

50
00:02:14,863 --> 00:02:15,278
early.

51
00:02:15,278 --> 00:02:21,095
The sticky note might say "engine partly
disassembled, check carburetor"

52
00:02:21,095 --> 00:02:25,206
-- useful, sure -- but if you're
rebuilding the whole trail bike,

53
00:02:25,206 --> 00:02:29,120
that's not enough detail to trust with
your knuckles.And

54
00:02:29,120 --> 00:02:31,318
because the mismatch was specific,

55
00:02:31,318 --> 00:02:34,880
this wasn't some vague "AI forgot stuff"
complaint.

56
00:02:34,880 --> 00:02:41,321
It was a concrete accounting bug: Opus 4.

57
00:02:34,880 --> 00:02:41,321
7 had a 1M-token native window,

58
00:02:41,321 --> 00:02:45,869
but Claude Code was budgeting like it
only had 200K.

59
00:02:41,321 --> 00:02:45,869
Which is honestly

60
00:02:45,869 --> 00:02:47,398
reassuring in a weird way.

61
00:02:47,398 --> 00:02:48,758
Bad, yes.

62
00:02:48,758 --> 00:02:50,038
But fixable bad.

63
00:02:50,038 --> 00:02:52,396
Not mystical bad.

64
00:02:52,396 --> 00:02:56,124
The practical
effect of the fix is pretty

65
00:02:56,124 --> 00:03:00,162
straightforward: if you're on a premium
plan using Opus 4.

66
00:02:56,124 --> 00:03:00,162
7,

67
00:03:00,162 --> 00:03:04,769
your sessions should now stay coherent
for WAY longer before autocompaction

68
00:03:04,769 --> 00:03:09,896
triggers.

69
00:03:04,769 --> 00:03:09,896
And "way longer" here means the
difference between a proper multi-hour

70
00:03:09,896 --> 00:03:13,192
work session and one that starts wobbling
before lunch.

71
00:03:13,192 --> 00:03:15,433
That matters for debugging especially.

72
00:03:15,433 --> 00:03:17,754
If you've spent an hour narrowing a bug
to,

73
00:03:17,754 --> 00:03:20,550
say, one race condition in a queue worker,

74
00:03:20,550 --> 00:03:25,358
losing the earlier elimination steps is
brutal.

75
00:03:20,550 --> 00:03:25,358
The queue-worker example

76
00:03:25,358 --> 00:03:30,240
is good because the lost context isn't
just facts.

77
00:03:30,240 --> 00:03:32,161
It's rejected paths.

78
00:03:32,161 --> 00:03:37,297
"We already ruled out Redis config." "We
already confirmed the timeout isn't

79
00:03:32,161 --> 00:03:37,297
network."

80
00:03:37,297 --> 00:03:41,356
Those negatives are expensive to
rediscover.

81
00:03:37,297 --> 00:03:41,356
Same with architecture planning.

82
00:03:41,356 --> 00:03:46,151
If you've spent pages agreeing on
constraints -- legacy database stays,

83
00:03:46,151 --> 00:03:51,982
API shape can't break mobile, rollout has
to be gradual -- and then autocompact

84
00:03:51,982 --> 00:03:55,034
fires early,
the conversation changes shape.

85
00:03:55,034 --> 00:03:57,669
The model may still sound clever,

86
00:03:57,669 --> 00:04:02,360
but it's now reasoning from a compressed
version of those constraints.

87
00:03:57,669 --> 00:04:02,360
That's

88
00:04:02,360 --> 00:04:06,875
the tension I keep coming back to:
autocompact is useful when it's correct.

89
00:04:06,875 --> 00:04:08,957
I actually LIKE it as a feature.

90
00:04:08,957 --> 00:04:13,277
But when it fires early, it's kind of
disastrous because nothing visibly

91
00:04:13,277 --> 00:04:13,997
explodes.

92
00:04:13,997 --> 00:04:19,235
The tool doesn't say "failure." It
silently swaps a rich history for

93
00:04:19,235 --> 00:04:21,321
a thinner one.Yep.

94
00:04:21,321 --> 00:04:25,556
A loud failure at least has the decency
to ruin your afternoon honestly.

95
00:04:25,556 --> 00:04:31,280
A silent one just makes the work feel
slippery.

96
00:04:25,556 --> 00:04:31,280
And this bug was narrow.

97
00:04:31,280 --> 00:04:37,038
Opus 4.

98
00:04:31,280 --> 00:04:37,038
6 and Sonnet 4.

99
00:04:31,280 --> 00:04:37,038
6 were never affected because they
genuinely use

100
00:04:37,038 --> 00:04:38,638
200K context windows.

101
00:04:38,638 --> 00:04:40,636
So 200K was correct there.

102
00:04:40,636 --> 00:04:43,912
The mismatch only hit Opus 4.

103
00:04:40,636 --> 00:04:43,912
7,

104
00:04:43,912 --> 00:04:48,041
where the native window is 1M.

105
00:04:43,912 --> 00:04:48,041
That distinction is worth underlining.

106
00:04:48,041 --> 00:04:54,315
If someone says, "Hang on, my Sonnet 4.

107
00:04:48,041 --> 00:04:54,315
6 session compacted around 200K and
seemed fine,"

108
00:04:54,315 --> 00:04:57,674
yeah -- that's because 200K is the real
ceiling there.

109
00:04:57,674 --> 00:05:03,227
No funny business.So
this isn't "autocompact bad."

110
00:05:03,227 --> 00:05:06,560
It's "wrong context accounting bad."Bingo.

111
00:05:06,560 --> 00:05:12,232
If the speed limit on the road is 100 and
your brakes kick in at 20,

112
00:05:12,232 --> 00:05:13,594
the brakes aren't evil.

113
00:05:13,594 --> 00:05:18,148
They're just firing at the wrong bloody
time.

114
00:05:13,594 --> 00:05:18,148
There's another update tucked

115
00:05:18,148 --> 00:05:21,320
in here, and this one's more about answer
quality than memory.

116
00:05:21,320 --> 00:05:27,859
On Opus 4.

117
00:05:21,320 --> 00:05:27,859
6 and Sonnet 4.

118
00:05:21,320 --> 00:05:27,859
6, Pro and Max subscribers now default to
`high`

119
00:05:27,859 --> 00:05:29,884
effort instead of `medium` automatically.

120
00:05:29,884 --> 00:05:34,764
No config change needed.

121
00:05:29,884 --> 00:05:34,764
And the key token there is `high`.

122
00:05:34,764 --> 00:05:40,049
Higher effort usually means slightly
higher token usage per response,

123
00:05:40,049 --> 00:05:42,854
but also more deliberate reasoning before
Claude answers.

124
00:05:42,854 --> 00:05:45,572
For code generation, debugging,

125
00:05:45,572 --> 00:05:49,178
architecture decisions -- that's often
where the extra thinking pays

126
00:05:49,178 --> 00:05:54,719
off.

127
00:05:49,178 --> 00:05:54,719
I like that you said "slightly higher
token usage" and not magic.

128
00:05:54,719 --> 00:05:56,237
Because there is a tradeoff.

129
00:05:56,237 --> 00:05:58,159
You are paying for more thought.

130
00:05:58,159 --> 00:06:02,166
The question is whether that should be
the DEFAULT.

131
00:05:58,159 --> 00:06:02,166
I'm mostly yes on

132
00:06:02,166 --> 00:06:02,438
that.

133
00:06:02,438 --> 00:06:07,159
For serious dev workflows, defaulting to
better reasoning feels right.

134
00:06:07,159 --> 00:06:11,637
Most people don't open Claude Code to get
the fastest mediocre answer.

135
00:06:11,637 --> 00:06:16,142
They open it because a wrong migration
plan or a shallow debugging path

136
00:06:16,142 --> 00:06:20,844
costs more than a few extra
tokens.Mostly agree...

137
00:06:20,844 --> 00:06:23,964
but I can hear the indie devs grinding
their teeth already.

138
00:06:23,964 --> 00:06:26,601
If you're doing lots of quick iterations,

139
00:06:26,601 --> 00:06:28,119
cost creep is real.

140
00:06:28,119 --> 00:06:30,514
Tiny per-response bumps add up,

141
00:06:30,514 --> 00:06:34,400
especially if you're in there all day
poking at a big repo.

142
00:06:30,514 --> 00:06:34,400
Sure,

143
00:06:34,400 --> 00:06:37,763
but there's context on the context --
different context,

144
00:06:37,763 --> 00:06:38,245
sorry.

145
00:06:38,245 --> 00:06:43,367
API key, Team, and Enterprise
users were already on `high` by

146
00:06:43,367 --> 00:06:46,325
default since v2.

147
00:06:43,367 --> 00:06:46,325
1.94.

148
00:06:46,325 --> 00:06:49,045
So this isn't some totally new experiment.

149
00:06:49,045 --> 00:06:53,007
It's bringing Pro and Max into line with
what another chunk of the ecosystem

150
00:06:53,007 --> 00:06:57,683
already had.

151
00:06:53,007 --> 00:06:57,683
That v2.

152
00:06:53,007 --> 00:06:57,683
1.94 detail matters.

153
00:06:57,683 --> 00:07:02,464
It tells you Anthropic had already
decided `high` was the sane default

154
00:07:02,464 --> 00:07:03,606
for other user groups.

155
00:07:03,606 --> 00:07:10,717
So for Pro and Max,
this is less a leap and more catching up.

156
00:07:03,606 --> 00:07:10,717
Exactly.

157
00:07:10,717 --> 00:07:15,116
And I think serious coding tasks benefit
from more internal deliberation.

158
00:07:15,116 --> 00:07:18,872
If the model takes a beat and avoids a
bogus refactor,

159
00:07:18,872 --> 00:07:23,000
that's worth more than shaving off a
little token spend.

160
00:07:18,872 --> 00:07:23,000
Maybe.

161
00:07:23,000 --> 00:07:26,881
Though I still reckon defaults should fit
the widest daily use,

162
00:07:26,881 --> 00:07:28,240
not just the heaviest one.

163
00:07:28,240 --> 00:07:30,603
Some people want a sharp pocketknife,

164
00:07:30,603 --> 00:07:34,721
not a whole workshop every time they ask
for a regex.Fair.

165
00:07:34,721 --> 00:07:37,440
But when the tool is aimed at coding,

166
00:07:37,440 --> 00:07:43,400
I'd rather the default bias toward
"thoughtful" than "cheap and hasty."So,

167
00:07:43,400 --> 00:07:44,038
practical stuff.

168
00:07:44,038 --> 00:07:52,442
Update with `npm install -g
@anthropic-ai/claude-code@latest`,

169
00:07:52,442 --> 00:07:54,365
or just let auto-update do its thing.

170
00:07:54,365 --> 00:07:59,742
Then inside a session, use `/context` to
confirm Claude Code is tracking

171
00:07:59,742 --> 00:08:04,982
the correct window size.

172
00:07:59,742 --> 00:08:04,982
That `/context` command is the bit I'd
tell everyone

173
00:08:04,982 --> 00:08:05,753
to remember.

174
00:08:05,753 --> 00:08:07,833
Don't just trust vibes.

175
00:08:07,833 --> 00:08:10,236
Check the actual reported window.

176
00:08:10,236 --> 00:08:15,197
If you were manually disabling
autocompact on Opus 4.

177
00:08:10,236 --> 00:08:15,197
7 as a workaround,

178
00:08:15,197 --> 00:08:19,635
you can re-enable it now because the bug
is fixed and it should behave

179
00:08:19,635 --> 00:08:22,675
properly.

180
00:08:19,635 --> 00:08:22,675
And for effort settings,

181
00:08:22,675 --> 00:08:26,436
use `/effort` to inspect what's active.

182
00:08:26,436 --> 00:08:28,676
If you need tighter cost control,

183
00:08:28,676 --> 00:08:31,313
explicitly set `medium` for that session,

184
00:08:31,313 --> 00:08:36,587
or lock `defaultEffortLevel` in your
project's `CLAUDE.

185
00:08:31,313 --> 00:08:36,587
md`.I love that

186
00:08:36,587 --> 00:08:40,960
there are knobs, but this whole update
raises a bigger question for me.

187
00:08:40,960 --> 00:08:45,745
When a tool quietly fixes a
deep session-management bug

188
00:08:45,745 --> 00:08:48,565
and also changes a quality default,

189
00:08:48,565 --> 00:08:53,405
how much do you trust the defaults versus
checking under the hood every

190
00:08:53,405 --> 00:08:57,962
single time?

191
00:08:53,405 --> 00:08:57,962
The phrase "quietly fixes" is the one
that sticks with me.

192
00:08:57,962 --> 00:09:02,955
Because the best version of software is
invisible -- stuff just works.

193
00:09:02,955 --> 00:09:07,496
But invisible changes also mean power
users have to decide where blind

194
00:09:07,496 --> 00:09:09,480
trust ends.

195
00:09:07,496 --> 00:09:09,480
Yeah.

196
00:09:09,480 --> 00:09:12,882
I don't wanna babysit every setting like
a nervous mechanic listening

197
00:09:12,882 --> 00:09:14,280
for a weird rattle.

198
00:09:14,280 --> 00:09:17,760
But I also don't wanna be the mug who
assumes the dashboard is right

199
00:09:17,760 --> 00:09:21,415
while the engine light's been
unplugged.Maybe that's the real

200
00:09:17,760 --> 00:09:21,415
modern

201
00:09:21,415 --> 00:09:25,443
developer skill now: not just using smart
tools,

202
00:09:25,443 --> 00:09:29,439
but periodically auditing what they think
the world looks like.

203
00:09:29,439 --> 00:09:33,705
Context window, effort level,
compaction behavior -- the hidden state

204
00:09:33,705 --> 00:09:36,356
matters.

205
00:09:33,705 --> 00:09:36,356
And if hidden state matters,

206
00:09:36,356 --> 00:09:38,925
defaults stop being boring.

207
00:09:38,925 --> 00:09:40,683
They become a design philosophy.

208
00:09:40,683 --> 00:09:43,086
Are they there to protect most users,

209
00:09:43,086 --> 00:09:45,885
optimize quality, control cost,

210
00:09:45,885 --> 00:09:47,647
or reduce support tickets?

211
00:09:47,647 --> 00:09:50,526
Sometimes those are the same thing...

212
00:09:50,526 --> 00:09:54,811
sometimes not even close.Which
is a pretty good note to leave

213
00:09:54,811 --> 00:09:55,241
hanging.

214
00:09:55,241 --> 00:09:59,507
Check the settings, sure -- but also ask
what the defaults are trying

215
00:09:59,507 --> 00:10:04,560
to optimize for, and whether that's
actually YOUR workflow.

216
00:09:59,507 --> 00:10:04,560
Nice one.

217
00:10:04,560 --> 00:10:06,078
Cheers for listening, folks.