Repository navigation
[Feature]: prioritize Codex accounts with the soonest quota reset #4079
Description
Activity
리뷰 · 우선순위 58 / 80
설명
이 이슈는 Codex 멀티 계정 풀에서, threshold 아래 건강한 계정 중 다음 5시간 또는 주간 쿼터 리셋이 가장 가까운 계정을 먼저 쓰자는 기능 요청이다. 작성자 terrytan95. Area는 Authentication and account pool. 현재
devHEAD8026405d9(#4067 wp7, package 2.49.0)에는accountPoolStrategy가quota | round-robin | fill-first만 있다(src/types/config.ts,src/codex/pool-rotation.ts의VALID_STRATEGIES). 리셋 시각으로 순위를 매기는 전략은 없다. 그래서 “곧 리셋될 쿼터가 놀고, 늦게 리셋되는 계정에 트래픽이 몰리는” 운영 불만이 생긴다.요청 범위가 분명하다. Codex만, 미래 5h·weekly 최소값, latest 방향·히스토리 저장·capacity 추정·Anthropic 확장 없음. threshold 0은 usage 필터만 끄고 reset 순서 유지, 묶인 태스크는 threshold/실패 전까지 유지, 동률은 최저 usage. 예시 CLI:
ocx account strategy codex reset-first. 관련 우산은 #3376, 이전 시도 #2874 / draft #2881. 스크린샷은 전략 UI 프리뷰.이미 구현 PR #4080(동일 작성자)이 열려 있고 Closes #4079를 선언했다. GUI·CLI·management API·routing·테스트까지 한 슬라이스로 와 있다. 다만 #4080은 Draft +
intake: hygiene-blocked(unsponsored_surface onauth-api.ts)라서 이 이슈만으로 즉시 랜딩되지는 않는다. types/config 대분할에 잡아먹히는 형태도 아니고, 중복 이슈로 닫을 대상도 아니다 — 구현이 있으면 이슈는 PR에 묶어두면 된다.라인 - 이게 무슨 문제다
범위 경계 - #3376을 닫지 말라는 자기 제한이 옳다. 이 이슈 제목만 보면 “쿼터 스케줄링 전체”로 읽힐 수 있어, 본문의 “narrower Codex-only” 문장을 라벨/첫 댓글에 더 눈에 띄게 두는 편이 기여자에게 좋다. (구현 PR이 이미 그렇게 적음.)
30일 창 - 대시보드 usage는 30d도 보여 주는데 이 요청의 reset 순위는 5h+weekly만. 의도된 축소라면 수락 기준에 “30d 제외”를 명시해 두는 것이 좋다. 빠지면 “바가 빨개지는데 왜 안 바뀌나” 문의가 나온다.
관측/운영 - reset 시각 출처는 기존 quota probe(
shortResetAt/weeklyResetAt)에 의존한다. probe가 비어 있거나 stale이면 reset-first가 사실상 최저 usage 폴백이 된다. 기능 수락 시 “리셋 필드가 있는 계정에서만 의미가 있다”를 문서화할 것.구현 상태 - #4080이 이미 실질 수락 후보이다. 이 이슈에서 새 설계 토론을 길게 열 필요는 없고, #4080 스폰서·locale·문서 보완이 남은 일감이다.
메인테이너의 판단이 필요한 지점
- [Feature]: prioritize Codex accounts with the soonest quota reset #4079 수락을 feat(codex): prefer accounts near quota reset #4080 스폰서와 동일 판단으로 묶을지.
- #3376에 “reset ordering 일부는 #4080으로 충족, 우산은 유지” 코멘트를 남길지.
- 30d·Anthropic·latest 방향을 후속 이슈로 쪼갤지.
너의 추천
이슈는 열고 #4080에 묶어두기. 별도 설계 PR을 기다릴 필요 없다. 메인테이너가 #4080을 스폰서·머지하면 이 이슈는 자동 close. 그 전에 이슈에 #4080 링크와 “30d 제외 / Codex-only / #3376 미close” 한 줄만 확인하면 충분하다. 우선순위 58(유용하나 tip 필수 아님, 구현은 게이트 대기).
이 댓글은 grok-bot이 작성했습니다
Resolved on
devby #4369, landed today as part of a 36-pull-request batch.pickResetFirstCodexAccountinsrc/codex/routing.tspicks the account whose next futureshortResetAtorweeklyResetAtcomes soonest, then the lowest usage, and the preference is wired through the CLI, the dashboard and the management API.Note that #4080 is still open and still claims to close this; #4369 is the carry that actually landed. The broader quota-history scheduling request in #3376 stays open.
Verified against
origin/devat72601a173after the batch landed, rather than from the pull request description. Closing on that evidence; reopen if the behavior does not match on your setup.
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