Reset-credit success can leave the same account blocked by a local quota cooldown #3973

Client or integration

OpenCodex dashboard

Area

Authentication and account pool

Summary

A successful manual reset-credit consume refreshes the account's WHAM usage, but does not reconcile that account's existing local quota cooldown. Subsequent native requests can therefore receive a local 429 before an upstream request is attempted, even after the operator has reset the account and refreshed its displayed usage.

The consume-success and routing paths were checked in v2.46.0 and v2.47.0; the relevant behavior remains on dev. This is a request to connect the manual reset outcome to the existing recovery contract, not to clear all account health after any successful HTTP response.

Reproduction

Observed intermittently on a long-running local proxy; the exact initial upstream error body was not retained, so this is not claimed as a deterministic live-account reproduction.

1. Use native Codex models through the OpenCodex account pool, with an additional account selected and pinned.
2. After that account has entered a reset-derived shared quota cooldown, consume a reset credit for that same account through the dashboard and refresh its displayed usage.
3. Resume a native request. Observed local responses still report the selected account cooling down, with no upstream attempt recorded.
4. A later, newly recorded cooldown is a confounder in the observed sequence. Verify the proposed fix with mocked reset and WHAM responses; do not consume another live credit for testing.

Evidence and limits

• src/codex/auth-api.ts: the manual /api/codex-auth/reset-credits/consume success branch refreshes WHAM and returns remaining; it does not settle an existing quota-recovery claim.
• src/codex/routing.ts: ordinary successful requests and quota-cache updates deliberately do not erase hard shared-scope cooldowns. Recovery is separately fenced by scope, lease and generation.
• In local observations, repeated native requests were rejected in tens of milliseconds with no upstream attempts and the same reset-derived cooldown deadline. The public error exposed only the generic 429/retry-limit summary.
• A later reset-derived cooldown was also observed after the reported manual reset time. The first failed physical send is not retained separately when an alternate-account retry succeeds, so those logs do not prove the original upstream error body or whether the reset itself failed. This issue does not claim that every post-reset 429 has this one cause.

Expected behavior

After a confirmed reset and a sufficiently fresh, complete usage observation, reconcile only the matching account's pre-existing shared reset-derived cooldown. Preserve explicit Retry-After, independent Spark/Reserve scopes, pause/pin settings, credential/identity changes and any newer quota failure.

The existing background recovery is related (#955), but a manual reset should not have to wait for its interval. The broader strict-quota/wait proposal #3738 is a separate scope.

Implementation constraints for a follow-up

• Bind the candidate recovery to the authenticated account and a unique cooldown identity; generation numbers alone can be reused after deletion/recreation.
• fetchPoolAccountQuota(..., true) may join an in-flight request started before the reset. Do not treat force=true as proof of a post-reset observation.
• A durable replay or already_redeemed response is not proof that this invocation performed a new reset. Preserve idempotency and do not spend another credit to establish recovery.
• Main and additional Pool identities have different proof contracts. Do not reuse a Pool credential proof for main, or clear another local alias merely because metadata appears similar.

Regression coverage can use mocked reset and quota responses; no real credit consumption is needed. It should cover successful recovery, pre-reset/stale/incomplete observations, a newer 429, identity replacement, deleted/recreated cooldown state, independent scopes and replayed operations.

auth-api.ts is a sponsored surface. Maintainer sponsorship and security review are requested for the follow-up implementation before review-ready status. No local account identifiers, raw responses or credentials are included here.

Version

Observed on 2.46.0. Relevant manual-reset and cooldown behavior also checked in 2.47.0 and dev dc5ee2f.

Operating system

Windows 11 Pro, version 10.0.26200 (build 26200).

Provider and model

OpenAI Codex account pool; gpt-6-astra and gpt-5.6-terra share the ordinary native quota scope.

Logs or error output

Redacted local record shape: status 429; errorCode rate_limit_exceeded; closeReason non_stream; attempts []; upstreamError describes the selected account's shared native quota cooling down with source reset-derived. The client shows exceeded retry limit, last status: 429 Too Many Requests.

Screenshots and supporting files

No raw account captures are attached. The source paths, version comparison and logging limitations are described above.

Redacted configuration

Codex account pool, fill-first selection, one additional account selected and pinned. Account identifiers and credentials are intentionally omitted.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.