Feature Request: Replace the 5-hour Codex quota window with a fixed local-time daily quota

Open 💬 3 comments Opened Aug 25, 2026 by kaisyare
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

I’d like to propose replacing the current 5-hour Codex usage window with a fixed daily quota that resets once per day based on the user’s local timezone, while keeping the existing weekly quota.

This is not a request for more total Codex usage or more compute.

The goal is to let users distribute the same available compute in a way that better matches real software development workflows.

---

Problem

The current 5-hour hard limit can interrupt active development sessions even when a large amount of weekly quota is still available.

For example, I recently reached:

  • 5-hour limit: 0% remaining
  • Weekly limit: 84% remaining

At that point, Codex became unavailable despite most of my weekly allowance still being unused.

This creates an unusual situation where the user is not being limited because of excessive weekly usage, but because their work happened to be concentrated within a particular 5-hour window.

Software development is naturally bursty.

A developer may:

  • spend several hours planning or working manually,
  • use Codex heavily for 3–5 hours while implementing a feature,
  • encounter a difficult bug,
  • and then need another intensive Codex session later the same day.

A rolling 5-hour quota does not align very well with this type of workflow.

---

Proposal

Replace the 5-hour quota with:

1. A fixed daily quota

  • Resets once per day.
  • Reset time is based on the user's local timezone.
  • For example, around 4–5 AM local time.

2. Keep the existing weekly quota

  • The weekly quota would continue to control overall compute usage.
  • The daily quota would only control how quickly that weekly allowance can be consumed.

3. Keep a lightweight burst/rate limit if necessary

  • If infrastructure protection is the reason for the 5-hour window, a separate short-term rate limit could still prevent extreme bursts.
  • This does not need to completely block normal multi-hour development sessions.

Conceptually:

Current:

5-hour quota + weekly quota

Proposed:

daily quota + weekly quota + infrastructure burst protection

---

Why a fixed daily quota?

A fixed daily quota would be much easier for users to understand and plan around.

Instead of:

“My weekly quota is mostly unused, but I cannot work again until this rolling window resets.”

The user would see something predictable like:

Daily quota: 35% remaining Weekly quota: 84% remaining Daily reset: 5:00 AM local time

That makes it possible to plan a working day around the available quota.

It also avoids situations where the quota reset occurs at an arbitrary time based on when a previous usage window began.

---

Why local time?

Using the user's local timezone would align the quota with a normal work/sleep cycle.

A reset during early morning hours would effectively create a new allowance for each working day.

It would also naturally distribute resets globally instead of resetting every user at the same UTC time.

Timezone abuse could be prevented by tying the reset timezone to the account/billing region or limiting how frequently users can change their quota timezone.

---

Compute cost does not need to increase

Again, this proposal does not require increasing the total amount of compute available to Plus users.

OpenAI could determine a daily allowance that produces approximately the same average compute consumption as the current 5-hour system.

The difference would be flexibility:

Users could decide when during the day to spend their allowance instead of having their development workflow dictated by a rolling 5-hour window.

The weekly quota would still prevent sustained excessive usage.

---

Why this matters specifically for Codex

Codex is different from a normal conversational product.

Development work often requires long, uninterrupted problem-solving sessions.

Interrupting a coding session because a short quota window has expired can be significantly more disruptive than limiting casual chat usage.

A daily allowance would preserve OpenAI's ability to manage compute while giving developers a much more predictable and natural working window.

---

Alternative

If replacing the 5-hour window entirely is not practical, another option could be allowing users to choose between:

  • 5-hour rolling quota mode
  • fixed daily quota mode

Both could consume the same weekly allowance.

Different users have different working patterns, so even an optional daily quota mode could significantly improve the experience.

---

Thanks for considering this.

I think a daily + weekly quota model could preserve the infrastructure benefits of usage limits while making Codex much easier to use for sustained development work.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #40650
  • #40524

Powered by Codex Action

kaisyare · 17 hours ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. Allow weekly-only Codex usage without the 5-hour limit #40650 Let Plus Users Choose How to Consume Their Weekly Codex Quota #40524 _Powered by Codex Action_

Thanks for flagging these. I reviewed #40650 and #40524.
They address the same underlying problem, but this proposal is specifically about replacing the rolling 5-hour window with a fixed local-time daily quota, rather than removing the short-term limit entirely or switching to a weekly-only model.

I’ll keep this issue open for now because the proposed quota model is materially different, while treating those issues as related discussions.

kaisyare · 17 hours ago

Related discussions that seem to point to the same broader issue:

  • #40784 proposes a similar shift from the current 5-hour window to a 1-day limit model.
  • #41089 proposes improving quota flexibility by allowing users to control when the 5-hour session begins.

Although the proposed solutions differ, all three issues appear to come from the same underlying problem: the current 5-hour quota model does not align very well with real development workflows, especially for users who work in long, concentrated coding sessions.

I’m linking them here so the related feedback can be considered together.