Area
Authentication and account pool
What are you trying to accomplish?
Use multi-account Codex quota before its windows refresh. Among healthy accounts under the configured usage threshold, prefer the account whose next 5-hour or weekly reset is closest.
What prevents this today?
The quota, round-robin, and fill-first strategies do not rank accounts by upcoming quota reset time. Quota that will soon refresh can remain unused while a later-reset account receives traffic.
What should OpenCodex do?
Add a Codex-only reset-first strategy in the dashboard, CLI, and management API. Compare the earliest future 5-hour or weekly reset for each eligible account, after existing priority and maximum-usage threshold rules. Preserve bound tasks until threshold or failure; use the same reset ordering for replacements. Ignore invalid, missing, and elapsed timestamps for reset priority, use lowest usage for ties, and preserve existing best-effort fallback if all accounts exceed the threshold. Threshold zero disables usage filtering but keeps reset ordering.
Example usage or interface
ocx account strategy codex reset-first
With threshold 80%, account A at 20% resets in 2 hours (5h) / 4 days (weekly), while B at 60% resets in 3 hours (5h) / 20 minutes (weekly): select B. If either of B’s usage windows reaches 80%, prefer eligible A.
Alternatives or workarounds
Manual switching requires tracking both reset windows. Lowest usage does not express reset urgency, and round-robin ignores it.
Additional context
Related: #3376 (broader quota scheduling umbrella), #2874 and draft PR #2881 (long-window soonest/latest ordering for Codex and Anthropic). This request is the narrower Codex-only dual-window minimum-reset policy, without a latest direction, history store, capacity estimation, or Anthropic changes.
Screenshot: actual strategy component in an isolated local preview, with no account data.
Checks
Area
Authentication and account pool
What are you trying to accomplish?
Use multi-account Codex quota before its windows refresh. Among healthy accounts under the configured usage threshold, prefer the account whose next 5-hour or weekly reset is closest.
What prevents this today?
The quota, round-robin, and fill-first strategies do not rank accounts by upcoming quota reset time. Quota that will soon refresh can remain unused while a later-reset account receives traffic.
What should OpenCodex do?
Add a Codex-only reset-first strategy in the dashboard, CLI, and management API. Compare the earliest future 5-hour or weekly reset for each eligible account, after existing priority and maximum-usage threshold rules. Preserve bound tasks until threshold or failure; use the same reset ordering for replacements. Ignore invalid, missing, and elapsed timestamps for reset priority, use lowest usage for ties, and preserve existing best-effort fallback if all accounts exceed the threshold. Threshold zero disables usage filtering but keeps reset ordering.
Example usage or interface
ocx account strategy codex reset-firstWith threshold 80%, account A at 20% resets in 2 hours (5h) / 4 days (weekly), while B at 60% resets in 3 hours (5h) / 20 minutes (weekly): select B. If either of B’s usage windows reaches 80%, prefer eligible A.
Alternatives or workarounds
Manual switching requires tracking both reset windows. Lowest usage does not express reset urgency, and round-robin ignores it.
Additional context
Related: #3376 (broader quota scheduling umbrella), #2874 and draft PR #2881 (long-window soonest/latest ordering for Codex and Anthropic). This request is the narrower Codex-only dual-window minimum-reset policy, without a latest direction, history store, capacity estimation, or Anthropic changes.
Screenshot: actual strategy component in an isolated local preview, with no account data.
Checks