Feature request: make the 5-hour and weekly Codex quotas sequential instead of concurrent

What variant of Codex are you using?

Codex App

What feature would you like to see?

I would like to propose changing the way the 5-hour and weekly usage quotas interact.

Instead of consuming both quotas at the same time, Codex should consume them sequentially.

Proposed behavior:

1. While the 5-hour quota is above 0%, only the 5-hour quota is consumed.
2. The weekly quota does not decrease while the 5-hour quota is available.
3. When the 5-hour quota reaches 0%, Codex should continue working by consuming the weekly quota.
4. When the 5-hour quota resets and becomes available again, Codex should automatically stop consuming the weekly quota and switch back to the 5-hour quota.
5. Codex should stop completely only when both available quota pools are exhausted.

In other words:

5-hour quota > 0
→ consume 5-hour quota only

5-hour quota = 0
→ consume weekly quota

5-hour quota resets above 0
→ stop consuming weekly quota
→ consume 5-hour quota again

5-hour quota = 0 AND weekly quota = 0
→ usage is blocked

Why I think this would be better

The current concurrent quota model can create a frustrating situation where a user still has a large amount of weekly quota remaining, but cannot use Codex because the shorter 5-hour quota has reached 0%.

For example:

• 5-hour quota: 0%
• weekly quota: 50%+ remaining
• result: Codex cannot continue working

From a user's perspective, this makes the remaining weekly quota feel inaccessible even though it is still displayed as available capacity.

This is particularly disruptive for long-running agentic coding tasks.

A single Codex task can involve many tool calls, large context reads, code analysis, searches, tests, and context compaction. If the 5-hour quota is exhausted in the middle of such a task, the task may stop before reaching a useful conclusion.

When the quota resets and the user sends "Continue", Codex often needs to reconstruct the previous state of the task:

• re-read context;
• recover previous conclusions;
• verify earlier work;
• inspect files again;
• sometimes compact or rebuild context;
• determine exactly where execution stopped.

This creates what I would describe as a "recovery tax": part of the newly restored quota is spent reconstructing work that had already been performed before the forced interruption.

In my own long-running Codex workflows, this recovery can consume a noticeable portion of a new 5-hour window before meaningful new progress resumes.

Sequential quota accounting would reduce these interruptions and reduce wasted compute spent recovering interrupted tasks.

This proposal does NOT require removing the 5-hour limit

I am not asking for unlimited usage or for the 5-hour quota to be removed.

The 5-hour quota could still serve as the primary short-term usage pool.

The weekly quota would simply become a real reserve pool after the short-term quota is exhausted.

This would preserve both limits while making their interaction much more useful:

Primary pool:
5-hour quota

Reserve pool:
weekly quota

Only when both are exhausted would Codex stop.

Example

Suppose a user has:

• 5-hour quota: 8% remaining
• weekly quota: 62% remaining

Under the proposed system:

1. Codex consumes the remaining 8% of the 5-hour quota.
2. After it reaches 0%, Codex continues against the weekly quota.
3. If the 5-hour quota later resets to 100%, weekly consumption pauses.
4. Codex starts consuming the refreshed 5-hour quota again.
5. The remaining weekly quota stays available as reserve capacity for the next time the 5-hour quota is exhausted.

Benefits

I think this model would have several advantages:

• fewer forced interruptions during long agentic tasks;
• less quota wasted on recovering interrupted context;
• the weekly quota becomes genuinely usable rather than a second simultaneously-depleting restriction;
• users can make better use of quota they already have;
• the 5-hour quota still protects against very intensive short-term usage;
• weekly usage remains bounded;
• no unlimited usage is introduced;
• the behavior of the two quota indicators becomes easier to understand.

Most importantly, it would improve continuity for professional and long-running Codex workflows without requiring OpenAI to remove either quota.

Optional additional improvement

It would also be very helpful if an already-running Codex turn were allowed a small grace period to finish after a quota reaches 0%, while preventing new tasks from starting.

Even without that additional change, however, I think sequential 5-hour → weekly quota consumption would significantly improve the current experience.

Additional information

No response

No files or tests are named. Start by locating the Codex App quota accounting and reset logic, then trace how the 5-hour and weekly pools are currently enforced. Done means the documented sequential behavior is implemented and covered for exhaustion, reset, and both-pools-exhausted cases.