Global quota resets should be granted as banked reset credits instead of overwriting users' current usage window

Summary

Please consider changing manual/global Codex quota resets so that they are granted as a banked reset credit (a button the user can redeem) instead of immediately resetting every paid user's current quota window.

The current behavior creates a frustrating planning problem for users who already have banked reset credits.

A concrete example of the failure mode:

1. A user reaches their weekly limit.
2. They redeem one of their limited banked reset credits because they need to continue working.
3. A manual/global reset happens shortly afterward.
4. The global reset overwrites the benefit of the credit they just spent.

If the user had known a global reset was coming, they would simply have waited. The result is that a scarce user-controlled reset can lose most of its value purely because of an unpredictable product-side reset.

Why this hurts trust

The problem is not primarily that the quota is too small. It is that the quota becomes hard to plan around.

A user-controlled banked reset is valuable because the user can choose when to spend it. A surprise global reset removes that control and turns reset timing into a guessing game: should the user redeem a credit now, or wait in case a global reset appears later today or tomorrow?

This uncertainty discourages users from relying on Codex for sustained work. Competing products with more predictable quota behavior can feel easier to plan around even when their absolute limits are not necessarily better.

Suggested behavior

When OpenAI wants to grant a manual/global reset, please do one of the following, preferably option 1:

Option 1 — Grant a banked reset credit

Instead of immediately modifying the active quota window, add one temporary or permanent reset credit to the user's account and show a Reset usage button.

Example:

Global Codex reset granted
You have received 1 reset credit.
Redeem it whenever you need it.

This preserves the intended generosity of the global reset while letting the user decide when it is useful.

Option 2 — Protect recently redeemed credits

If an immediate global reset must remain, detect users who redeemed a banked reset shortly before the global reset and restore that credit to their bank.

For example, if a user redeemed a credit within the previous 24 hours, the global reset should either:

• refund that reset credit, or
• convert the global reset into a new banked credit for that user.

Option 3 — Announce the reset in-product before it happens

At minimum, show an authoritative in-product notice several hours before a planned global reset so users do not waste a banked reset unnecessarily.

This overlaps with #35044, which requests authoritative in-product reset notices, but a notice alone still does not solve the underlying issue as cleanly as granting the reset as a redeemable credit.

Expected outcome

Global resets should be additive rather than destructive to user-controlled reset value.

A user who has carefully saved or redeemed a banked reset should never be worse off because OpenAI unexpectedly decided to give everyone a global reset shortly afterward.

The best mental model is simple:

If OpenAI wants to give users an extra reset, give them the reset button — don't press the button for them.

No files, tests, or code entry points are named. Start by tracing the existing global quota-reset and banked-reset-credit flows, then determine which product behavior is intended. Done means a global reset is redeemable without overwriting active usage or wasting a recently redeemed credit, with tests covering the selected behavior.