Area
Authentication and account pool
What are you trying to accomplish?
After a quota reset occurs (e.g. weekly limit), I want OpenCodex to optionally perform a brief activation/switch on that account as soon as possible, so the next reset window is locked in from the earliest moment.
If the account is not used right after reset, the next reset time keeps sliding later. Activating early maximises the usable window.
What prevents this today?
Quota reset itself happens on schedule, but the next reset timer appears to be anchored to the first actual use after the reset.
Example:
- Reset becomes available at Aug 1, 17:00
- If I use the account immediately → next reset is Aug 8, 17:00
- If I only use it the next day at 19:00 → next reset slides to Aug 9, 19:00
If I am away or busy at the exact reset moment, the window drifts later and I lose potential usage. There is currently no automatic “briefly touch the account right after reset” behaviour.
What should OpenCodex do?
Add an opt-in feature that, after a reset is detected for an account, automatically performs a short activation (brief switch / minimal use) on that account so the next reset window is fixed as early as possible.
If multiple accounts reset at the same time (or in a short window), process them sequentially: briefly activate account A, then B, then C, etc.
Existing long-running sessions should stay pinned; this is only a short background activation to claim the new window.
Example usage or interface
Setting (opt-in, default off):
- “Auto-activate after reset to lock next window”
Behaviour example:
- Account A weekly quota resets at 16:00
- OpenCodex detects the reset
- Briefly switches/activates account A for a short Setting (opt-in, default off):
- “Auto-activate after reset to lock next window”
Behaviour example:
- Account A weekly quota resets at 16:00
- OpenCodex detects the reset
- Briefly switches/activates account A for a short moment (enough to start the new window)
- Returns to the previously active account / normal routing
- Next reset for A is now anchored near 16:00 one week later instead of sliding
Multiple accounts:
- A, B, C all reset around the same time
- OpenCodex sequentially does a short activation on A → B → C
- Returns to the previously active account / normal routing
- Next reset for A is now anchored near 16:00 one week later instead of sliding
Multiple accounts:
- A, B, C all reset around the same time
- OpenCodex sequentially does a short activation on A → B → C
Alternatives or workarounds
Manually watching reset times and switching to each account right after reset. This works but is easy to miss (sleep, meetings, overnight resets) and does not scale well with many accounts.
Additional context
Goal is not to consume meaningful quota — only to “claim” the post-reset window as early as possible so the next cycle does not drift later.
This is complementary to:
- sequential priority order for normal failover
- auto-redeem of reset credits before expiry
Together they help extract maximum usable time from multi-account pools.
Checks
Area
Authentication and account pool
What are you trying to accomplish?
After a quota reset occurs (e.g. weekly limit), I want OpenCodex to optionally perform a brief activation/switch on that account as soon as possible, so the next reset window is locked in from the earliest moment.
If the account is not used right after reset, the next reset time keeps sliding later. Activating early maximises the usable window.
What prevents this today?
Quota reset itself happens on schedule, but the next reset timer appears to be anchored to the first actual use after the reset.
Example:
If I am away or busy at the exact reset moment, the window drifts later and I lose potential usage. There is currently no automatic “briefly touch the account right after reset” behaviour.
What should OpenCodex do?
Add an opt-in feature that, after a reset is detected for an account, automatically performs a short activation (brief switch / minimal use) on that account so the next reset window is fixed as early as possible.
If multiple accounts reset at the same time (or in a short window), process them sequentially: briefly activate account A, then B, then C, etc.
Existing long-running sessions should stay pinned; this is only a short background activation to claim the new window.
Example usage or interface
Setting (opt-in, default off):
Behaviour example:
Behaviour example:
Multiple accounts:
Multiple accounts:
Alternatives or workarounds
Manually watching reset times and switching to each account right after reset. This works but is easy to miss (sleep, meetings, overnight resets) and does not scale well with many accounts.
Additional context
Goal is not to consume meaningful quota — only to “claim” the post-reset window as early as possible so the next cycle does not drift later.
This is complementary to:
Together they help extract maximum usable time from multi-account pools.
Checks