A $200 Codex weekly limit burned in a median 23 hours

Three hundredths of a second is the median gap between one Codex turn ending and goal mode starting the next. In a write-up published by Relux, that gap is the whole story: an agent waiting on something external can only poll, and every poll resends the entire transcript.

At a glance

• Across 3808 Codex rollouts from July to September 2026, the 52 sessions that had goal mode on consumed 29.2 billion of the archive's 59.2 billion input tokens.
• Codex ships a pause tool, clock.sleep, that sleeps up to twelve hours and wakes on new input, but the built-in model catalog declares it for one model, gpt-6-astra.
• The rollout files behind the numbers are not published, and the formula that turns tokens into a share of a subscription window is not published either, so the accounting stays inferred.

If you have not been following the complaints: subscribers spent the summer asking why a paid Codex limit drains so fast. According to posts on the OpenAI Developer Community forum, one user wrote on August 21, 2026 that the limit drains quickly even on small tasks; another reported on August 22 exhausting a weekly quota in about 12 hours on a 5x plan.

97.8% of the archive's input tokens came from the cache

A model keeps no memory of the conversation. Each time it takes a step, the full transcript goes back in, and it answers with one action: a tool call or a line of text. Ask it to run tail on a log, and you still pay for everything that travelled with the request, like handing over the whole book to have one sentence read aloud.

Providers soften this with the KV cache: if a request starts with the same tokens as the last one, the stored intermediate values are reused instead of recomputed. In the archive, 97.8% of input tokens came from the cache. At OpenAI cached input is billed at 10% of the regular rate and kicks in on prompts longer than 1024 tokens.

Subscriptions work differently. The Codex client receives only a usage percentage and a reset time, and the formula behind that share is not published, so the write-up counts input tokens in full. Over the summer the weekly limit on a 200-dollar Pro account ran out fifteen times, a median 23 hours into the window.

Goal mode starts the next turn 0.03 seconds after the last one ends

Without a goal, a model has a free pause: it ends the turn and goes quiet until a human comes back, and silence costs nothing. With a goal active, the idle handler starts a new turn at once. Measured gaps between turns in the source session ran 0.02 to 0.05 seconds, median 0.03, with no backoff and no default token budget per goal.

The goal contract supplies the other half. Per continuation.md, a turn spent waiting counts as progress only if the model polled a live process during it; saying it is waiting, with no poll, counts as nothing, and only a human can pause the goal. So every turn polls, and every poll pays for the full context.

In the source session, muse-spark 1.3 through the opencode provider, goal mode fired 173 continuations in 48 minutes and 466 model calls, each rereading 120 to 470 thousand tokens, until the provider answered 429. That came to 149 million input tokens, or 188 million an hour. Of the session's 181 turns, 135 were a single poll command.

Why does the pause tool reach only one model?

Codex has the right primitive. clock.sleep sleeps for up to twelve hours and is interrupted by new input; it landed in PR 28429, shipped in 0.141.0 on June 18, 2026, and took its current name in 0.143.0 on July 8. Registration depends on the model's catalog entry declaring clock support, and in the built-in catalog only gpt-6-astra does.

The sources do not say why. The write-up notes that the catalog field is called experimental_supported_tools and that gpt-6-astra carries a second experimental tool in the same field, and reads the pattern as a staged rollout. Across the 3808 sessions, sleep was called 420 times, 418 of them by gpt-6-astra.

The fallback is the shell, and in the source session a float closed it. muse-spark sent 60000.0 where the parser wants an integer, so 10 of 10 write_stdin calls and 23 of 25 calls carrying yield_time_ms failed with a type error. Every shell trip stayed at the 10-second default.

Claude Code defers the first check-in for 30 minutes, then doubles it

Per its docs, Claude Code runs the same kind of mode through a different dispatcher: a small model checks the goal condition after each turn, and if a background command or subagent is still running, the check is deferred and its result arrives later as a new turn. On long background work the first check-in comes after 30 minutes, the interval doubles, and there are at most three without a human.

It also stops the loop after several turns with no tool calls. In the Codex archive, fourteen empty continuations in one session cost 77 million input tokens.

Longer pauses per call are what make an hour of waiting cheap. One gpt-5.6-sol session held 30 seconds per call and spent 83 million input tokens per hour of waiting. In another session the model kept reading output with an empty write_stdin, got five minutes per pause, and the hour cost 20 million. The two goal sessions on gpt-6-astra called clock.sleep 60 and 129 times at 45 seconds each, and an hour cost 10 to 15 million.

The rollouts behind all of this are not published, only the code links are. The author also flags that the preferred fix at home, waiting for all child processes with one call plus a budget per goal, has not been verified at scale, and struck out an earlier claim that carried an API rate-limit rule over to subscriptions. In our view the odd part is the split: goal mode is on for every model, the tool that keeps it from spinning for one.

Where a Codex-side fix would land

The asks are small: register clock.sleep whenever a thread has an active goal, add a delay between continuations after a waiting or empty turn, accept 60000.0 where an integer is expected, and name a long sleep as a valid wait in continuation.md. No timeline for any of that has been given. The lever you have today is the config flag sleep_tool set to always_on, which adds the tool but not the habit of using it.