Codex on Windows burned my entire usage window on July 29 and produced nothing. I’ve been through the local rollout logs and I don’t think this was a usage problem. I think the client got stuck in a restart/compaction loop.
Context: I run Codex hard — multi-agent workloads, subagents doing bounded implementation tasks, reviews, image generation. Earlier in July I ran much bigger map-reduce jobs than this, with more calls and more fresh token activity, and they finished fine. July 29’s work was smaller.
What it looked like from the outside: the app got so laggy I could barely use the machine. The UI went blank or restarted over and over. At one point it told me to log out and sign back in. When I did and reopened the same sessions, they picked back up instead of showing as canceled or complete.
What the logs show. My reset window started around 12:15pm ET on July 29. By ~4am on the 30th the new allowance was gone. Inside that window:
- ~25,660 model/API call events
- 0 completed image generations
- ~20 straight hours of activity with no successful image result
- one session by itself: 15.7 hours, 2,056 calls, zero images
This wasn’t one long image job. The sessions kept polling and waiting on image state and never reached a generation event.
The part that actually convinces me is the lifecycle data:
- one session initialized 76 times over 29.3 hours (about once every 5.5 minutes)
- 31 sessions initialized more than once
- ~280 session launches over ~32 hours
- 399 context-compaction events on July 29, with several sessions compacting 13-14 times inside the same minute
- 14 interrupted turns
- no auth, quota, rate-limit, or image-generation error anywhere in the logs
Fourteen compactions in one minute isn’t context management. That’s a client that can’t hold a stable context and keeps retrying. Which matches what I saw: lag, blank UI, a re-login prompt, and sessions resuming afterward.
One correction, because I said it badly the first time. I found ~9.31 billion tokens of context traffic across the wider window and called it “billed tokens.” That was wrong. 97.9% of it was cached replay. The actual finding is that the same large contexts got dragged through thousands of turns while nothing converged. The distinct content was a tiny fraction of that total.
Things that appear in my logs for the first time around July 28-29. Offered as breadcrumbs, not as a theory:
- thread_source: “automation”
- GPT-5.6 Terra in some sessions
- mixed CLI versions running at the same time (0.146.0-alpha.3.1 and 0.144.1)
- large batches of sessions launched through the automation path rather than normal user or subagent paths
Questions for anyone at Codex:
- Can logging out and back in cause an existing worker or turn to be replayed, duplicated, or resumed alongside the original?
- Can a session keep running server-side after the desktop app crashes or logs the user out?
- What makes thread_settings_applied fire 76 times in one session, or 13-14 compactions land inside the same minute?
- Is there any circuit breaker for a session that has made thousands of calls with zero results?
- Does the “automation” thread source rebuild or resend more context than normal subagent execution?
I kept the original rollout logs and did the analysis offline. I have per-hour and per-session CSVs, the scripts, file hashes, lifecycle and compaction counts, token figures from Codex’s own usage objects, and an independent tiktoken cross-check. I’m not posting raw prompts, repo contents, or account details here, but I’ll hand sanitized excerpts to engineering if someone tells me which fields they need.
There’s already a private support case for the account side, so I’m not asking the forum to fix my bill. I’m asking whether anyone else has hit this — repeated init, compaction storms, or sessions restarting after a desktop logout. A bounded task ending in 25k calls and zero output shouldn’t be a normal terminal state.