Area
Authentication and account pool
What are you trying to accomplish?
Make quota windows a first-class scheduling input: activate them per account without manual work, order pool selection by when each account's window resets, and estimate how much capacity an account actually has from its observed history.
This consolidates three reports that describe one mechanism from three angles. Each is closed individually and absorbed here:
They share a single blocker: OpenCodex keeps only the newest quota snapshot per account, so nothing downstream can reason about windows over time.
What prevents this today?
Only the latest snapshot is retained. src/codex/quota.ts stores one quota snapshot per account and overwrites it on each observation. Without history, capacity estimation has no input, and reset-window ordering has nothing to sort by.
Pool strategies cannot express reset order. src/types/config.ts limits account-pool strategies to quota, round-robin, and fill-first. There is no way to prefer the account whose window resets soonest, or the one that just reset.
Window activation is manual. src/codex/warmup.ts is an invocation primitive with no reset-driven scheduling, so an account's window starts whenever a request happens to arrive rather than when the operator wants it to.
Note that the observation half now exists: the active account's observed subscription windows are surfaced at provider level (src/providers/muse-subscription-usage.ts, src/providers/registry.ts). The gap is that nothing durably retains or acts on that observation.
What should OpenCodex do?
- Retain a bounded history of quota observations per account rather than a single overwritten snapshot.
- Derive an effective-capacity estimate per account from that history, and surface it with an explicit confidence or sample count so an operator can tell a guess from a measurement.
- Add a reset-window-aware pool ordering strategy that prefers accounts by time-to-reset.
- Activate an account's quota window on a schedule tied to its reset, not to incidental traffic.
Example usage or interface
ocx quota history --account me@example.com
# window observed used est. capacity samples
# 5h 12:00-17:00 61% ~2.1M tokens 18
Alternatives or workarounds
Operators currently watch the dashboard and rotate accounts by hand around reset times, which is exactly the manual loop these three issues each asked to remove.
Additional context
Absorbs #2344, #2874, #2969. Credit for the original analysis belongs to @Michael-Han0608, @wonny-log, and @terrytan95.
PR #2973 by @terrytan95 (auto-activate quota reset windows) is open and addresses item 4; it is not superseded by this issue.
Checks
Area
Authentication and account pool
What are you trying to accomplish?
Make quota windows a first-class scheduling input: activate them per account without manual work, order pool selection by when each account's window resets, and estimate how much capacity an account actually has from its observed history.
This consolidates three reports that describe one mechanism from three angles. Each is closed individually and absorbed here:
They share a single blocker: OpenCodex keeps only the newest quota snapshot per account, so nothing downstream can reason about windows over time.
What prevents this today?
Only the latest snapshot is retained.
src/codex/quota.tsstores one quota snapshot per account and overwrites it on each observation. Without history, capacity estimation has no input, and reset-window ordering has nothing to sort by.Pool strategies cannot express reset order.
src/types/config.tslimits account-pool strategies toquota,round-robin, andfill-first. There is no way to prefer the account whose window resets soonest, or the one that just reset.Window activation is manual.
src/codex/warmup.tsis an invocation primitive with no reset-driven scheduling, so an account's window starts whenever a request happens to arrive rather than when the operator wants it to.Note that the observation half now exists: the active account's observed subscription windows are surfaced at provider level (
src/providers/muse-subscription-usage.ts,src/providers/registry.ts). The gap is that nothing durably retains or acts on that observation.What should OpenCodex do?
Example usage or interface
{ "providers": { "codex": { "accountPool": { "strategy": "reset-window", // prefer the account whose window resets soonest "quotaHistory": { "retain": 200 }, "autoActivateWindows": true } } } }Alternatives or workarounds
Operators currently watch the dashboard and rotate accounts by hand around reset times, which is exactly the manual loop these three issues each asked to remove.
Additional context
Absorbs #2344, #2874, #2969. Credit for the original analysis belongs to @Michael-Han0608, @wonny-log, and @terrytan95.
PR #2973 by @terrytan95 (auto-activate quota reset windows) is open and addresses item 4; it is not superseded by this issue.
Checks