Allow users to queue one banked usage reset for automatic redemption when a usage limit is exhausted

What variant of Codex are you using?

Codex App

What feature would you like to see?

Summary

Currently, an available banked usage reset can only be redeemed immediately. Please add an opt-in option to queue one reset in advance and redeem it automatically only when the applicable usage limit is exhausted.

Problem

This would be especially useful for long-running or unattended tasks, such as Goals.

A Goal may start while usage is still available but reach a limit before it finishes. Redeeming a reset immediately can waste the usage that is still available. Waiting until the limit is actually reached, however, requires the user to monitor the task and manually redeem the reset at exactly the right time.

If the user is away when the limit is reached, the Goal may be interrupted even though the user already has an available reset and is willing to use it.

Proposed behavior

Alongside the existing immediate redemption action, Codex could provide two options:

• Use reset now
• Queue reset for when the limit is reached

When a reset is queued:

1. The reset remains unused while usage is still available.
2. Codex clearly shows that one reset is queued.
3. The user can cancel the queued redemption at any time before it is used.
4. When the selected Goal or task is blocked because the applicable usage limit is exhausted, Codex redeems the queued reset once.
5. The affected Goal or task continues, or resumes from its existing state, without requiring manual intervention.
6. Codex notifies the user when the reset is redeemed, expires, is canceled, or fails to apply.

Safeguards

This behavior should be strictly opt-in.

• Only one banked reset should be queueable at a time.
• Queueing a reset should authorize only that one reset.
• Codex should not automatically queue or consume future resets.
• Purchased credits should not be consumed as part of this setting.
• The reset should be redeemed only after a real usage-limit block, not merely because a usage indicator temporarily displays 0%.
• If multiple usage limits exist, the UI should clearly indicate which limit or reset scope will trigger the redemption.
• If the selected Goal or task finishes before the limit is reached, the queued action should be cleared and the reset should remain available.
• After the queued reset is used, queueing another reset should require a new explicit action.

Expected outcome

Users could let long-running Goals continue without redeeming a reset too early or continuously monitoring their remaining usage, while retaining full control over whether a scarce reset is consumed.

Additional information

This request is related to #28931, #30952, and #31386, but it proposes a different recovery path.

Those issues focus on pausing a task or resuming it after the normal quota window refreshes. This request is specifically about allowing the user to queue one already-available banked usage reset in advance.

The intended flow is:

usage limit exhausted → redeem one explicitly queued reset → continue the existing task

rather than:

usage limit exhausted → wait for the normal quota refresh → resume later

This is also related to #28382 and #28525, which highlight the importance of explicit user consent before additional credits or resets are consumed, and to #28805, which requests clearer visibility into banked reset state and redemption events.

The proposed feature would be a deliberate, revocable, one-time authorization. It is not a request to automatically consume all available resets, chain multiple resets, or use purchased credits without confirmation.

Possible UI labels include:

• Queue reset
• Auto-redeem at limit
• Use when limit is reached