5-Hour Limit Reset and Consumption Bug

ChatGPT Bugs
1

I encountered incorrect behavior with the Codex CLI 5-hour usage window.

Timeline

  • 16:21 — I submitted the first task, starting a new 5-hour usage window.

  • That task consumed approximately 49%, leaving approximately 51% remaining.

  • The expected expiration of this window was therefore approximately 21:21.

  • 21:19 — I submitted a second task, while the original window was still active and still had approximately 51% remaining.

  • The second task ran for approximately 22 minutes, finishing around 21:41.

  • I sent no additional user messages between 21:19 and 22:00.

  • 22:00 — After the task had completed, I submitted my next user message.

  • Codex rejected the request because the 5-hour limit was already at 0% and reported that it would reset at approximately 02:23.

The 02:23 reset time is the key evidence of the issue.

A 5-hour window ending at 02:23 means that a new usage window was created at approximately 21:23.

However:

  • my previous window expired at approximately 21:21;

  • I did not submit a new user message at 21:23;

  • the only activity at 21:23 was the Codex task that I had already submitted at 21:19 and that was still running.

Therefore, the running task appears to have automatically started a second 5-hour usage window after the first one expired.

This was not simply a stale usage indicator. When I actually submitted another message at 22:00, Codex refused to execute it and explicitly required me to wait until 02:23.

Expected behavior

The task submitted at 21:19 was started while the original usage window was still active.

If an already-running task is allowed to continue after that window expires, it should not automatically create a new 5-hour window without another user message.

Since my first user message after the original window expired was sent at approximately 22:00, I expected that message to start the next 5-hour window, with a reset around 03:00.

Actual behavior

A new window was apparently created at approximately 21:23, while the previous task was still running.

That new window was then fully consumed before my next user message at 22:00.

In other words, a task submitted during one 5-hour window appears to have crossed the reset boundary and automatically started and consumed the following 5-hour window.

Why this is a bug

There was no user action around 21:23 that could have started a new window.

The sequence was:

16:21 → first window starts
21:19 → second task submitted
21:21 → first window expires
~21:23 → second window apparently starts automatically
~21:41 → running task finishes
22:00 → next user message is rejected because the second window is already at 0%
02:23 → reported reset

The reset timestamp therefore shows that the next usage window was started while an existing task was still executing, rather than by a new user message.

Please verify which event created the usage window ending at 02:23, and whether internal model/tool calls from the task submitted at 21:19 were incorrectly treated as activity that starts and consumes a new 5-hour window.

If internal activity from an already-running task can start the next usage window, then a single user-submitted task can consume quota from two consecutive 5-hour windows, which is the behavior being reported here.

2

This is a particularly useful boundary specimen because the reported reset timestamp is independent of your next user message.

I would keep one distinction very explicit, though: the 02:23 reset strongly suggests that some event around ~21:23 established the next five-hour window, but from the user-facing meter alone we cannot yet prove which event did that or whether cross-boundary execution is currently intended accounting behavior.

OpenAI’s current Codex guidance says an active turn can continue after a usage limit, subject to fair-use limits. That supports the continuation itself, but it does not explain whether continued work from a turn started in the old window is supposed to consume a newly opened window automatically.

The smallest additional evidence, without rerunning this deliberately, would be:

  • plan;
  • exact model + reasoning effort for the 21:19 task;
  • the exact rate-limit/reset text shown at 22:00 (screenshot or copied CLI output if preserved);
  • any usage/meter output you happened to capture immediately before 21:19 and after completion;
  • the session/task ID if the CLI exposes one.

The key engineering question is exactly the one you ended with: what event created the window ending at 02:23? If it was continuation activity from the already-running 21:19 turn, was that expected, and can one user-submitted turn legitimately consume from two consecutive five-hour windows?

I would not burn another five-hour window just to reproduce it. This existing timeline is already much more useful than a generic “quota drained too fast” report.