Return banked resets redeemed within 24 hours before a global usage reset

Open 💬 1 comment Opened Aug 1, 2026 by derekszen

What variant of Codex are you using?

Codex App, Web, and CLI. This is an account-level usage/reset behavior rather than a client-specific feature.

What feature would you like to see?

When OpenAI applies a server-initiated global (hard) usage reset, automatically return any banked reset that the account redeemed during the preceding 24 hours.

Public global resets are often announced at or after the time they are applied. A user can therefore redeem a banked reset, then have the same usage allowance reset globally minutes or hours later. The banked reset provided almost no durable benefit, but the credit is still consumed.

Proposed behavior:

Use the effective timestamp of the server-side global/admin reset; do not depend on detecting a social-media post.
Look back 24 hours for banked-reset redemptions on each affected account.
Re-credit each qualifying reset with the same expiration semantics it would have had if it had not been redeemed.
Do not apply this to normal scheduled quota rollovers or user-initiated resets.
Make the reimbursement idempotent so retrying a global-reset job cannot grant duplicate credits.
Show a usage-history entry such as: Banked reset returned because a global usage reset occurred within 24 hours.

This preserves the benefit of surprise global resets without penalizing users who happened to spend a banked reset shortly beforehand.

Additional information

A recent example is the July 28 global reset announced by Tibo:
https://x.com/thsottiaux/status/2081940052154933696

Replies to that announcement include users reporting that they had planned around or just used banked resets, which the immediate hard reset then made effectively go to waste.

Related but distinct issues:

#32218 requests queued automatic redemption when a limit is exhausted.
#33513 reports receiving an automatic reset instead of expected milestone banked resets.

Neither covers returning a successfully redeemed banked reset when an OpenAI-triggered global reset follows shortly afterward.

View original on GitHub ↗

1 Comment

FlapPearLabs · 2 days ago

A fresh real-world example from Aug 25, 2026 makes this issue more painful because of the restored 5-hour limit.

I redeemed a banked full reset because I needed to keep working. Shortly afterward, another server-side/global reset was applied. I had barely used the restored weekly allowance before the global reset overwrote it, so the banked reset was effectively wasted.

The 5-hour cap amplifies the problem: even if a user wants to consume a meaningful part of the newly restored weekly allowance immediately, they cannot. They can hit the 5-hour cap, wait for the next window, and then a surprise global reset can arrive before they have had a realistic chance to use the allowance they spent a banked reset to restore.

So I strongly support the proposed 24-hour reimbursement rule. Ideally:

If a global/admin reset occurs within 24 hours after a banked reset redemption, automatically return that banked reset.
If a global reset is planned and can be announced in advance, warn users before it lands so they do not redeem scarce banked resets unnecessarily.
If advance notice is impossible, the backend reimbursement should be automatic and not depend on users seeing a social post or filing support tickets.
The usage UI should show a reset-event ledger: user redemption vs scheduled reset vs global/admin reset, with timestamps and whether a banked reset was refunded.

This is not asking OpenAI to stop giving global resets—the global resets are appreciated. The problem is that an unannounced hard reset can destroy the value of a scarce banked reset that a user redeemed only hours earlier.