Let Plus Users Choose How to Consume Their Weekly Codex Quota

Totally agree with you.

I think the current 5-hour Codex usage limit on ChatGPT Plus is too restrictive for developers who use Codex as part of their primary development workflow.

The main issue is not simply the amount of usage available. The 5-hour window itself does not align well with how developers actually work.

Most developers do not work 24 hours a day or distribute their Codex usage evenly throughout the day. In practice, productive development time is usually concentrated within an 8–10 hour working period.

For example, my typical workflow is:

Write requirements → let Codex read and understand a large codebase → modify multiple files → run tests → analyze failures → make additional changes → run tests again.

Codex is involved throughout most of my development process.

With this type of workflow, it is possible to hit the 5-hour limit while still having a significant amount of weekly usage remaining. This interrupts an active development session and forces the developer to wait for the usage window to reset.

Meanwhile, resets that occur during sleep or other non-working hours provide little practical value. As a result, the amount of Codex usage that a developer can realistically utilize during a normal working day can be significantly lower than the theoretical allowance available across 24 hours.

I think a better system could be one of the following:

1. Increase the 5-hour allowance for Plus users.
2. Make the 5-hour limit primarily a safeguard against extreme short-term usage, while allowing the weekly limit to be the main usage constraint.
3. Replace the current system with a daily + weekly allowance, allowing developers to decide how to use their daily capacity during their working hours.
4. Introduce separate 5-hour reset and weekly reset options, potentially including purchasable resets.

The weekly limit already provides a mechanism for controlling overall usage. A very restrictive 5-hour limit on top of it can unnecessarily interrupt legitimate, sustained development workflows.

For developers who use Codex heavily for reading large repositories, implementing features, refactoring code, running tests, debugging, and iterating autonomously, uninterrupted working time is extremely important.

I hope OpenAI will consider adjusting the 5-hour limit for Plus users so that Codex better supports sustained, real-world software development workflows.

I want to add a practical usage perspective to this proposal.

The main problem for me is not simply that a 5-hour limit exists. The problem is how much useful work can actually be completed inside that allowance.

Before the recent changes, I could run several serious project audits using Sol 5.6 with high or ultra reasoning as part of a normal development workflow.

Now, in my current usage, a single substantial Ultra audit can consume most of the 5-hour allowance.

That changes the way I work with Codex completely.

Instead of choosing the model and reasoning level that best fits the task, I now spend a lot of attention managing quota. I reduce reasoning effort, switch from Sol to Terra, split tasks into smaller pieces, reduce context, and avoid deeper audits because I am afraid of exhausting the 5-hour window.

So yes, I can still work with the 5-hour limit, but only by deliberately restricting the quality of the workflow.

There is also a second problem: while trying to protect the 5-hour allowance, the weekly quota can still decrease surprisingly quickly.

That means I am optimizing for one limit while watching the other one fall at a rate that is difficult to predict.

In practice, Sol 5.6 is starting to feel like a luxury model rather than a model I can use normally for serious project work.

Even when I move to Terra to save usage, the reduction in consumption does not always feel proportional enough to restore the workflow I had before.

Another important problem happens near the end of the 5-hour window.

If I have around 10–15% remaining, starting a meaningful task becomes risky.

The task can consume the remaining allowance before reaching a clean completion point. Then I am left with an interrupted workflow and have to resume from an earlier state, rebuild context, repeat reasoning, or re-check previous work.

That recovery itself consumes quota again.

So the cycle becomes:

remaining quota → task starts → quota reaches 0% before a clean completion point → task is interrupted → recovery/resume requires more context and reasoning → more quota is consumed.

This is especially damaging for agentic development because continuity is part of the value of the product.

If users have to constantly reduce reasoning quality, split logically connected work, avoid large-context tasks, or stop using the strongest models in order to stay inside the short-term window, then the system is technically available but the quality of the development workflow is degraded.

I understand the need for compute controls and burst protection. I am not asking for unlimited usage.

What I would like to see is:

• clearer accounting of how much each task consumed from both the 5-hour and weekly quotas;
• better visibility into how model and reasoning level affect quota consumption;
• protection against starting a long task that is unlikely to finish with the remaining short-term allowance;
• reliable checkpointing or completion behavior when a limit is reached mid-task;
• a 5-hour limit that primarily protects infrastructure, while the weekly quota remains the main constraint for normal sustained work.

There is also a perception problem when the 5-hour allowance is exhausted and the immediate path is to purchase additional credits.

Paying for overflow usage is understandable.

But if included usage becomes difficult to use productively without constantly lowering model quality and shortening tasks, it can start to feel less like optional overflow capacity and more like paying just to continue a normal workflow.

I am starting to collect my own examples with task type, model, reasoning level, 5-hour usage before/after, weekly usage before/after, duration, whether the task completed, and whether recovery was required.

I hope more users can add comparable observations so it becomes easier to separate expected model cost from genuinely excessive or inefficient quota consumption.

I want to add one final follow-up after today's actual development session, because I now have a concrete example that illustrates several problems with the current 5-hour system at the same time.

Before the introduction of the 5-hour window, I could reasonably run two or three serious project audits using Sol 5.6 with High or Ultra reasoning over the course of a day or two when the project required it.

That was part of a normal development workflow for me.

Since the introduction of the 5-hour window, I have already changed the way I work considerably.

I use Terra much more often instead of Sol 5.6. I reserve Ultra reasoning for stages where deeper analysis is genuinely necessary. I split larger development work into smaller tasks, reduce context where possible, and avoid unnecessary full-project audits.

In other words, I am already actively trying to conserve compute.

But today's experience showed me that even after making those compromises, the current consumption and interruption behavior can make the workflow inefficient.

A concrete example from today

Before starting one final development/audit stage:

• approximately 47% of my 5-hour allowance remained
• approximately 35% of my weekly allowance remained
• model: Terra
• reasoning: Ultra
• task: a medium-sized final audit/development stage involving code review and implementation
• the larger project had already been divided into smaller stages specifically to control usage

After this run, my 5-hour allowance was almost exhausted and my weekly allowance had dropped to approximately 22%.

The important part is that the task still did not finish.

Near the end, the UI showed approximately 1% of the 5-hour allowance remaining.

I then asked Codex a very simple follow-up question: whether the task had actually been completed.

Instead of being able to confirm the state of the work, Codex reported that the 5-hour usage window needed to reset.

So from my perspective the sequence was:

substantial quota consumed → task remains incomplete → UI still shows ~1% remaining → I spend another interaction simply trying to determine whether the task finished → Codex reports that the 5-hour limit has effectively been reached

This is an important problem because the quota is not only being spent on productive development anymore.

Some of the quota — and potentially part of the next window — is now required simply to determine what happened when the previous window ended.

The recovery cost is the part that concerns me most

When the next 5-hour window becomes available, I cannot simply start the next development stage.

First I need to recover the interrupted one.

That means asking Codex to inspect the current repository state, determine what was completed, determine what remains unfinished, restore the relevant context, establish where the previous reasoning stopped, and then continue from a safe point.

All of that requires additional inference and therefore consumes additional quota.

The effective workflow becomes:

productive work
→ 5-hour quota approaches zero
→ task stops before completion
→ wait for reset
→ spend part of the next quota reconstructing the interrupted state
→ restore context/checkpoint
→ continue the original task
→ only after that return to new productive work

This creates a feedback loop where hitting the quota can itself generate additional quota consumption.

For an agentic coding system, that is particularly expensive because repository state, previous reasoning, intermediate decisions, context and continuity are part of the task.

A coding task is not simply a collection of independent prompts.

This also changes which models I can realistically use

Previously I could use Sol 5.6 High or Ultra for serious audits when the project justified it.

Today I increasingly feel that I have to treat Sol 5.6 as a luxury option.

I move work to Terra, reduce reasoning levels, split tasks more aggressively, reduce context and avoid deeper audits because a single substantial run can represent a significant part of the entire 5-hour allowance.

Historically, comparable development stages in my own workflow felt substantially cheaper — often roughly in the 5–15% range depending on the task, sometimes less.

I cannot provide a controlled historical benchmark for those numbers, so I am explicitly presenting that as my previous practical experience rather than a measured benchmark.

But the difference in how I now have to manage my work is significant.

Instead of selecting the model and reasoning level primarily according to the engineering problem, I increasingly select them according to how much quota I am afraid the task will consume.

That pushes the workflow toward:

smaller models → lower reasoning → smaller context → fragmented tasks → fewer deep audits

This may reduce compute consumption, but it also reduces the quality and continuity of the development process.

There is also a difficult boundary problem

When only 10–15% of the 5-hour allowance remains, I now have to decide whether it is even safe to start another meaningful task.

The quota technically exists.

But if the task consumes that remaining quota without reaching a clean completion point, using the remaining allowance can actually create more work than simply stopping immediately and waiting for the reset.

That means part of the advertised allowance can become practically unusable for meaningful agentic work.

A remaining 10% is not necessarily 10% of useful development capacity if using it risks creating an interrupted state that must be reconstructed later.

Paid overflow also creates an unavoidable perception problem

I understand that compute is expensive and that OpenAI needs short-term capacity controls.

I am not asking for unlimited usage.

I also understand the purpose of offering additional paid credits once included usage is exhausted.

However, from the user's perspective there is an unavoidable question:

If additional compute remains immediately available after payment, while the included 5-hour allowance can interrupt an ordinary development task, it becomes difficult to understand whether such a restrictive short-term boundary is primarily protecting infrastructure capacity or increasingly functioning as a paid continuation point.

I am not claiming that this is the intention.

I am describing how the current system can reasonably be perceived from the user side.

The strongest models remain technically available, but the included quota increasingly encourages me not to use them.

What I think would materially improve this

I would like to see:

• clearer per-task accounting for both 5-hour and weekly consumption;
• better visibility into the expected relative cost of model and reasoning levels;
• more accurate behavior near the displayed 5-hour boundary;
• a warning when the remaining allowance is unlikely to support a substantial new task;
• reliable checkpointing when a task approaches the quota boundary;
• preservation of enough execution state that recovery after reset does not require reconstructing work that was already performed;
• ideally, allowing an already-running task to reach a safe completion/checkpoint instead of stopping at the worst possible point;
• the weekly allowance acting as the primary sustained-work constraint, with the 5-hour window functioning mainly as protection against extreme bursts.

The main issue for me is therefore no longer simply:

"The 5-hour limit is too small."

It is:

The current combination of high task consumption + hard short-term boundary + incomplete tasks + recovery cost can make the effective useful quota considerably smaller than the number shown in the UI.

Today I consumed most of a remaining 5-hour window on a meaningful development stage, did not receive a completed task, reached the boundary while the UI still showed approximately 1%, and now part of my next window may have to be spent simply recovering the work that the previous window interrupted.

That is the behavior I hope OpenAI will investigate.

I will continue collecting real before/after examples rather than treating one session as a controlled benchmark, but I wanted to document this case because it demonstrates why the interruption behavior matters just as much as the nominal size of the quota.