1
00:00:00,119 --> 00:00:04,719
Big thanks to Jellypod for helping us
bring this daily break down to life every

2
00:00:04,819 --> 00:00:05,139
morning.

3
00:00:05,940 --> 00:00:12,059
So, Maya, Python SDK zero point one fifty
four point zero dropped alongside

4
00:00:12,319 --> 00:00:17,840
CLI zero point one fifty five point zero
alpha, and the way we control individual

5
00:00:17,940 --> 00:00:21,500
execution turns in Codex just completely
shifted.

6
00:00:21,861 --> 00:00:23,321
Wait, shifted how?

7
00:00:23,881 --> 00:00:28,841
Like, we are not just setting a global
execution mode for an entire conversation

8
00:00:28,881 --> 00:00:29,241
anymore?

9
00:00:29,583 --> 00:00:30,583
Exactly.

10
00:00:30,639 --> 00:00:33,023
That is where turn service tier comes in.

11
00:00:33,160 --> 00:00:37,503
Before this, if you had an agent running a
multi step pipeline,

12
00:00:37,563 --> 00:00:42,863
say ten routine file reads and then one
massive architectural refactor,

13
00:00:42,883 --> 00:00:45,183
you had to set the tier for the whole
session.

14
00:00:45,290 --> 00:00:48,703
Which meant either paying peak rates for
every minor check,

15
00:00:48,863 --> 00:00:51,823
or dragging your heavy turn through a
slower tier.

16
00:00:52,192 --> 00:00:59,032
Ah, so now on a single turn or run call,
you can just pass turn service tier equals

17
00:00:59,152 --> 00:01:03,772
priority for that critical refactor step,
and then drop right back to the default

18
00:01:03,812 --> 00:01:05,372
tier for the next simple file read.

19
00:01:05,750 --> 00:01:06,550
Right on the money.

20
00:01:06,710 --> 00:01:12,710
It gives you precise control over cost and
latency on a step by step level without

21
00:01:12,772 --> 00:01:15,430
mutating the session's baseline
configuration.

22
00:01:15,798 --> 00:01:19,657
Okay, but what happens when you need to
inspect what happened earlier?

23
00:01:20,197 --> 00:01:25,697
If you are resuming or forking a thread,
doesn't pulling down past history clog up

24
00:01:25,718 --> 00:01:27,517
the model's active context window?

25
00:01:27,875 --> 00:01:32,035
That is the clever part about include
turns on thread resume and fork.

26
00:01:32,131 --> 00:01:38,835
When you pass include turns equals True on
thread point resume or thread point fork,

27
00:01:38,875 --> 00:01:44,355
the client SDK pulls down those full turn
history objects in the API response

28
00:01:44,415 --> 00:01:47,555
payload, but it does it purely for your
client app.

29
00:01:47,742 --> 00:01:52,755
It leaves the model's active LLM context
window completely untouched.

30
00:01:53,151 --> 00:01:54,131
Oh, wow.

31
00:01:54,511 --> 00:01:59,611
So your local user interface or monitoring
tool gets the full rich transcript

32
00:01:59,831 --> 00:02:05,172
history, but you are not burning tokens
re-feeding all that raw text back into the

33
00:02:05,252 --> 00:02:06,931
prompt context for the next turn!

34
00:02:07,333 --> 00:02:08,133
Precisely.

35
00:02:08,320 --> 00:02:14,373
So in code, you might write thread point
turn with turn service tier set to priority

36
00:02:14,493 --> 00:02:19,413
and source set to ci runner, and then
later when you want to display the audit log

37
00:02:19,473 --> 00:02:25,653
locally, you just run thread point resume
with thread id and include turns set to

38
00:02:25,733 --> 00:02:26,213
True.

39
00:02:26,373 --> 00:02:29,893
Clean local data, zero context bloat.

40
00:02:30,376 --> 00:02:36,096
Speaking of alpha releases, I saw there
was a patch update recently in zero point

41
00:02:36,176 --> 00:02:39,796
one fifty five point zero alpha point
three point ten.

42
00:02:40,417 --> 00:02:41,576
What was going on there?

43
00:02:42,221 --> 00:02:45,381
Yeah, according to the official Codex
release notes on GitHub,

44
00:02:45,981 --> 00:02:52,241
version zero point one fifty five point
zero alpha point three point ten actually

45
00:02:52,342 --> 00:02:58,321
reverted a payload change that was causing
GPT six Astra executions to fail mid step

46
00:02:58,382 --> 00:02:59,542
during agent workflows.

47
00:03:00,321 --> 00:03:03,021
It also brought some fixes for worktree
operations.

48
00:03:03,402 --> 00:03:08,282
Oof, failing mid step is the worst kind of
bug for autonomous agents.

49
00:03:08,822 --> 00:03:10,543
Good thing that got reverted quickly.

50
00:03:11,463 --> 00:03:14,423
What about that source parameter you
mentioned earlier?

51
00:03:14,482 --> 00:03:17,583
How does telemetry track where these
requests originate?

52
00:03:18,000 --> 00:03:24,320
Right, source metadata tagging lets you
pass string identifiers like ide extension,

53
00:03:24,373 --> 00:03:29,160
terminal interactive, or ci runner
directly into turn requests.

54
00:03:29,280 --> 00:03:33,920
If you are managing a central developer
platform, your telemetry systems can

55
00:03:33,967 --> 00:03:39,520
immediately filter metric spikes or error
rates by client type rather than grouping

56
00:03:39,556 --> 00:03:41,680
everything into one big black box.

57
00:03:41,967 --> 00:03:46,047
That makes debugging centralized
deployments so much easier.

58
00:03:46,708 --> 00:03:48,547
But, okay, what are the gotchas here?

59
00:03:49,007 --> 00:03:53,588
Anything people need to watch out for when
upgrading to SDK zero point one fifty

60
00:03:53,607 --> 00:03:54,308
four point zero?

61
00:03:54,949 --> 00:03:55,969
A major one!

62
00:03:56,549 --> 00:04:02,250
If your stack relies on custom codex bin
overrides, your binary must be CLI version

63
00:04:02,369 --> 00:04:05,889
zero point one fifty one point zero or
newer.

64
00:04:05,949 --> 00:04:11,190
If you try to use per turn tiering or
ExternalMessage types with an older underlying

65
00:04:11,329 --> 00:04:14,850
CLI binary, it will silently fail or
break.

66
00:04:15,216 --> 00:04:17,316
And what about include turns?

67
00:04:17,696 --> 00:04:20,196
Does that help if a session completely
drops state?

68
00:04:20,542 --> 00:04:22,702
No, and that is a key distinction.

69
00:04:22,832 --> 00:04:27,822
include turns changes what the API returns
in its response payload to your

70
00:04:27,882 --> 00:04:31,982
application, not what the model remembers
in its active memory.

71
00:04:32,195 --> 00:04:36,782
If your underlying session lost state or
truncated its context,

72
00:04:36,822 --> 00:04:40,302
pulling response history won't magically
restore model memory.

73
00:04:40,613 --> 00:04:41,392
Good distinction.

74
00:04:41,953 --> 00:04:45,612
Anything else in the ecosystem round up
worth flagging before we get back to

75
00:04:45,652 --> 00:04:45,932
building?

76
00:04:46,292 --> 00:04:48,132
A couple of nice stability items!

77
00:04:48,279 --> 00:04:53,652
Alpha point two fixed some nasty agent
startup crash bugs, and for Windows

78
00:04:53,703 --> 00:04:59,652
developers building voice tools, the
repository now pins offline Cygwin build inputs

79
00:04:59,732 --> 00:05:06,132
like cygwin build inputs point tar point
gz for deterministic builds.

80
00:05:06,646 --> 00:05:09,586
Love to see deterministic build setups
getting love.

81
00:05:10,206 --> 00:05:13,946
Alright, that is the latest on Codex turns
and patches.

82
00:05:14,507 --> 00:05:15,226
Catch you all tomorrow!