1
00:00:00,419 --> 00:00:05,779
So I was looking at my API bill from last
week, Ethan, and I- I- I seriously thought

2
00:00:05,819 --> 00:00:06,679
it was a typo.

3
00:00:07,379 --> 00:00:11,880
I was doing this really basic refactoring
session, just back-and-forth chat in the

4
00:00:11,939 --> 00:00:14,500
terminal, and the token count was...

5
00:00:15,079 --> 00:00:17,139
it was astronomical.

6
00:00:17,199 --> 00:00:20,000
For, like, three-word answers from the AI.

7
00:00:21,016 --> 00:00:25,317
Yeah, you got hit by the, uh, what people
are calling the context window tax.

8
00:00:25,897 --> 00:00:29,356
It is a very real, very expensive thing.

9
00:00:29,436 --> 00:00:36,357
But, the cool thing is, the v0.145.2
update that just rolled out-literally like

10
00:00:36,396 --> 00:00:39,696
a day or two ago-it actually addresses
this head-on.

11
00:00:40,216 --> 00:00:42,216
They're trying to stop that silent
bleeding.

12
00:00:42,750 --> 00:00:43,829
Wait, really?

13
00:00:44,389 --> 00:00:49,149
Because I- I- I couldn't figure out why a
simple "yes" to a code suggestion was

14
00:00:49,210 --> 00:00:49,730
costing me...

15
00:00:50,389 --> 00:00:52,309
what, like, thousands of tokens?

16
00:00:53,090 --> 00:00:55,289
How is that even possible under the hood?

17
00:00:55,833 --> 00:00:59,833
Okay, so think about what actually goes to
the model every time you press enter.

18
00:01:00,046 --> 00:01:02,313
It's not just your message, right?

19
00:01:02,513 --> 00:01:04,993
Codex has to know your environment.

20
00:01:05,113 --> 00:01:11,513
So, before v0.145.2, the system was
prepending this massive,

21
00:01:11,913 --> 00:01:18,313
1,800-token system configuration to *every
single turn* in the chat thread.

22
00:01:18,500 --> 00:01:22,873
It's got your platform detection, your
local environment variables,

23
00:01:22,973 --> 00:01:24,873
the terminal status...

24
00:01:24,913 --> 00:01:25,433
all of it.

25
00:01:25,593 --> 00:01:27,193
Over and over.

26
00:01:27,567 --> 00:01:28,507
Oh, wow.

27
00:01:28,887 --> 00:01:35,708
So every time I say "looks good," it's
re-sending those 1,800 tokens of...

28
00:01:35,747 --> 00:01:37,928
basically redundant setup info?

29
00:01:38,987 --> 00:01:39,567
That's...

30
00:01:39,628 --> 00:01:41,347
that's incredibly wasteful.

31
00:01:41,708 --> 00:01:42,828
Exactly.

32
00:01:42,908 --> 00:01:44,188
It's a huge tax.

33
00:01:44,308 --> 00:01:49,628
But in 145.2, they started doing this
clever thing where they hash the environment

34
00:01:49,685 --> 00:01:51,148
configuration on startup.

35
00:01:51,268 --> 00:01:57,708
Instead of sending the whole 1,800-token
beast every time, the client now only sends

36
00:01:57,748 --> 00:02:01,868
a minimal diff-payload-just a delta of
what actually changed,

37
00:02:01,921 --> 00:02:02,588
if anything.

38
00:02:02,801 --> 00:02:07,708
If your environment vars haven't changed,
it sends almost nothing for that header.

39
00:02:08,127 --> 00:02:08,587
Huh.

40
00:02:09,448 --> 00:02:10,007
So it's like...

41
00:02:10,428 --> 00:02:14,827
instead of re-sending the whole blueprint
of my house every time I want to paint a

42
00:02:14,927 --> 00:02:19,467
door, it just says, "Hey, same house, but
we're painting the kitchen door now."

43
00:02:20,051 --> 00:02:20,451
Yes!

44
00:02:20,691 --> 00:02:21,331
Exactly.

45
00:02:21,891 --> 00:02:25,811
And when you map that out over a long
session, the math gets pretty wild.

46
00:02:26,491 --> 00:02:28,712
Let's say you're in a 50-turn coding
thread.

47
00:02:29,371 --> 00:02:33,651
Under the old system, by the time you get
to that final turn-maybe you're just

48
00:02:33,712 --> 00:02:39,091
typing "yes" to approve a code
block-you've accumulated all those repeated system

49
00:02:39,171 --> 00:02:39,551
headers.

50
00:02:40,111 --> 00:02:45,891
That single "yes" turn could cost you up
to 90,000 tokens of total billed context

51
00:02:46,331 --> 00:02:49,191
because of the accumulation and repeated
bloat.

52
00:02:50,449 --> 00:02:51,129
Ninety...

53
00:02:51,669 --> 00:02:53,610
ninety thousand tokens?

54
00:02:53,889 --> 00:02:55,629
For a one-word answer?

55
00:02:56,210 --> 00:02:56,889
That is...

56
00:02:56,949 --> 00:03:01,889
I mean, that's pennies per call, but it
adds up to real money so fast.

57
00:03:02,292 --> 00:03:03,572
It really does.

58
00:03:03,652 --> 00:03:10,292
But with this new delta-tracking in 145.2,
that exact same 50-turn approval message?

59
00:03:10,532 --> 00:03:13,172
It drops to under 4,000 tokens.

60
00:03:13,300 --> 00:03:19,732
They're seeing up to a 40% reduction in
overall API billing for these dense,

61
00:03:19,796 --> 00:03:21,012
long-running sessions.

62
00:03:21,399 --> 00:03:23,480
That is a massive save.

63
00:03:24,079 --> 00:03:27,199
Okay, so that explains why my bill looked
like a car payment.

64
00:03:27,779 --> 00:03:29,519
I need to update immediately.

65
00:03:29,875 --> 00:03:31,315
You definitely should.

66
00:03:31,375 --> 00:03:36,115
But, uh, speaking of updating, there is
another feature in this patch that is...

67
00:03:36,163 --> 00:03:38,595
well, it's a bit of a double-edged sword.

68
00:03:38,627 --> 00:03:42,515
They introduced this new flag:
--cache-auth-tokens.

69
00:03:43,019 --> 00:03:48,839
Okay, "cache auth tokens" sounds like one
of those things that's super convenient

70
00:03:49,480 --> 00:03:53,059
right up until it completely breaks your
pipeline at 3:00 AM.

71
00:03:54,674 --> 00:03:56,774
You have the classic tester intuition.

72
00:03:57,454 --> 00:03:58,934
That is exactly the worry.

73
00:03:59,554 --> 00:04:04,295
It's designed for headless
environments-like if you have a cron job doing autonomous

74
00:04:04,394 --> 00:04:09,875
refactoring overnight, or a CI/CD pipeline
running checks without a human there to

75
00:04:09,934 --> 00:04:12,434
click "approve" on an OAuth screen.

76
00:04:12,899 --> 00:04:16,359
Right, because in a headless runner,
there's no browser.

77
00:04:16,419 --> 00:04:18,519
You can't just log in interactively.

78
00:04:19,000 --> 00:04:20,760
So, how does it actually cache them?

79
00:04:21,125 --> 00:04:27,765
It stores these short-lived JWTs-JSON Web
Tokens-directly in a local

80
00:04:27,877 --> 00:04:29,365
JSON file at

81
00:04:29,745 --> 00:04:35,445
~/.config/codex/credentials.json.

82
00:04:35,645 --> 00:04:38,965
But here is the trap: those tokens expire.

83
00:04:39,125 --> 00:04:44,085
And if your script is running unattended
and the local daemon fails to trigger a

84
00:04:44,129 --> 00:04:45,845
background refresh...

85
00:04:45,925 --> 00:04:46,405
boom.

86
00:04:46,716 --> 00:04:47,917
Wait, so the script just...

87
00:04:48,476 --> 00:04:49,056
dies?

88
00:04:49,536 --> 00:04:52,736
Like, does it throw a clean error, or does
it just spin out?

89
00:04:53,083 --> 00:04:58,203
It fails with an uncaught 401 Unauthorized
mid-run.

90
00:04:58,443 --> 00:05:04,283
If your script doesn't have robust error
handling to catch that specific 401 and try

91
00:05:04,310 --> 00:05:09,643
to re-authenticate or, you know, fail
gracefully, your overnight refactoring run

92
00:05:09,723 --> 00:05:10,603
just...

93
00:05:10,696 --> 00:05:11,243
stops.

94
00:05:11,387 --> 00:05:12,603
Halfway through.

95
00:05:13,417 --> 00:05:16,236
That is a total nightmare for automation.

96
00:05:16,816 --> 00:05:21,596
You wake up thinking your codebase is
fully refactored, and instead you just have a

97
00:05:21,656 --> 00:05:24,156
broken build and a cryptic error log.

98
00:05:25,076 --> 00:05:25,877
I guess...

99
00:05:26,236 --> 00:05:31,337
if you're going to use --cache-auth-tokens
in a cron job, you absolutely have to

100
00:05:31,376 --> 00:05:34,036
wrap that call in some solid
error-catching logic.

101
00:05:34,375 --> 00:05:35,735
Oh, 100%.

102
00:05:35,895 --> 00:05:38,535
Don't just assume the cache is always
fresh.

103
00:05:38,635 --> 00:05:41,415
You've got to write the wrapper to handle
the expiration.

104
00:05:41,575 --> 00:05:45,895
But, on the bright side, they did clean up
some of the noise around failures in this

105
00:05:45,945 --> 00:05:46,695
release too.

106
00:05:46,839 --> 00:05:51,815
They actually quieted down the
standard-error logs when a local tool execution

107
00:05:51,895 --> 00:05:52,375
fails.

108
00:05:52,588 --> 00:05:54,375
It's much less...

109
00:05:54,455 --> 00:05:55,415
chaotic now.

110
00:05:55,836 --> 00:05:57,136
Oh, thank goodness.

111
00:05:57,597 --> 00:06:02,716
My terminal was constantly flooded with
those massive stack traces whenever a simple

112
00:06:02,756 --> 00:06:03,737
linter tool failed.

113
00:06:04,257 --> 00:06:08,856
It made finding the actual error like
searching for a needle in a haystack.

114
00:06:08,936 --> 00:06:11,476
Did they fix that nested folder issue too?

115
00:06:11,517 --> 00:06:12,956
The one with the github workflows?

116
00:06:13,292 --> 00:06:13,852
Yes!

117
00:06:13,948 --> 00:06:15,452
They finally fixed that.

118
00:06:15,543 --> 00:06:20,572
Before this, if you had deeply nested
monorepos, the scanner would sometimes get

119
00:06:20,618 --> 00:06:24,172
caught in this infinite loop scanning
.github folders.

120
00:06:24,385 --> 00:06:27,292
It would just hang there, eating up CPU.

121
00:06:27,492 --> 00:06:32,252
Now, the parser actually respects the
boundaries and stops the infinite recursion.

122
00:06:32,590 --> 00:06:35,849
Honestly, that alone is worth the upgrade.

123
00:06:36,309 --> 00:06:38,969
It's the little quality-of-life things,
you know?

124
00:06:39,589 --> 00:06:45,049
Less noise in the logs, no infinite loops,
and a much smaller bill at the end of the

125
00:06:45,109 --> 00:06:45,389
month.

126
00:06:45,708 --> 00:06:46,548
Exactly.

127
00:06:46,615 --> 00:06:49,388
It's a quiet update, but a really
important one.

128
00:06:49,500 --> 00:06:53,548
Well, that's our quick look at v0.145.2.

129
00:06:53,761 --> 00:06:55,628
Go update your clients, people!

130
00:06:56,004 --> 00:06:57,664
Yeah, save those tokens.

131
00:06:58,065 --> 00:06:58,784
Catch you next time.