[Bug]: CLIProxyAPI account-pool cooldowns never reach usage-limit auto-resume

[f4llenz]

Problem

Claude threads routed through a multi-account CLIProxyAPI pool stop on a usage limit with no reset time, so T3 cannot schedule auto-resume. The client displays:

The provider did not report a reset time. Retry manually when your limit is available.

The accompanying error is:

API Error: Request rejected (429) · All credentials for model anthropic-opus-5-5 are cooling down (last error: rate_limit_error: This request would exceed your account's rate limit. Please try again later.)

A user reported this on mobile and reported that direct-provider auto-resume works. Follow-up read-only inspection confirmed that their MacBook already has an enabled CLIProxyAPI Usage Limits source with a working management key, and T3's autoResumeLimitedThreads preference is enabled. Their exact installed T3 version was not collected. The investigation below establishes a T3-side solution for an explicitly associated, management-enabled hub; it does not establish that T3 can recover a deadline from an endpoint-only setup.

Reproduction and verification

Investigated current T3 main 3b99fb2d2114f57c96bf92e4ed1c7ce5eaa67b1e and CLIProxyAPI 911f49cbd49f4fe2516979754a7488a3fd14fe64. Local protocol reproduction used Claude Code 2.1.296, a mock HTTP endpoint, dummy credentials, isolated configuration, no tools, and no real model requests.

1. Return the Claude-compatible 429 body above with Retry-After: 120.
2. In proxy authentication mode (ANTHROPIC_AUTH_TOKEN), Claude emits assistant.error = "rate_limit" and a result with terminal_reason = "api_error", api_error_status = 429, but no timed rate_limit_event. Adding native unified-reset headers still does not produce a timed event in that auth mode.
3. With mock subscription OAuth authentication and unified-reset headers, the same CLI emits rate_limit_event.rate_limit_info.resetsAt.
4. Replay those captured frames through the extracted current T3 failure-mapping functions: proxy case is usage_limit with resetAt: null; subscription case has a reset timestamp.
5. Replay the existing recovery-command function with a synthetic, explicitly matched two-account pool fixture: without a deadline it returns no command; supplying the earliest eligible account's cooldown deadline arms the existing auto-resume metadata.

These are isolated protocol/function replays, not a live end-to-end test of the user's hub or a completed implementation.

Live management verification on the affected MacBook

On 2026-10-16, a read-only GET /v0/management/auth-files using T3's existing saved management credential returned HTTP 200. Hub response headers identify 7.3.17-claudex, commit 18c7b789c.

The response contained two enabled Claude accounts, both marked unavailable with quota cooldowns. Anonymized relevant fields at inspection:

[
  {
    "account": "A",
    "cooldowns": [
      { "scope": "credential", "reason": "credential_quota", "retry_at": "2026-10-16T20:40:08.000904Z" },
      { "scope": "model", "model_key": "claude-opus-5-5", "reason": "quota", "retry_at": "2026-10-16T20:40:08.000904Z", "http_status": 429 }
    ]
  },
  {
    "account": "B",
    "cooldowns": [
      { "scope": "credential", "reason": "credential_quota", "retry_at": "2026-10-18T05:00:30.00061Z" },
      { "scope": "model", "model_key": "claude-opus-5-5", "reason": "quota", "retry_at": "2026-10-18T05:00:30.00061Z", "http_status": 429 }
    ]
  }
]

The first account also retained a quota observation from the reported incident time (16:25 local) identifying a rejected five-hour window and its upstream reset timestamp. The second account's retained observation identified a rejected weekly window. This confirms that the affected hub exposes the proposed fallback data, rather than only demonstrating the API on upstream source or synthetic fixtures. Provider-to-hub/model-alias matching and an actual scheduled continuation remain unverified. No account identities, keys, or raw auth-file contents are included here; no live settings or provider state were changed.

Why this can be addressed in T3

The ordinary Claude provider stream lacks the required data. However, CLIProxyAPI's existing management auth-files response exposes cooldowns[] with scope, model_key, retry_at, and remaining_seconds. T3 already calls this endpoint for its optional CLIProxyAPI Usage Limits source, but its AuthFile schema retains identity/auth fields and discards cooldowns. That source is not associated with the failed thread's route for recovery.

Relevant sources:

• T3 management response schema
• T3 Claude reset-event handling
• T3 recovery requires a deadline
• CLIProxyAPI cooldown projection and its limitations
• CLIProxyAPI attaches cooldowns to auth-files

Expected behavior / proposed scope

Allow a provider instance to be explicitly associated with its configured CLIProxyAPI management source, then use authoritative, fresh cooldown data as a recovery fallback when the normal provider failure has no deadline. Feed the resulting retry deadline into the existing usage-limit recovery flow so web, desktop, and mobile benefit from the same server behavior.

Respect route/model aliases and credential eligibility. For a known pool, account for all restrictions on each eligible account before selecting the earliest account that can serve the requested model. Do not blindly use the earliest subscription-window reset or treat an empty cooldown list as proof of availability. Unknown routes, disabled/invalid accounts, unavailable remote/Home cooldown state, missing management access, and uncertain model mappings must retain the current manual-retry fallback. Treat this as a retry opportunity, not a guarantee that upstream quota has reset. No upstream protocol change is required for the supported management-backed case.

Related but distinct: #14169 concerns native Codex usage telemetry not reaching recovery; #17777 handled a gateway that included its reset time in the error text. CLIProxyAPI #6646 discusses long cooldown HTTP error semantics. This issue requests T3's management-backed recovery integration.

Investigated and filed using GPT-6.1-Sol through the Codex harness in T3 Code.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Open PR #17866 already targets this: pooling-proxy / CLIProxyAPI hub 429s that arrive without a rate_limit_event leave resetAt null, so usage-limit auto-resume never arms and the client shows “The provider did not report a reset time.”

That PR wires the hub’s Usage Limits windows back into Claude recovery as a fallback when the instance has an ANTHROPIC_BASE_URL. Tracking this issue against that PR (Fixes #20375 added to the PR body).

[CRGDan]

Note

Claude Code posting on behalf of @CRGDan. Edited: an earlier version said our gateway was not CLIProxyAPI. It is a routing layer on top of a CLIProxyAPI pool, so #17866 covers us directly.

We hit this same failure. Claude threads routed through our CLIProxyAPI pool stop on a bare 429 with no reset time, and native auto-resume never arms. Our T3 setup already matches #17866's preconditions: the Claude instance's ANTHROPIC_BASE_URL and the cliproxy usage source share one origin, and the hub serves v0/management/auth-files and api-call.

+1 for landing #17866. We run the nightly build and can test it against a real pool once it merges.

One observation from our pool: poolResetAt returns null when any listed Claude account's usage is unreadable. A pool that keeps a credential in an error state, without disabling it, would therefore never get a reset time, even when every working account is exhausted. Skipping accounts whose usage the hub cannot read may be worth considering, but that is your call.