1
00:00:00,000 --> 00:00:01,359
Welcome to the show.

2
00:00:01,359 --> 00:00:05,893
James, imagine this: you've loaded up a
monster prompt -- big system

3
00:00:05,893 --> 00:00:08,560
instructions, a chunky `CLAUDE.

4
00:00:05,893 --> 00:00:08,560
md`,

5
00:00:08,560 --> 00:00:12,401
maybe a 100K-token context -- then you
stand up for,

6
00:00:12,401 --> 00:00:14,157
I dunno, a quick bathroom break,

7
00:00:14,157 --> 00:00:18,013
come back six minutes later,
and the whole expensive prefix has gone

8
00:00:18,013 --> 00:00:18,477
cold.

9
00:00:18,477 --> 00:00:19,477
Gone.

10
00:00:19,477 --> 00:00:23,231
You're paying to shove the same truckload
back through the gate again.[questioning

11
00:00:23,231 --> 00:00:25,075
tone] Six minutes later is the killer
part.

12
00:00:25,075 --> 00:00:30,433
Not "tomorrow," not "after lunch" -- six
minutes.

13
00:00:30,433 --> 00:00:36,325
So the old 5-minute TTL basically meant a
normal human pause could blow

14
00:00:36,325 --> 00:00:39,237
up your cache?Exactly.

15
00:00:39,237 --> 00:00:45,920
And Claude Code v2.

16
00:00:39,237 --> 00:00:45,920
1.108 changes that in a really meaningful
way.

17
00:00:45,920 --> 00:00:49,360
There's a new flag,
`ENABLE_PROMPT_CACHING_1H`,

18
00:00:49,360 --> 00:00:55,206
and it bumps the default prompt-cache TTL
from 5 minutes to 1 hour for

19
00:00:55,206 --> 00:00:59,763
API key, Bedrock, Vertex,
and Foundry auth modes.

20
00:00:59,763 --> 00:01:04,565
So in plain English: the pricey front
half of your session gets loaded

21
00:01:04,565 --> 00:01:09,862
once, then stays warm for an actual work
block instead of expiring while

22
00:01:09,862 --> 00:01:13,964
you're refilling your coffee.
`1H` is the memorable token

23
00:01:13,964 --> 00:01:14,564
there.

24
00:01:14,564 --> 00:01:17,521
From 5 minutes to 60 minutes is not a
tweak.

25
00:01:17,521 --> 00:01:19,448
That's twelve times longer.

26
00:01:19,448 --> 00:01:22,492
If your prefix is 100K tokens,

27
00:01:22,492 --> 00:01:26,934
that's the difference between
"interactive coding assistant" and

28
00:01:22,492 --> 00:01:26,934
"meter's

29
00:01:26,934 --> 00:01:30,042
running while I wash my hands."
Yeah,

30
00:01:30,042 --> 00:01:33,271
it's the difference between a ute with a
full tank and one that stalls

31
00:01:33,271 --> 00:01:34,283
at every traffic light.

32
00:01:34,283 --> 00:01:39,727
And this matters most when your prefix is
fat: a long system prompt,

33
00:01:39,727 --> 00:01:42,126
a carefully built `CLAUDE.

34
00:01:39,727 --> 00:01:42,126
md`,

35
00:01:42,126 --> 00:01:43,885
loads of repo context.

36
00:01:43,885 --> 00:01:48,908
Those are exactly the bits you do NOT
wanna keep resending because they're

37
00:01:48,908 --> 00:01:52,282
the expensive part.

38
00:01:48,908 --> 00:01:52,282
Let me try to explain it back.

39
00:01:52,282 --> 00:02:00,600
The cache is basically holding
onto the repeated prefix -- the

40
00:02:00,600 --> 00:02:03,326
same opening bytes, same instructions,

41
00:02:03,326 --> 00:02:08,437
same big context -- so later turns don't
have to reprocess that whole

42
00:02:08,437 --> 00:02:08,852
chunk.

43
00:02:08,852 --> 00:02:12,932
And the upgrade here is not smarter
caching,

44
00:02:12,932 --> 00:02:14,133
it's longer memory.

45
00:02:14,133 --> 00:02:18,880
Same idea, way less fragile.

46
00:02:14,133 --> 00:02:18,880
That's it.

47
00:02:18,880 --> 00:02:22,201
Not exactly "memory" in the chat-history
sense,

48
00:02:22,201 --> 00:02:24,722
more like the prefix stays preloaded.

49
00:02:24,722 --> 00:02:28,718
Which means if you're working in bursts
-- ask a question,

50
00:02:28,718 --> 00:02:30,638
read code, think for ten minutes,

51
00:02:30,638 --> 00:02:34,395
come back -- you're still sitting on the
warm path.

52
00:02:34,395 --> 00:02:38,369
Before, that ten-minute think was enough
to kick the ladder out from

53
00:02:38,369 --> 00:02:41,760
under you.Okay,
but I want the practical picture.

54
00:02:41,760 --> 00:02:46,726
Say I've got a giant `CLAUDE.

55
00:02:41,760 --> 00:02:46,726
md` at the root of a repo and I'm
pair-programming

56
00:02:46,726 --> 00:02:48,126
for, like, 45 minutes.

57
00:02:48,126 --> 00:02:51,246
Under the new setup,
as long as I don't change the prefix,

58
00:02:51,246 --> 00:02:55,600
that expensive setup cost mostly happens
once?

59
00:02:51,246 --> 00:02:55,600
Mostly,

60
00:02:55,600 --> 00:02:55,880
yeah.

61
00:02:55,880 --> 00:02:57,878
That's the clean mental model.

62
00:02:57,878 --> 00:03:01,156
Load the heavy stuff once,
keep it warm for an hour.

63
00:03:01,156 --> 00:03:04,795
So a normal work session -- not an
all-day marathon,

64
00:03:04,795 --> 00:03:08,590
just a decent block -- stops getting
reset by little gaps.

65
00:03:08,590 --> 00:03:12,188
For people actually using Claude Code
like a tool,

66
00:03:12,188 --> 00:03:17,094
not a benchmark harness, that's a pretty
chunky quality-of-life gain.

67
00:03:12,188 --> 00:03:17,094
And

68
00:03:17,094 --> 00:03:18,915
there's a surprise buried in the same
release,

69
00:03:18,915 --> 00:03:19,315
right?

70
00:03:19,315 --> 00:03:22,116
Because the TTL change is already useful,

71
00:03:22,116 --> 00:06:08,212
but there was also a bug fix tied to
`DISABLE_TELEMETRY`.

72
00:06:08,212 --> 00:06:09,880
Yep, and this bit's sneaky.

73
00:06:09,880 --> 00:06:13,647
The same release fixed a bug where users
with `DISABLE_TELEMETRY` were

74
00:06:13,647 --> 00:06:16,633
silently stuck on the old 5-minute TTL,

75
00:06:16,633 --> 00:06:19,278
even though they should have gotten the
1-hour cache.

76
00:06:19,278 --> 00:06:20,878
Silently is the key word.

77
00:06:20,878 --> 00:06:27,620
No big error, no flashing light -- just
worse caching than

78
00:06:20,878 --> 00:06:27,620
expected.`DISABLE_TELEMETRY`

79
00:06:27,620 --> 00:06:29,680
being the token that makes this sting.

80
00:06:29,680 --> 00:06:34,901
Because the kind of user who sets
`DISABLE_TELEMETRY` is usually the

81
00:06:34,901 --> 00:06:40,375
kind of user who also notices weird cost
behavior and starts debugging

82
00:06:40,375 --> 00:06:41,317
their own workflow.

83
00:06:41,317 --> 00:06:45,938
They may have thought, "Huh,
maybe prompt caching just isn't helping

84
00:06:45,938 --> 00:08:12,403
much," when actually they were pinned to
5 minutes.Right.

85
00:08:12,403 --> 00:08:17,004
And that's why this release feels bigger
than one environment variable.

86
00:08:17,004 --> 00:08:21,365
It's not just "here's a longer cache."
It's also "by the way,

87
00:08:21,365 --> 00:08:25,648
some of you never got the longer window
you were meant to get." That's

88
00:08:25,648 --> 00:08:27,006
a proper gotcha.

89
00:08:27,006 --> 00:08:31,570
Bit of a dog's breakfast, really.

90
00:08:27,006 --> 00:08:31,570
There's also a subtle product point

91
00:08:31,570 --> 00:08:32,162
here.

92
00:08:32,162 --> 00:08:35,914
Five minutes sounds fine on paper if you
think in pure request-response

93
00:08:35,914 --> 00:08:36,408
cycles.

94
00:08:36,408 --> 00:08:39,202
But humans don't work in uninterrupted
loops.

95
00:08:39,202 --> 00:08:42,243
We tab away, read docs, answer Slack,

96
00:08:42,243 --> 00:08:44,403
stare at a test failure,
walk to the kitchen.

97
00:08:44,403 --> 00:08:48,881
One hour maps to reality way
better.Exactly.

98
00:08:48,881 --> 00:08:51,241
Five minutes is machine time.

99
00:08:51,241 --> 00:08:53,201
One hour is people time.

100
00:08:53,201 --> 00:08:56,874
And when the whole point of the tool is
interactive work,

101
00:08:56,874 --> 00:09:02,600
that shift from machine time to people
time is the actual story.

102
00:08:56,874 --> 00:09:02,600
So let's

103
00:09:02,600 --> 00:09:03,760
get concrete on setup.

104
00:09:03,760 --> 00:10:32,034
The new knob is simple: `export
ENABLE_PROMPT_CACHING_1H=1` before

105
00:09:03,760 --> 00:10:32,034
launching

106
00:10:32,034 --> 00:10:32,552
`claude`.

107
00:10:32,552 --> 00:10:35,672
That enables the 1-hour TTL.

108
00:10:35,672 --> 00:10:37,588
And if you need the old behavior,

109
00:10:37,588 --> 00:10:42,463
there's a reverse switch:
`FORCE_PROMPT_CACHING_5M=1`.I

110
00:10:37,588 --> 00:10:42,463
wanna

111
00:10:42,463 --> 00:10:46,239
poke that `FORCE_PROMPT_CACHING_5M=1` bit,

112
00:10:46,239 --> 00:10:48,717
because on first glance it sounds
backwards.

113
00:10:48,717 --> 00:10:54,077
Why would anyone choose the shorter
5-minute TTL after getting the roomy

114
00:10:54,077 --> 00:10:57,361
1-hour one?

115
00:10:54,077 --> 00:10:57,361
Predictability.

116
00:10:57,361 --> 00:11:00,634
Especially for lots of
short `claude --print` jobs,

117
00:11:00,634 --> 00:11:02,071
maybe running in parallel.

118
00:11:02,071 --> 00:11:04,869
If prefixes linger for a full hour,

119
00:11:04,869 --> 00:11:08,103
you can get reuse patterns that are great
for humans but not always what

120
00:11:08,103 --> 00:11:09,424
you want in batch workflows.

121
00:11:09,424 --> 00:11:13,786
The shorter TTL can make per-run billing
behavior feel more bounded and

122
00:11:13,786 --> 00:11:18,679
repeatable.

123
00:11:13,786 --> 00:11:18,679
So the tension is: humans love warm
caches,

124
00:11:18,679 --> 00:11:21,888
automation sometimes loves cleaner edges.

125
00:11:21,888 --> 00:11:23,008
That's fair.

126
00:11:23,008 --> 00:11:25,942
It's a bit like leaving the workshop
lights on because you're ducking

127
00:11:25,942 --> 00:11:29,531
in and out all afternoon versus shutting
everything down between jobs

128
00:11:29,531 --> 00:11:33,121
because you want the ledger neat.

129
00:11:29,531 --> 00:11:33,121
Exactly.

130
00:11:33,121 --> 00:11:37,724
And there's one more compatibility
wrinkle: the old Bedrock-only flag,

131
00:11:37,724 --> 00:11:40,883
`ENABLE_PROMPT_CACHING_1H_BEDROCK`,

132
00:11:40,883 --> 00:11:43,279
is deprecated but still honored.

133
00:11:43,279 --> 00:11:47,632
Which sounds boring until you remember
how many teams have ancient shell

134
00:11:47,632 --> 00:11:52,880
scripts and CI wrappers nobody's touched
in months.Months?

135
00:11:52,880 --> 00:11:56,723
Mate, I've seen env vars survive longer
than houseplants.

136
00:11:56,723 --> 00:12:01,005
But yeah,
`ENABLE_PROMPT_CACHING_1H_BEDROCK` still

137
00:11:56,723 --> 00:12:01,005
being honored matters

138
00:12:01,005 --> 00:12:04,728
because it means old deployment scripts
don't instantly faceplant.

139
00:12:04,728 --> 00:12:08,878
Deprecated, not dead.

140
00:12:04,728 --> 00:12:08,878
That distinction -- deprecated but still
honored

141
00:12:08,878 --> 00:12:10,868
-- is the listener takeaway there.

142
00:12:10,868 --> 00:12:13,346
Your old Bedrock setup may keep working,

143
00:12:13,346 --> 00:12:17,397
but it's a sign to clean house before
that compatibility shim disappears

144
00:12:17,397 --> 00:12:25,823
in some future release.

145
00:12:17,397 --> 00:12:25,823
Now,
big caveat: this does NOT affect `claude.

146
00:12:17,397 --> 00:12:25,823
ai/code`

147
00:12:25,823 --> 00:12:26,634
OAuth sessions.

148
00:12:26,634 --> 00:12:28,720
Those handle caching server-side.

149
00:12:28,720 --> 00:12:31,280
So if someone hears all this and goes,

150
00:12:31,280 --> 00:12:36,624
"Sweet, I'll export the flag and my OAuth
session changes," nah -- wrong

151
00:12:36,624 --> 00:12:37,119
paddock.

152
00:12:37,119 --> 00:12:45,997
Different path entirely.`claude.

153
00:12:37,119 --> 00:12:45,997
ai/code` OAuth being excluded is
important.

154
00:12:45,997 --> 00:12:57,788
Because otherwise people are gonna set
`ENABLE_PROMPT_CACHING_1H=1`,

155
00:12:57,788 --> 00:12:59,433
see no difference in that flow,

156
00:12:59,433 --> 00:13:01,037
and assume the feature is broken.

157
00:13:01,037 --> 00:13:06,233
It's not broken; it just doesn't apply
there.

158
00:13:01,037 --> 00:13:06,233
And here's the edge case

159
00:13:06,233 --> 00:13:11,241
that catches people even when the TTL is
perfect: the cache still breaks

160
00:13:11,241 --> 00:13:13,813
instantly if the prefix bytes change.

161
00:13:13,813 --> 00:13:15,493
Instantly.

162
00:13:15,493 --> 00:13:19,258
Edit the top of `CLAUDE.

163
00:13:15,493 --> 00:13:19,258
md`, tweak the system prompt,

164
00:13:19,258 --> 00:13:23,770
alter those opening bytes, and you've
invalidated the warm cache no matter

165
00:13:23,770 --> 00:13:28,860
whether you picked 5 minutes or 1
hour."Prefix bytes change" is

166
00:13:28,860 --> 00:13:29,715
the phrase to remember.

167
00:13:29,715 --> 00:13:34,678
Not "the meaning changed," not "the
instructions are kinda similar."

168
00:13:34,678 --> 00:13:36,835
If the bytes at the front are different,

169
00:13:36,835 --> 00:13:39,234
the warm cache is gone.

170
00:13:39,234 --> 00:13:43,238
So if you keep fiddling with the top of
`CLAUDE.

171
00:13:39,234 --> 00:13:43,238
md`,

172
00:13:43,238 --> 00:13:47,440
you're basically kicking your own chair
out from under you.

173
00:13:43,238 --> 00:13:47,440
Yeah,

174
00:13:47,440 --> 00:13:48,402
that's the thing.

175
00:13:48,402 --> 00:13:52,525
Folks hear "one-hour cache" and imagine
some magical persistence.

176
00:13:52,525 --> 00:13:54,007
It's not magic.

177
00:13:54,007 --> 00:13:54,926
It's conditional.

178
00:13:54,926 --> 00:13:57,845
Stable prefix, warm cache.

179
00:13:57,845 --> 00:14:00,764
Changed prefix, cold start.

180
00:14:00,764 --> 00:14:02,764
Dead simple once you say it out loud,

181
00:14:02,764 --> 00:14:06,244
but easy to miss when you're in the
weeds.

182
00:14:02,764 --> 00:14:06,244
I actually think that's where

183
00:14:06,244 --> 00:14:07,563
the real decision lives.

184
00:14:07,563 --> 00:14:11,367
If you're an interactive user -- long
repo context,

185
00:14:11,367 --> 00:14:16,225
lots of back-and-forth, normal human
pauses -- the 1-hour TTL is a clear

186
00:14:16,225 --> 00:14:16,685
win.

187
00:14:16,685 --> 00:14:20,483
But if you're running many short `claude
--print` jobs in parallel,

188
00:14:20,483 --> 00:14:23,689
a longer-lived prefix can hang around
longer than you want,

189
00:14:23,689 --> 00:14:27,722
and "better" stops being
universal.Which I like,

190
00:14:27,722 --> 00:14:28,360
honestly.

191
00:14:28,360 --> 00:14:31,953
It means there isn't one blessed setting
for everyone.

192
00:14:31,953 --> 00:14:34,515
One hour is better for people-time.

193
00:14:34,515 --> 00:14:37,394
Five minutes can still be better for
batch-time.

194
00:14:37,394 --> 00:14:40,114
Same tool, different jobs.

195
00:14:40,114 --> 00:14:43,158
And if there's a lesson in this release,

196
00:14:43,158 --> 00:14:47,420
it's probably that the clever bit isn't
the cache itself -- it's knowing

197
00:14:47,420 --> 00:14:51,821
whether you're optimizing for a human at
a keyboard or a pile of automated

198
00:14:51,821 --> 00:14:56,248
runs hammering away in parallel.
That's the question I'd leave people

199
00:14:56,248 --> 00:14:59,971
with before they export anything: are you
trying to keep a conversation

200
00:14:59,971 --> 00:15:02,798
warm, or keep your runs predictable?

201
00:15:02,798 --> 00:15:06,745
Because those are not always the same
goal.And if your answer

202
00:15:06,745 --> 00:15:08,798
is "both," well...

203
00:15:08,798 --> 00:15:12,077
welcome to engineering.

204
00:15:12,077 --> 00:15:13,679
Catch you next time.