Let Plus Users Choose How to Consume Their Weekly Codex Quota

What variant of Codex are you using?

App

What feature would you like to see?

Feature Request: Let Plus Users Choose How to Consume Their Weekly Codex Quota

Summary

With the upcoming restoration of the 5-hour usage limit for ChatGPT Plus users on Codex and ChatGPT Work, I would like to propose an alternative:

Keep the weekly quota, but give Plus users the ability to choose how they consume it.

The request is not for unlimited usage or a larger weekly quota. It is about allowing users to manage the quota they have already been allocated according to their own workflows.

A mandatory 5-hour window can unnecessarily interrupt focused development sessions even when a user still has substantial weekly quota remaining.

The Problem

The weekly quota already provides a clear upper bound on total usage.

With only a weekly quota, users can decide how to distribute that allowance:

• Some may spread it evenly throughout the week.
• Some may use Codex only occasionally.
• Others may intentionally consume a large portion during a focused development session, deadline, debugging session, or weekend project.

All of these are legitimate usage patterns.

With a mandatory 5-hour limit, however, a user may encounter a situation like:

Weekly quota remaining: 70%
5-hour quota remaining: 0%

Codex unavailable until the short-term window resets.

From the user's perspective, this is frustrating: there is still plenty of weekly quota available, but it cannot be used when it is actually needed.

Software development does not always happen at a uniform rate.

Developers often work in bursts:

Large refactor
    ↓
Run tests
    ↓
Investigate failures
    ↓
Ask Codex to modify multiple files
    ↓
Run tests again
    ↓
Review changes
    ↓
Continue debugging

Interrupting this workflow because of an additional short-term quota can be significantly more disruptive than reaching a clearly understood weekly limit.

Regarding the Reasons for the 5-Hour Limit

Two reasons have been given for restoring the 5-hour limit:

1. Smoothing compute demand.
2. Preventing Plus users from accidentally consuming their entire weekly allowance too quickly.

Both concerns are understandable.

However, I do not think the second concern requires a mandatory restriction for every Plus user.

Preventing accidental quota exhaustion is fundamentally a user-protection feature.

User-protection features can be enabled by default without being mandatory.

Experienced users who understand the consequences should be allowed to decide:

"I know this may consume a large percentage of my weekly quota today, and I am willing to accept that."

Users already make similar decisions with cloud computing budgets, API credits, mobile data, battery usage, and many other limited resources.

Proposed Solution: Balanced and Flexible Usage Modes

Please consider introducing two usage modes for Plus users.

Balanced Mode — Default

Usage Mode: Balanced

5-hour protection: Enabled
Weekly quota: Enabled

This would remain the default experience.

It would:

• Smooth compute demand.
• Prevent new or casual users from accidentally exhausting their weekly quota.
• Preserve predictable usage throughout the week.

This directly addresses the concerns behind the 5-hour limit.

Flexible Mode — Opt-In

Usage Mode: Flexible

5-hour protection: Disabled or significantly relaxed
Weekly quota: Enabled

⚠ You may consume your weekly quota much faster.

Users would have to explicitly enable this mode and acknowledge the warning.

The weekly quota would remain unchanged.

Therefore, Flexible Mode would not grant additional weekly compute. It would simply allow users to decide when to consume their existing allocation.

If Removing the 5-Hour Limit Is Not Operationally Possible

If completely disabling the short-term limit creates infrastructure or capacity-planning problems, there are several possible compromises.

For example:

• Allow a larger burst allowance for Plus users.
• Allow users to temporarily borrow from their remaining weekly quota.
• Provide one or more "burst sessions" per week.
• Dynamically relax the 5-hour limit when infrastructure capacity is available.
• Allow users to choose between "Balanced" and "Performance" usage profiles.
• Increase the short-term allowance for users with substantial weekly quota remaining.

Any of these would provide more flexibility without requiring unlimited usage.

Better Quota Transparency

Regardless of the final policy, Codex usage limits would also benefit greatly from better transparency.

Ideally, users should be able to see something like:

5-hour usage
██████████████░░░░░░ 72%
Resets in: 2h 14m

Weekly usage
████████░░░░░░░░░░░░ 38%
Resets: Monday 09:00

Current model: GPT-5.6 Sol

Even better would be some indication of how expensive a task was relative to the user's quota.

Without clear visibility, users may become hesitant to use Codex because they do not know whether the next request will consume 1%, 10%, or a substantial portion of their available window.

This creates usage anxiety, which is not a good experience for a paid developer tool.

Transparent limits are much easier to accept than unpredictable limits.

Why This Matters for Plus Users

Plus users are a diverse group.

Some are casual users, but many are also developers who use Codex seriously while not requiring enough total weekly compute to justify a much more expensive subscription tier.

A developer might use very little Codex from Monday through Friday and then spend several hours working intensively on a project during the weekend.

Another developer might suddenly need several hours of continuous Codex assistance because of a production issue or deadline.

A weekly quota naturally supports these usage patterns.

A strict 5-hour window does not.

The distinction is important:

Total usage and usage distribution are two different things.

If a Plus user has been allocated a certain amount of weekly compute, there is a reasonable argument that they should have some control over when that compute is consumed, within reasonable infrastructure constraints.

This Is Not a Request for Unlimited Codex

To be clear, this proposal is not asking OpenAI to:

• Remove the weekly quota.
• Give Plus users unlimited Codex.
• Give Plus users the same allowance as higher-tier plans.
• Ignore infrastructure constraints.

The proposal is simply:

Keep the weekly quota, but give Plus users more control over how they consume it.

And specifically:

Protecting users from accidentally exhausting their weekly quota should ideally be an opt-out safety feature, rather than a mandatory restriction for users who knowingly want to spend their quota.

Suggested Implementation

A possible implementation could be:

Codex Usage Mode

● Balanced (Recommended)
  Helps distribute your usage throughout the week.
  Includes a 5-hour usage limit.

○ Flexible
  Allows higher short-term usage from your weekly quota.
  You may exhaust your weekly quota significantly earlier.

Weekly quota remaining: 73%

When selecting Flexible:

Flexible usage may consume your weekly Codex allowance quickly.

If you reach your weekly limit, you may not be able to use Codex again until your weekly quota resets.

[Cancel] [I Understand — Enable Flexible Mode]

This preserves a safe default for casual and new users while respecting the preferences of experienced users.

Conclusion

The 5-hour limit may make sense as a default mechanism for capacity management and preventing accidental overuse.

But applying it rigidly to every Plus user reduces flexibility for people whose development workflows naturally involve concentrated periods of activity.

Please consider giving Plus users more control over how their existing weekly Codex quota is distributed.

Default protection for users who want it.
Flexibility for users who understand the trade-off.
The same weekly quota for everyone on the same plan.

I believe this would provide a better balance between infrastructure management, predictable costs, and user autonomy.

Additional information

No response

No file, test, or entry point is named. Start by reviewing the proposed Balanced and Flexible usage modes and the quota-transparency requirements; done means defining an implementable approach that preserves the weekly quota, keeps Balanced as the default, and clearly warns users about Flexible mode trade-offs.