Skip to content

[Feature]: Activate Codex quota windows automatically per account #2969

Closed as not planned
Closed as not planned
[Feature]: Activate Codex quota windows automatically per account#2969
Labels
account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requestplatformOS/service/tray/ACL (Windows-heavy, not Windows-only)

Description

@terrytan95
terrytan95
opened on Aug 30, 2026

Area

Multiple areas

What are you trying to accomplish?

Keep every opted-in ChatGPT Codex account's rolling quota windows anchored to their earliest available reset time. When an idle account reaches the start of a new 5-hour or weekly window, OpenCodex should send one minimal Codex request through that exact account so the next reset window starts immediately instead of drifting until the account is used manually.

What prevents this today?

OpenCodex already knows each account's WHAM quota percentages and reset timestamps, and it already has an account-scoped warmup request used after OAuth login. It does not connect those pieces after startup. An account that remains idle past a reset can therefore leave its next rolling-window start deferred, wasting part of the subscription allowance period.

There is also no per-account opt-in control, so users cannot choose which account/window should incur the small activation request.

What should OpenCodex do?

  • Add separate per-account switches for the 5-hour and weekly windows in Codex account settings.
  • Offer a switch only when that account's live quota payload exposes the corresponding window; do not infer support from a brittle plan-name allowlist.
  • Keep both switches off by default.
  • At or just after an enabled window's reported resetAt, send one minimal non-stored Codex message through that exact account using the existing warmup path.
  • If both enabled windows become due together, one message should activate both.
  • Persist the last activated resetAt per account/window so daemon restarts cannot send duplicate activation messages.
  • Refresh WHAM quota after a successful activation to schedule the next window.
  • Skip unavailable or reauthentication-required accounts and retry transient failures without crashing the proxy.

Example usage or interface

For each Codex account card whose WHAM response contains both windows:

Automatic window activation
5-hour  [off/on]
Weekly  [off/on]

An account that exposes only weekly quota shows only the weekly switch. An account with no fixed window shows neither switch.

Example sequence:

weekly resetAt = 2026-09-01T12:00:00Z
12:00:00Z  window becomes due
12:00-12:01 OpenCodex sends the existing minimal `hi` warmup through that account
after success OpenCodex refreshes WHAM and records the new resetAt

Alternatives or workarounds

Users can set calendar reminders and manually send one message from every account after each reset. A fixed cron schedule is unreliable because rolling windows differ per account and move when activation is late. Polling every account with synthetic traffic regardless of resetAt wastes quota and is not acceptable.

Additional context

Related quota-window parsing/display work: #1791, #1863, #2141, #2615, and #2616.

Official OpenAI documentation describes a shared rolling five-hour window for ChatGPT plan usage and notes that additional weekly limits may apply: https://learn.chatgpt.com/docs/pricing#what-are-the-usage-limits-for-my-plan

The implementation can reuse src/codex/warmup.ts, the per-account WHAM quota cache, and the existing one-minute state-store sweep tick. No new dependency or scheduler subsystem is needed.

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.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    account-poolOAuth, credentials, Codex pool, quota, failover, plans
    platformOS/service/tray/ACL (Windows-heavy, not Windows-only)
    on Aug 30, 2026

  2. lidge-jun commented on Aug 30, 2026

    @lidge-jun
    lidge-jun
    on Aug 30, 2026
    Owner

    리뷰 · 우선순위 38 / 80

    설명

    이 이슈는 ChatGPT Codex 계정의 롤링 할당량 창(5시간·주간)이 리셋된 뒤에도 계정이 계속 놀면 다음 창 시작이 미뤄지는 문제를 막자고 합니다. 지금 dev HEAD(4f6a19643)에는 계정별 WHAM 할당량·resetAt 파싱(src/codex/quota.ts, src/providers/quota.ts, src/providers/codex-capacity.ts)과 OAuth 직후 쓰는 최소 Codex 워밍업(src/codex/warmup.ts, auth-api.ts의 verifyCodexAccountWarmup/warmCodexAccount)이 이미 있습니다. 다만 이 두 조각을 ‘리셋 시각이 되면 그 계정으로 한 번만 워밍업을 보내 창을 붙잡는다’는 스케줄로 이어 주는 고리는 없습니다. 그래서 수동으로 메시지를 보내기 전까지 구독 기간이 흘러갈 수 있다는 청구는 HEAD 기준으로도 맞습니다.

    요청 형태는 꽤 구체적입니다. 계정 카드에 5시간/주간 스위치를 따로 두고, WHAM 페이로드에 그 창이 실제로 있을 때만 스위치를 보여주고, 기본은 둘 다 끔, resetAt 직후에 기존 워밍업 경로로 최소 요청 한 번, 두 창이 같이 도래하면 한 메시지로 둘 다 활성화, 계정·창별 마지막 활성화한 resetAt을 남겨 재시작 중복을 막고, 성공 후 WHAM을 다시 읽어 다음 일정을 잡으며, 재인증·비가용 계정은 건너뛰고 일시 실패만 재시도한다는 점입니다. 고정 cron이나 전 계정 무조건 합성 트래픽은 거절하고 있습니다. 관련으로 이미 열린 #2783(창 리셋 감지·알림), #2874(풀 reset-window 정렬), 그리고 combo 쪽 {bt}reset-window{bt} 전략({bt}src/combos/reset-window.ts{bt})이 있어 ‘리셋 시각을 안다’는 축은 제품 안에 흩어져 있고, 이 이슈는 그걸 ‘계정별 opt-in 자동 활성화’로 묶자는 제안입니다.

    우선순위는 중간보다 조금 낮게 잡습니다. 보안 구멍이 아니라 구독 효율 기능이고, 기본 off·창별 opt-in·중복 방지 설계가 본문에 이미 있어 방향은 안전 쪽에 가깝습니다. 다만 프록시가 백그라운드에서 계정 대신 Codex에 요청을 보내는 일이라 의도치 않은 사용량·요금·감사 로그 기대치를 설계 단계에서 고정해야 합니다. types.ts/config.ts 분할 캠페인과는 직접 충돌하지 않고, 설정 스키마에 계정별 플래그를 넣는다면 그 캠페인 이후에 맞추는 편이 덜 아픕니다. 프리뷰 배포는 계획에 없습니다.

    구현 후보 경로는 본문이 적은 대로 src/codex/warmup.ts 재사용, WHAM 캐시, 기존 1분 state-store sweep 틱에 ‘도래한 opt-in 창이 있으면 워밍업’을 붙이는 쪽이 현실적입니다. 새 스케줄러 서브시스템을 만들지 말라는 제약도 HEAD의 틱 구조와 잘 맞습니다. GUI는 Codex 계정 카드에 창이 노출될 때만 스위치를 그리는 조건부 UI가 필요합니다.

    주의할 점은 ‘리셋 = 바로 새 창 시작’이 OpenAI 쪽 실제 계약인지를 제품이 단정하면 안 된다는 것입니다. 공식 문서는 공유 롤링 5시간 창과 추가 주간 한도를 설명하지만, 유휴 계정에 최소 요청을 보내는 행위가 창을 다시 붙잡는다는 보장은 OpenCodex가 관측으로 증명해야 합니다. 또한 combo {bt}reset-window{bt} 선택 전략(#2050 계열)과 이름만 비슷한 #2874 풀 정렬, #2783 알림 PR과 범위가 겹쳐 보이기 쉬우니 이슈 본문에 ‘자동 활성화 ≠ 라우팅 전략 ≠ 알림’을 한 줄로 구분해 두는 것이 좋습니다.

    라인 - 문제

    이슈 본문 / src/codex/warmup.ts - 워밍업이 OAuth 직후 검증용으로 설계돼 있어, 틱에서 주기적으로 부르면 타임아웃·SSE 크기 한도·에러 분류가 ‘백그라운드 활성화’ 의미와 맞는지 확인이 필요합니다. 실패를 사용자에게 어떻게 보여줄지도 비어 있습니다.

    이슈 본문 / 계정 설정 스키마 - 5시간·주간 스위치와 ‘마지막 활성화 resetAt’ 영속 필드 위치가 아직 없습니다. 디스크 키를 계정 id·창 종류로 고정하지 않으면 재시작 중복 방지가 깨집니다.

    이슈 본문 / WHAM 창 노출 조건 - 플랜 이름 화이트리스트를 쓰지 말라는 요구는 타당하지만, 어떤 필드가 ‘5시간 창’·‘주간 창’인지는 HEAD 파서와 한 줄로 연결해 적어야 구현자가 추측하지 않습니다.

    #2783 · #2874 - 리셋 시각을 다루는 열린 작업과 제품 경계가 겹칩니다. 알림·풀 정렬·자동 활성화를 한 PR에 섞지 말고, 이 이슈는 활성화만 맡긴다고 명시하는 편이 안전합니다.

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

    너의 추천

    이슈는 열어 두고 design 라벨(또는 needs-design)을 유지한 채, 짧은 설계 메모에 (1) 재사용할 warmup API, (2) 영속 키, (3) sweep 틱 진입점, (4) #2783/#2874와의 비겹침을 고정한 뒤 구현 PR을 받는 쪽을 추천합니다. 지금 당장 코드 PR을 받지 말고, 관측으로 ‘유휴 계정에 최소 요청이 창을 붙잡는지’를 한 계정에서 재현·기록한 다음 착수하세요. types/config 분할에 걸리면 설정 스키마 변경 PR은 그 캠페인 이후에 맞추고, 닫지 말고 대기하면 됩니다.

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

  3. lidge-jun commented on Sep 3, 2026

    @lidge-jun
    lidge-jun
    on Sep 3, 2026
    Owner

    Closing in favor of #3376, which carries the remaining scope forward.

    Thank you @terrytan95 — the report on activating Codex quota windows automatically per account was correct.

    Current state. src/codex/warmup.ts remains an invocation primitive with no reset-driven scheduling. Your PR #2973 implements this and stays open — it is not superseded.

    Quota history, reset ordering, and automatic window activation are three views of one missing mechanism, so keeping them as three issues split the discussion without splitting the work. #3376 states the whole thing, names this issue, and credits you for the original analysis.

    Please follow #3376; if the consolidation lost something you asked for, say so there and it will be added.

  4. lidge-jun
    closed this as not plannedon Sep 3, 2026
  5. lidge-jun
    added a commit that references this issue on Sep 5, 2026

    feat(codex): auto-activate quota reset windows (#3588)

    593978d
  6. agentHits
    added a commit that references this issue on Sep 17, 2026

    feat(codex): auto-activate quota reset windows (lidge-jun#3588)

    9b9efd1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requestplatformOS/service/tray/ACL (Windows-heavy, not Windows-only)

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions