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_