Prevent the 5-hour Codex limit from blocking remaining weekly quota near reset

What variant of Codex are you using?

Codex CLI (v0.153.4)

What feature would you like to see?

Please make the 5-hour Codex usage limit aware of the weekly reset boundary so that the short-term limit cannot make otherwise-valid weekly quota unusable solely because the two windows are misaligned.

A particularly useful remedy would be:

During the final 5 hours before the weekly reset, suspend the 5-hour limiter and allow usage to continue up to the remaining weekly allowance.

This would allow users to consume weekly quota that would otherwise expire while still blocked by an older 5-hour window.

Other implementations that would solve the same underlying problem would also be reasonable, for example:

• truncate or refresh the active 5-hour window at the weekly reset boundary;
• allow the 5-hour window to be reset independently without resetting/re-anchoring the weekly window; or
• allow manual resets to target the 5-hour window, weekly window, or both.

The desired invariant is:

The 5-hour limiter should not make otherwise-valid weekly quota inaccessible solely because its reset epoch is misaligned with the weekly reset.

I am not requesting a larger weekly allowance. The request is to avoid quota becoming effectively stranded because two independently timed limiters interact across the weekly reset boundary.

Additional information

Concrete example from my account:

• ChatGPT plan: Plus
• Client: Codex CLI v0.153.4
• 5-hour limit: 30% remaining, resetting at 23:45
• Weekly limit: 23% remaining, resetting at 21:45

The weekly reset was therefore scheduled 2 hours before the active 5-hour window reset.

This creates an awkward boundary condition: the weekly allowance can refresh while the user remains constrained by an older, substantially consumed 5-hour window. Conversely, immediately before the weekly reset, remaining weekly quota can potentially expire without being usable because the 5-hour limiter has already been reached.

The current reset mechanism does not provide a clean workaround because the windows cannot be managed independently.

I believe the final-five-hours rule described above is particularly attractive because it prevents weekly quota from being stranded without requiring any user intervention or changing the weekly allocation itself. I recognize that the 5-hour limit may also serve a burst/capacity-management purpose, so an equivalent implementation that preserves those operational goals while avoiding the boundary condition would address the request as well.

Codex feedback thread:
01a07953-e55b-7a83-b0a7-79bdb4c8f1f4

Feedback was submitted through /feedback without diagnostic logs.

Duplication triage

Related requests such as #43135 and #42980 propose removing or generally bypassing the 5-hour constraint while weekly quota remains. This request is intentionally narrower: the 5-hour limiter may remain in effect during normal usage, but should not strand otherwise-valid quota around the weekly reset boundary solely because the two limiter epochs are misaligned. #43403 proposes capacity-dependent limits, which could be complementary but does not by itself guarantee this property.

Start by tracing how Codex CLI v0.153.4 represents and enforces the 5-hour and weekly usage windows, including the reset mechanism. Check whether this behavior is implemented in the CLI or depends on a service boundary. Done means the 5-hour limiter cannot strand otherwise-valid weekly quota near the weekly reset, with coverage for misaligned reset times.