Repository navigation
Allow users to queue one banked usage reset for automatic redemption when a usage limit is exhausted #32218
Description
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 nowQueue reset for when the limit is reached
When a reset is queued:
- The reset remains unused while usage is still available.
- Codex clearly shows that one reset is queued.
- The user can cancel the queued redemption at any time before it is used.
- When the selected Goal or task is blocked because the applicable usage limit is exhausted, Codex redeems the queued reset once.
- The affected Goal or task continues, or resumes from its existing state, without requiring manual intervention.
- 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 resetAuto-redeem at limitUse when limit is reached
Activity
jaydensouthworth commentedon Jul 11, 2026
Agreed this is needed.
It would also be nice for the /goal here to work with the new Sol "extra review," function. It appears as if though it does actually continue even when its being review sometimes. Wonder if that is intended behavior/if codex is bypassing its safety setup.
I have a 40 day goal and these little annoyances with it have been a pain. This would be a good step.
sunjiajunsunjiajun commentedon Jul 17, 2026
I also have this need, especially for long-running CLI sessions.
A session can run unattended for several hours and then stop only because the usage limit is exhausted. In practice, if I already have an available banked reset and I know I want the current task to keep going, it would be useful to authorize Codex in advance to redeem exactly one reset when the limit is actually reached.
This feels even more important now that usage is weekly: using a reset card to let an already-running session continue often makes sense, and manually waiting for the exact moment when quota is exhausted is not practical.
The key point for me is that this should be explicit and scoped: I want to opt in for the current task/session, allow one reset to be used only after a real usage-limit block, and then have Codex continue from the existing state instead of stopping until I return.
hossam-96 commentedon Jul 23, 2026
any updates on this? it's a real need for us, specially with fast draining limits currently going on
postmelee commentedon Aug 18, 2026
Apparently, Claude have suppported this feature?
https://x.com/ClaudeDevs/status/2088014831605702937?s=20
tcreevan commentedon Sep 7, 2026
To expand on this proposal, it would be incredibly valuable if this logic was extended into a permanent feature inside the VS Code Extension parameters.
Adding an opt-in toggle like
codex.usage.autoRedeemBankedResets: booleanwould allow power users to explicitly consent to continuous background consumption of banked tokens. Instead of needing to manually queue them one-by-one or break development flow to access the web dashboard, the extension could seamlessly process the reset the moment active usage hits 0%.To prevent users from accidentally exhausting their entire backlog of bonus resets, the UI should include a secondary "Disable after next activation" checkbox, or automatically toggle itself back off once the current long-running task or session concludes.
axisrow commentedon Oct 5, 2026
Related use case: a saved reset can expire while the user is asleep, even when they intended to use it.
I had a reset scheduled to expire around 5–6 AM in my local time zone. I left Codex working and set an alarm for 5 AM so I could redeem it, but I missed the alarm and woke at 6 AM. The reset had already expired and was lost. It was especially frustrating because I had deliberately planned to use it; I just missed a narrow overnight window.
This issue proposes redeeming a queued reset when a usage limit is exhausted. A separate expiry fallback request proposes automatically applying any still-unused saved reset just before it expires: #32586.
songyb111-gachon commentedon Oct 18, 2026
On Windows, Codex Auto Resume (v0.6.16, unofficial, MIT) has this as an opt-in feature of its advanced edition, Use a reset credit at the limit you pick: you choose ahead of time which limit to spend on (the next 5-hour one, a later one, or the next weekly one), and when that limit is reached while a task is waiting for usage it uses one of your banked resets so the task can go on. Before spending it checks again that the window is still full and how many resets you have (and when the soonest expires), and it never spends more than two a day. On a Codex version where its check of the redeem route has not run yet, it asks you to press a button instead of spending on its own. A native toggle would still be the better fix.
songyb111-gachon commentedon Nov 1, 2026
A follow-up: Codex Auto Resume, the unofficial Windows tool I mentioned above (MIT, not affiliated with OpenAI), is now at v0.6.20. Its advanced edition, off until you turn it on, can use one of your reset credits when a usage limit you picked is reached - and asks first unless you tell it not to - and then continues the conversations you allowed.
A native option in Codex would still be better - this is only a stopgap until then.
iki commentedon Nov 9, 2026
It would be really helpful to be able to mark a banked reset to be used automatically:
It would make it easier to use and solve issues when agents are not capable to use it correctly: #60078
mrjiangqiao commentedon Nov 10, 2026
I am running long-lived Codex tasks unattended while I sleep. I explicitly asked the assistant in a conversation to check my allowance every 30 minutes and redeem one existing banked reset if the remaining allowance falls to 5% or less. I also enabled “Allow your assistant to use resets.” The assistant still cannot carry out that instruction because the setting says resets are never used automatically and a fresh, per-use confirmation would be needed while I am asleep.
This restriction is frankly terrible. It fails to account for a central Codex use case: an agent doing sustained work while its user is away. Telling me to wake up and type “use my reset” at the moment the limit is nearly exhausted defeats the purpose of unattended execution. Falling back to paid credits is not equivalent to using a reset I already have.
Please support explicit, one-time, revocable preauthorization for a specific banked reset and task, with a user-selected threshold (for example, 5% remaining) or a real limit block. Redeem at most that one reset, continue or resume the task, and notify the user with an audit record. Do not buy credits or consume later resets under the same authorization.