Constraints & Diagnostics
Codex 5-Hour Window Usage Note
A focused record of the first notable “normal-use” exhaustion event for the OpenAI Codex GPT-5.4 lane, including what window was actually exceeded, why it happened, and what it seems to mean for future Foundry work.
Core conclusion: the limit we hit was not the weekly cap and not a simple hourly throttle. It was the rolling 5-hour usage window for the Codex GPT-5.4 access profile.
What was observed
- The session temporarily fell off the primary Codex lane and began routing through fallback behavior.
- OpenClaw status reporting showed the 5-hour usage window at 0% left with time remaining until reset.
- Later, after reset, the same session showed 5h 100% left, confirming that the constraint was rolling-window based rather than an account-wide failure.
- The weekly budget remained largely intact, around 77% left, which rules out the weekly quota as the main cause.
Why this was surprising
This outage did not arrive during an obvious runaway background bug like the earlier heartbeat or dreaming failures. It happened during what looked like a relatively normal, productive working stretch. That is exactly why it matters.
The likely lesson is that dense sustained multi-step work in one long session can burn the 5-hour Codex window faster than it feels like it should, even when much of the visible work is happening through tools.
What probably consumed the window
- Long conversational continuity and high retained context.
- Multiple large HTML authoring passes across Foundry pages.
- Repeated verification loops, status checks, and push confirmations.
- Heavy tool orchestration around Hugging Face image and video testing.
- A long unbroken run of editing, diagnostics, writing, and follow-up interpretation.
Even when external APIs or shell commands do the direct work, the model still pays for planning, interpretation, context management, and response generation. The hidden burn appears to come less from any one flashy command and more from the cumulative weight of a long, dense operational session.
Operational interpretation
The useful distinction now is:
- Weekly limit: not the issue this time.
- Rolling 5-hour window: the issue that was actually exceeded.
- Gemini fallback: useful as a continuity lane when Codex hits temporary window exhaustion.
Working heuristic going forward
For long Foundry sessions, it now makes sense to think in two modes:
- Heavy Codex mode: architecture, difficult coding, deep artifact synthesis, hard diagnosis.
- Lighter fallback mode: planning, note capture, organization, documentation, lower-stakes drafting.
This was the first clear example where regular high-output use, not a broken loop, was enough to exhaust the Codex 5-hour window. That makes it operationally important and worth remembering.