Feature: weekly reset-aware account selection

[artile]

Summary

When multiple ChatGPT/Codex OAuth accounts are configured, the current routing strategies (round-robin and fill-first) do not take weekly quota reset timing into account.

This can waste paid quota when one account's weekly allowance is about to reset sooner than another's. In practice, it is often better to consume the quota that will expire/reset first, then move on to the next account.

Current behavior

From reading the current implementation:

• account selection is driven by round-robin or fill-first
• availability/cooldown state is respected
• 429 / quota-exceeded responses trigger cooldown/backoff/failover
• ChatGPT subscription metadata is available in JWT claims (chatgpt_account_id, chatgpt_plan_type, chatgpt_subscription_active_start, chatgpt_subscription_active_until)
• but selection does not appear to consider a per-account weekly quota reset timestamp

So today the proxy can react after quota is exhausted, but it cannot proactively prefer the account whose weekly quota will refresh first.

Requested behavior

Add an optional routing mode that prefers the account with the earliest upcoming weekly quota reset.

Example behavior:

1. Among currently available auths for the same provider/model, compute or store each account's next weekly quota reset time.
2. Prefer the auth whose reset time is nearest in the future.
3. If reset times are equal or unavailable, fall back to the existing strategy (fill-first or round-robin).
4. Continue to honor priority, disabled state, and cooldown/unavailable state.

Why this helps

This would let operators maximize use of multiple paid subscriptions without manually rotating accounts.

Instead of:

• spreading traffic evenly, or
• burning one account fully without regard to reset timing,

the proxy could consume the quota that will "expire" first and preserve quota on accounts whose weekly window resets later.

Possible implementation ideas

A few possible approaches:

• Add a new routing strategy, e.g. earliest-reset-first
• Or add a secondary ordering policy layered on top of existing routing:
  • routing.strategy: fill-first|round-robin
  • routing.account-order: earliest-weekly-reset|priority|static
• Store an explicit per-auth metadata field such as:
  • weekly_quota_reset_at
  • or quota_refresh_at
• If the reset timestamp cannot be derived reliably from provider metadata, allow operators to set it manually via auth metadata / management API

Nice-to-have

• Expose the reset timestamp in management UI/API
• Surface why a given auth was selected
• Add tests covering mixed cases:
  • known reset dates
  • missing reset dates
  • reset-aware ordering + cooldown
  • reset-aware ordering + priority buckets

Notes

A related distinction: chatgpt_subscription_active_until is useful for subscription validity, but it is not the same thing as a weekly usage reset timestamp. The feature request here is specifically about weekly quota refresh / rolling-window prioritization.

[trungdlp]

Hi @artile, any updates on this? I'm interested in this!

[zzc941210]

+1! This is a fantastic feature idea and exactly what I’ve been looking for.

Managing multiple paid accounts is a bit of a headache right now because the current strategies waste quota on accounts that are just about to reset. Prioritizing accounts based on their upcoming weekly reset time would be a massive efficiency booster for anyone running a multi-account setup.

Really hope to see this implemented!