Build1 publisher3 min readPublished
Codex gives the model one bounded turn to pick where its own context gets cut
A design reading of one Codex commit shows the runtime holding a 90% compaction budget and a 95% hard guard, with the model allowed a single bounded step in between to call new_context at a cleaner point.
The Engineer · Build desk

What happened
- In the Codex source tree examined, the runtime derives an automatic-compaction budget from 90% of the raw context window and sets a default effective full-context guard at 95%.
- The optional TokenBudget fallback opens a small interval once the automatic budget is exhausted, appending one prompt to the model-visible conversation and allowing one more bounded model step.
- Absent any model request, the runtime forces the rollover itself when the buffer ends or the total-context guard is reached.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Anyone copying this pattern has to settle which component holds the veto before choosing a percentage, because Codex splits enforcement from cut-point selection and the numbers follow from that split.
- cost Turning the fallback on spends headroom: the extra prompt and step come out of the five points between the budget and the guard, and the runtime decides when that spending stops.
- capability Holding the 95% contract separate from the 90% schedule means a team can retune when rollover happens without reopening the question of whether the next request will fit.
- constraint The design only works where a durable record of messages, tool calls and results already exists, since the active window is treated as disposable.
Two thresholds on one resource look like belt and braces until you separate the schedule from the contract. The 90% budget starts the normal transition while there is still room [3]. The 95% guard is the line total active context is not allowed to cross [3]. In the ordinary Total path with the optional fallback off, 90% fires first and the session never reaches 95% [4]. The guard stays anyway, so the total-context safety contract does not move when someone retunes the rule that schedules rollover [5].
Between the two sit five percentage points of the raw window [17]. When the automatic budget is exhausted, the runtime appends one fallback prompt to the model-visible conversation and lets the model take one more bounded step [7]. If the task has reached a semantic cut point, the model calls `new_context` and the runtime performs the rollover [8]. If the model does not ask, the runtime forces the rollover when the buffer ends or the total guard is reached [9]. The prompt goes into the conversation the model can see, so the request to find a cleaner cut point is charged against the window it is trying to protect [18].
That ordering decides which failures are cheap. A model given the timing decision has the best view of task semantics and can still be late, distracted, or wrong [11]. Here a late model costs one bounded interval; the forced rollover still happens with headroom left [19]. A runtime holding the decision alone cannot tell whether the agent has just finished an investigative phase or is halfway through one [10]. For an agent running in a process I control, I would take this division, because the veto belongs with the component that can enforce the limit. The dev.to analysis states the general rule as "the component that can enforce a resource limit must retain the final veto" [13].
The division does not make the cut point good. When the model never asks, the rollover lands wherever the budget ran out, which is the same behaviour as the fixed-percentage design [22].
Three things have to hold before the 90/95 numbers mean anything in another system. There must be a durable record of messages, tool calls, files and results, so that discarding the active working window loses nothing permanent [14]. The runtime has to measure context pressure itself: this is a client-side policy, not a second provider-side measurement [6]. And the thresholds are policy in one source tree, pinned to Codex commit 8444cf63b50a8a88521e0d2970d49f659b48eac7, not a product contract [1].
One more scoping note. In Codex, compaction can replace old history with a local or remote compacted representation, or start a fresh managed window without asking a model to summarize anything [15]. A rollover path whose only move is to ask the model for a summary is implementing the narrower thing. OpenAI's public API guidance sits one level up: monitor usage, plan ahead, compact after major milestones instead of every turn, and preserve functionally equivalent instructions when resuming [16].
What to watch
- Whether the 90% and 95% defaults survive later Codex commits, since the analysis pins them to one source tree.
- Whether the fallback interval gets an explicit token bound, rather than being limited only by the distance to the total guard.
- Whether OpenAI's API guidance grows a provider-side equivalent of the client-side total-context guard.