Skip to content

[Feature]: retain quota history and make reset windows a scheduling input (capacity estimation, reset ordering, automatic activation) #3376

Open
Open
[Feature]: retain quota history and make reset windows a scheduling input (capacity estimation, reset ordering, automatic activation)#3376
Labels
account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requestplatformOS/service/tray/ACL (Windows-heavy, not Windows-only)priority: P3Low: new provider/client integration, large or experimental feature (>2000 LOC or >50 files), RFC/ro

Description

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

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?

  1. Retain a bounded history of quota observations per account rather than a single overwritten snapshot.
  2. 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.
  3. Add a reset-window-aware pool ordering strategy that prefers accounts by time-to-reset.
  4. Activate an account's quota window on a schedule tied to its reset, not to incidental traffic.

Example usage or interface

{
  "providers": {
    "codex": {
      "accountPool": {
        "strategy": "reset-window",     // prefer the account whose window resets soonest
        "quotaHistory": { "retain": 200 },
        "autoActivateWindows": true
      }
    }
  }
}
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

  • 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. lidge-jun
    added
    enhancementNew feature or request
    account-poolOAuth, credentials, Codex pool, quota, failover, plans
    on Sep 3, 2026

  2. coderabbitai commented on Sep 3, 2026

    @coderabbitai
    coderabbitaibot
    on Sep 3, 2026 – with coderabbitai
    Contributor
    ⚠️ Possible Duplicate Issue(s)
    📝 Issue Planner

    Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.

    • Create Plan
    🧪 Issue enrichment is currently in open beta.

    To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

    issue_enrichment:
  auto_enrich:
    enabled: false

    💬 Have feedback or questions? Drop into our discord!

  3. github-actions
    added
    platformOS/service/tray/ACL (Windows-heavy, not Windows-only)
    on Sep 3, 2026

  4. lidge-jun commented on Sep 3, 2026

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

    리뷰 · 우선순위 70 / 80

    이 이슈는 쿼터 창을 “지금 스냅샷 하나”가 아니라, 고르는 입력으로 쓰자는 요청입니다. 용량을 추정하고, 창이 언제 리셋되는지 보고 계정을 고르고, 리셋 시각에 창을 자동으로 켜려면, 과거 관측이 필요합니다. 지금 dev HEAD(664d80c76)의 src/codex/quota.ts는 계정마다 최신 스냅샷 하나를 디스크에 두고, 새 관측이 오면 덮어씁니다. 주간·월간·짧은 창·커스텀 창 필드는 있지만 시계열은 없습니다. 그래서 용량 추정(#2344)과 리셋 시각 정렬(#2874)과 자동 활성화(#2969)가 서로 다른 말처럼 보여도, 막힌 곳은 하나입니다. 과거가 없습니다.

    풀 전략도 아직 그 입력을 받을 자리가 없습니다. src/types/config.ts의 OcxAccountPoolRotationStrategy는 quota | round-robin | fill-first뿐입니다. 콤보 쪽 OcxComboStrategy에는 이미 reset-window가 있습니다(#3373이 GUI 선택기를 여는 바로 그 값). 계정 풀에는 같은 이름이 없습니다. src/codex/warmup.ts는 호출 프리미티브이지, 리셋 시각에 맞춰 창을 켜는 스케줄러가 아닙니다. 관측 반은 본문 말대로 제공자 수준에 있습니다(src/providers/muse-subscription-usage.ts 등). 없는 것은 그 관측을 쌓고, 풀 선택에 넣는 일입니다.

    흡수된 #2344, #2874, #2969는 닫혀 있습니다. 열린 PR #2973(feat(codex): auto-activate quota reset windows, @terrytan95)은 이 이슈가 “항목 4만 다룬다, 대체되지 않는다”고 적어 두었습니다. 자동 활성화만 먼저 넣으면 히스토리 없이 리셋 시각을 추측하게 되므로, #2973은 히스토리 저장이 생긴 뒤에 리베이스하는 편이 안전합니다. 이 이슈 자체는 types.ts/config.ts 분할에 치여 닫을 대상이 아닙니다. 다만 reset-window 전략을 설정에 넣는 패치는 src/types/config.ts를 만지므로, 분할 캠페인과 겹치면 그 PR은 닫고 다시 쓰는 쪽이 맞습니다.

    저장 상한(quotaHistory.retain: 200)은 필요합니다. 쿼터 스냅샷을 무한히 쌓으면 홈 디렉터리가 커집니다. CLI ocx quota history는 관측이 쌓인 다음에야 의미가 있습니다. 콤보의 reset-window와 계정 풀의 reset-window를 같은 이름으로 쓸지는 헷갈릴 수 있습니다. 콤보는 타깃 모델 사이, 풀은 계정 사이입니다. 이름이 같아도 객체가 다릅니다. 문서에 한 줄로 구분해 두는 편이 좋습니다.

    src/codex/quota.ts - 계정당 최신 스냅샷만 유지합니다. 히스토리가 없어 용량 추정·리셋 정렬의 입력이 없습니다.

    src/types/config.ts OcxAccountPoolRotationStrategy - quota / round-robin / fill-first만 있고 reset-window가 없습니다. 콤보 전략과 다릅니다.

    src/codex/warmup.ts - 리셋 시각 스케줄이 아니라 호출 프리미티브입니다.

    열린 PR #2973 - 자동 활성화만 다루며 이 이슈가 대체하지 않는다고 본문에 적혀 있습니다. 히스토리 저장보다 앞설 수 있습니다.

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

    • 히스토리 저장을 먼저 넣고 #2973을 그 위에 올릴지, #2973을 독립으로 머지할지.
    • 계정 풀 전략 이름 reset-window를 콤보와 공유할지, 더 구체적인 이름을 쓸지.
    • retain 기본값과 디스크 위치(OPENCODEX_HOME 아래인지).

    너의 추천
    이 이슈를 열어 두고, 첫 작업은 계정당 쿼터 히스토리를 상한과 함께 저장하는 것입니다. 그 다음 풀 전략 reset-window와 자동 활성화를 얹으세요. #2973은 히스토리 커밋 위에 다시 맞추는 것을 권합니다. 흡수된 원본 이슈는 다시 열지 마세요.

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

  5. devin-ai-integration
    added
    priority: P3Low: new provider/client integration, large or experimental feature (>2000 LOC or >50 files), RFC/ro
    on Sep 24, 2026

  6. devin-ai-integration commented on Sep 24, 2026

    @devin-ai-integration
    devin-ai-integrationbot
    on Sep 24, 2026 – with Devin.ai Integration
    Contributor

    Triage: priority: P3 — quota history and reset scheduling.

    Criteria (P3): Low: new provider/client integration, large or experimental feature (>2000 LOC or >50 files), RFC/roadmap, or long-stale branch.

    Matched pull requests:

  7. luvs01 commented on Sep 27, 2026

    @luvs01
    luvs01
    on Sep 27, 2026
    Collaborator

    Follow-up measurement for the automatic activation part of this issue, after #6056 was closed in favor of #6020 / #6062.

    On Windows, the running proxy reports OpenCodex 2.68.0. One configured, validated, unpaused Pro Lite pool account has weekly automatic activation enabled. Two direct, identity-checked WHAM reads showed:

    Observed (UTC) used_percent limit_window_seconds reset_after_seconds reset_at
    2026-09-27 12:49:29 0 604800 604800 1791118169
    2026-09-27 12:50:32 0 604800 604800 1791118232

    The reset moved by 63 seconds while the remaining duration stayed at the full seven days. This distinguishes an unanchored idle window from a started window whose small usage merely rounds to 0%. Other accounts in the same process have fixed reset timestamps and decreasing remaining durations.

    The idle account's persisted nextWeeklyResetAt is 1791018013000 (2026-10-03 09:00:13 UTC), still almost six days away. The retained-deadline implementation therefore addresses eventual activation, but does not start this already-opted-in idle weekly window now. This observation does not prove that the retained deadline will fail when it becomes due; it identifies the gap between scheduled activation and initial activation on enable/startup.

    For a narrow follow-up, an explicit per-account Start unused window now action with a small-request explanation would make this state actionable without reviving #6056's extra polling or account-wide retry fence. If initial activation is made automatic instead, it should require fresh same-credential moving-window evidence and replace the affected saved deadline only after verified completion, without delaying due work for other windows or repeating a request after an ambiguous result.

    No warmup, token refresh, reset-credit use, pin/priority change, or quota-counter edit was performed for this measurement. No account identifiers or credentials are included. Keeping this evidence in the existing tracking issue rather than opening a duplicate or reopening the superseded PR.

  8. lidge-jun commented on Sep 27, 2026

    @lidge-jun
    lidge-jun
    on Sep 27, 2026
    OwnerAuthor

    Release train 4 (account-pool lane) re-checked this against dev. Several parts already exist:

    • Bounded quota history (src/codex/quota-history.ts).
    • A capacity estimate that reports low confidence and its sample count (src/codex/quota-capacity.ts).
    • Codex reset-first ordering (src/codex/routing/selection.ts).
    • Opt-in scheduled activation (src/codex/quota-auto-refresh.ts).

    Keeping it open for the part @luvs01 measured on 2.68.0: an idle weekly window on an opted-in account stays unstarted until its later due time. Whether Anthropic has any reset ordering also still needs checking. This train does not change either.

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)priority: P3Low: new provider/client integration, large or experimental feature (>2000 LOC or >50 files), RFC/ro

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions