[Feature]: reset-window ordering for Codex and Anthropic account pools

[wonny-log]

Area

Authentication and account pool

What are you trying to accomplish?

I want new or currently unbound tasks to drain account quota in an explicit reset-window order while preserving the account affinity of healthy bound tasks.

Two workflows are useful:

• Soonest reset first consumes quota that would expire sooner, reducing capacity lost at the next reset.
• Latest reset first concentrates work on the freshest quota window before moving to accounts whose reset is nearer.

The choice should be explicit because the two policies optimize different operator preferences.

What prevents this today?

The current quota, round-robin, and fill-first strategies do not order eligible accounts by their reported reset timestamps. Manual selection order can approximate this once, but it is static: after an account resets and its next reset timestamp advances, the operator must refresh quota and reorder every account again.

This is especially cumbersome for pools whose weekly reset times are staggered across several days. The dashboard already displays per-account reset timestamps, but routing cannot use the same evidence.

What should OpenCodex do?

Add an opt-in reset-window account-pool strategy with an explicit order:

• soonest: choose the eligible account with the nearest fresh future reset.
• latest: choose the eligible account with the farthest fresh future reset.

The strategy should:

• preserve healthy live thread/session affinity;
• respect pause, reauthentication, cooldown, account usability, and configured selection-order tiers before reset ordering;
• use the provider's governing long quota window (weekly where available, monthly for plans that expose a monthly primary window);
• treat missing, non-finite, elapsed, or stale reset timestamps as unknown evidence;
• prefer accounts with known reset evidence, then fall back deterministically to the existing quota selection when no eligible account has usable reset evidence;
• continue to use autoSwitchThreshold as the drain point, including its existing 0 behavior that disables percentage-driven switching;
• apply the same observable policy to the Codex and opt-in Anthropic account pools where per-account quota evidence is available;
• expose the strategy and direction through config, CLI/management API, dashboard copy, and documentation.

No existing default should change.

Example usage or interface

{
  "accountPoolStrategy": "reset-window",
  "accountPoolResetOrder": "latest",
  "autoSwitchThreshold": 0
}

With eligible accounts reporting future governing resets at Tuesday, Thursday, and Saturday, latest assigns new/unbound work to Saturday first. It keeps doing so until the account reaches the configured drain condition or becomes unavailable, then chooses Thursday and Tuesday.

{
  "accountPoolStrategy": "reset-window",
  "accountPoolResetOrder": "soonest",
  "autoSwitchThreshold": 90
}

The same pool instead assigns new/unbound work to Tuesday first and moves after the 90% drain point. Healthy bound work remains on its affined account.

Suggested dashboard controls:

Rotation strategy: Reset window
Reset order: Soonest first | Latest first

Alternatives or workarounds

• Refresh quota, manually rewrite every account's Selection order, and repeat after each reset.
• Use fill-first, which drains one account but follows stable account-id order rather than reset order.
• Use quota, which balances known usage but does not minimize or maximize reset deadlines.
• Run an external scheduler that rewrites account priorities. This duplicates routing policy outside OpenCodex and can race live quota refreshes.

Additional context

• [Feature]: Account pool round-robin / fill-first rotation strategies #592 / feat(auth): account pool round-robin and fill-first strategies #593 introduced the current account-pool strategy surface and affinity contract.
• [Feature] Let users define the priority order for automatic account failover in the Codex pool #821 covers manually configured account selection order; this proposal is dynamic ordering from fresh quota evidence rather than another static priority mechanism.
• [Feature]: opt-in reset-credit recovery after verified pre-stream quota exhaustion #657 documents autoSwitchThreshold: 0 and rejection-driven recovery, which should remain orthogonal to assignment order.
• feat(combos): add random, least-used, and reset-window routing strategies #2050 uses the name reset-window for an analogous Combo strategy that prefers the nearest future reset. Reusing that vocabulary would keep routing concepts consistent while the account-pool direction setting adds the explicit latest workflow.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.

[lidge-jun]

리뷰 · 우선순위 47 / 80

이 이슈가 원하는 것은 간단하다. Codex 풀과 Anthropic 풀에서, 아직 계정에 안 묶인 새 작업을 reset 시각 순서로 배정하고 싶다. soonest는 곧 리셋되는 쿼터부터 써서, 리셋 때 버려지는 양을 줄인다. latest는 리셋이 먼 계정부터 써서, 신선한 창에 일을 모은다. 이미 묶여 건강히 돌아가는 작업은 계정을 바꾸지 않는다. 지금 dev HEAD(3e3df05aa)의 quota / round-robin / fill-first는 그 시각으로 줄을 세우지 않는다. 대시보드에 reset이 보여도 라우팅은 안 본다. 손으로 선택 순서를 고치면 한 번은 비슷해지지만, 리셋이 지나고 시각이 밀리면 또 고쳐야 한다.

이슈가 적어 둔 경계는 지금 코드와 잘 맞는다. 우선순위 티어, 일시정지, 재인증, 쿨다운은 그대로 두고, reset은 그 다음이다. 기본 전략은 바꾸지 않는다. 5시간 창이 아니라 긴 창(일반은 주간, 월간 플랜은 30일)을 쓰라고 한 것도 Codex 풀이 이미 가진 플랜별 창과 같다. 증거가 없거나 오래되면 지금 quota 고르기로 돌아가라고 한 것도, 잘못된 시각으로 계정을 고르는 것보다 낫다. #2050 콤보 reset-window와 단어를 맞추자고 한 것은 읽기에는 편하다. 다만 콤보는 가장 가까운 아무 창만 고르고 latest가 없다. 같은 단어가 두 곳에서 다른 일을 한다.

구현은 이미 초안 PR #2881로 열려 있다. 48파일이고 GUI·CLI·문서까지 한 덩어리다. 위생 검사가 관리 API 면을 막아 intake: hygiene-blocked다. 이 이슈를 따로 또 구현할 필요는 없다. Kiro 풀(#2875/#2878/#2880)은 이 글이 요청한 범위가 아니다. #2783은 리셋이 지나갔는지를 알려 주는 쪽이고, 줄을 세우는 이 이슈와는 다르다. #2560은 Anthropic 풀을 다른 방향으로 넓히려는 초안이라, 둘을 같이 넣으면 전략 키가 싸운다.

이슈 본문의 예시 JSON(accountPoolStrategy / accountPoolResetOrder / autoSwitchThreshold: 0)은 #2881이 그대로 따라간다. 0이 퍼센트 전환만 끄고 배정과 장애 복구는 남긴다는 #657 설명과도 맞다. 빠진 것은 “콤보 reset-window와 무엇이 다른지”, “Kiro는 이번이 아닌지”, “증거가 오래됐다는 기준이 디스크 6시간인지 메모리 TTL인지” 세 줄이다.

경로/이슈 범위 - Codex와 Anthropic만 적혀 있다. 지금 dev가 만들고 있는 Kiro 계정 풀은 요청에 없다. 나중에 Kiro에도 같은 버튼을 달지, 이 이슈는 여기까지인지를 본문에 한 줄 더 적으면 구현 PR이 범위를 넘지 않는다.

경로/단어 reset-window - #2050 콤보 전략과 이름이 같다. 콤보는 5시간 창도 보고 방향이 하나다. 이 이슈는 긴 창과 soonest/latest다. 운영자가 설정 두 곳을 같은 뜻으로 읽지 않게, 이슈 본문에 차이를 남겨 두는 편이 좋다.

경로/#2881 - 구현이 이미 있다. 이 이슈를 열린 채로 두고 그 PR만 보면 된다. 두 번째 구현을 열면 중복이다.

경로/#2560, #2783 - Anthropic 풀 초안과 리셋 알림 PR이 따로 있다. 역할을 나누지 않으면 기여자가 같은 설정 키를 두 번 고친다.

경로/오래됨 - “stale reset timestamps”라고만 되어 있다. Codex 디스크 스냅샷은 6시간, 메모리 TTL은 더 짧을 수 있다. 구현이 어느 시계를 쓸지 이슈가 정해 주면 #2881 테스트가 그 숫자를 잠글 수 있다.

메인테이너의 판단이 필요한 지점

• 이 이슈의 구현을 feat(codex): add reset-window account routing #2881 하나로 볼지
• 콤보와 풀의 reset-window를 같은 이름으로 둘지
• Kiro 풀은 후속 이슈로 따로 열지
• 증거 오래됨을 6시간 디스크 수명으로 볼지, 더 짧은 메모리 TTL로 볼지

너의 추천
이 이슈는 열어 두고, 구현은 #2881만 본다. 두 번째 PR을 열지 마라. 본문에 콤보와의 차이, Kiro는 이번이 아님, 오래됨의 시계 세 줄을 보태면 초안 리뷰가 수월해진다. types/config 분할 때문에 닫을 대상은 아니다. #2881이 스폰서를 받고 초안을 벗으면 그때 이 이슈를 같이 닫으면 된다.

이 댓글은 grok-bot이 작성했습니다