[Bug] v7.2.155: Claude Sonnet/Opus stay in ~18-day cooldown after quota recovery; restart restores access

[nidhi-singh02]

Is it a request payload issue?

• Yes, this is a request payload issue.
• No, it's another issue: credential/model cooldown state after quota recovery.

Describe the bug
I use CLIProxyAPI 7.2.155 as a Homebrew service on macOS, with two linked Claude accounts. Claude Code points to the local proxy. The setup worked until I hit a usage limit. After Claude's usage page showed quota available again, the proxy continued returning HTTP 429 for both claude-opus-5 and claude-sonnet-5:

All credentials for model claude-sonnet-5 are cooling down via provider claude

The retained Sonnet responses contain Retry-After values of 1,587,827, 1,587,608, and 1,583,274 seconds. Adding each value to its response timestamp gives approximately 2026-10-01 05:30:19 IST, over 18 days after the first error. Opus error logs count down toward the same deadline.

Running brew services restart cliproxyapi restored access. No credential relinking was needed for this recovery.

Observed sequence:

1. Use the local proxy with two linked Claude accounts until a usage limit is reached.
2. Check Claude usage and observe that quota is available again.
3. Continue the existing Claude Code conversation; Opus requests fail with the cooldown error.
4. Switch to Sonnet and retry; Sonnet also fails with the cooldown error.
5. Restart the Homebrew service; requests work again.

This describes the observed incident, not a deterministic minimal reproduction. Available quota and successful recovery after restart are my observations; the retained logs establish the pre-restart errors and unusually long retry deadline.

CLI Type
Claude accounts (two linked accounts).

Model Name
claude-sonnet-5 and claude-opus-5 (exact identifiers recorded in the errors).

LLM Client
Claude Code, configured to use the local CLIProxyAPI server.

Request Information
Endpoint: /v1/messages. Below are all three retained Sonnet response extracts. These are response-only excerpts; the original request bodies and request headers are omitted because they contain private conversation content and are not needed to show this local cooldown rejection. They are not synthetic cURL reproductions.

Redacted Sonnet error logs (three requests, September 12, 2026; timezone +05:30)

REDACTED SONNET COOLDOWN RESPONSE EXTRACTS
CLIProxyAPI 7.2.155; macOS/Homebrew

These are response-only extracts from retained /v1/messages error logs.
Request bodies, request headers, credentials and account identifiers are omitted.
The API RESPONSE sections contain proxy-generated cooldown errors, not the original upstream Claude error.

Source file: error-v1-messages-2026-09-12T202632-fa1be1d1.log

=== API RESPONSE ===
Timestamp: 2026-09-12T20:26:32.257336+05:30
{"error":{"type":"rate_limit_error","message":"All credentials for model claude-sonnet-5 are cooling down via provider claude"}}

=== RESPONSE ===
Status: 429
Retry-After: 1587827
{"error":{"type":"rate_limit_error","message":"All credentials for model claude-sonnet-5 are cooling down via provider claude"}}

---

Source file: error-v1-messages-2026-09-12T203011-7ba33260.log

=== API RESPONSE ===
Timestamp: 2026-09-12T20:30:11.727328+05:30
{"error":{"type":"rate_limit_error","message":"All credentials for model claude-sonnet-5 are cooling down via provider claude"}}

=== RESPONSE ===
Status: 429
Retry-After: 1587608
{"error":{"type":"rate_limit_error","message":"All credentials for model claude-sonnet-5 are cooling down via provider claude"}}

---

Source file: error-v1-messages-2026-09-12T214225-c14d971d.log

=== API RESPONSE ===
Timestamp: 2026-09-12T21:42:25.971444+05:30
{"error":{"type":"rate_limit_error","message":"All credentials for model claude-sonnet-5 are cooling down via provider claude"}}

=== RESPONSE ===
Status: 429
Retry-After: 1583274
{"error":{"type":"rate_limit_error","message":"All credentials for model claude-sonnet-5 are cooling down via provider claude"}}

Expected behavior
Once upstream quota is available, the proxy should recover within a bounded interval or provide a way to revalidate/clear stale cooldown state without restarting the service. A saved reset deadline should not prevent recovery for more than 18 days when the account is already usable.

Screenshots
Not included; the exact retained response excerpts are provided above.

OS Type

• OS: macOS
• Version: 26.6.2
• Architecture: arm64
• Installation: Homebrew service (cliproxyapi)
• CLIProxyAPI version: 7.2.155

Additional context
Relevant values from the Homebrew configuration (/opt/homebrew/etc/cliproxyapi.conf):

debug: false
logging-to-file: false
save-cooldown-status: false
error-logs-max-files: 10

Only ten error files were retained when inspected after the restart. The original Claude response that established the cooldown, including any upstream rate-limit/reset headers, was not found in the retained logs. The full pre-restart in-memory cooldown state is unavailable. Consequently, I cannot determine which upstream header or calculation produced the October 1 deadline, or whether every linked account participated in the failing requests.

The shared cooldown logic in v7.2.155 appears consistent with the symptom, but this is a hypothesis rather than a confirmed root cause. The inferred deadline above comes from the proxy's downstream Retry-After, not a captured Anthropic reset header.

Related reports checked before filing:

• All credentials for model claude-sonnet-4-6 are cooling down #1655: two Claude Max accounts with available quota received a similar Sonnet cooldown error.
• Quota cooldown is never re-checked: credential stays blocked after upstream quota is restored #5611: quota recovery remained blocked until restart (reported with Codex; shared cooldown path).
• fix(auth): bound quota cooldowns so restored quota is not latched out #5609: proposed quota cooldown ceiling, currently unmerged.

This report adds Claude Sonnet/Opus evidence on v7.2.155/macOS, including an approximately 18-day countdown and successful recovery after a Homebrew service restart. Please advise whether this belongs under an existing issue, and which diagnostics would be most useful if it recurs.

[riccardovandra]

Same bug here, with one extra detail: the credential stayed benched after its own next_retry_after had already passed, so this is not only a too-long Retry-After. The expired cooldown is never cleared either.

Setup

• VibeProxy 1.8.292 bundling CLIProxyAPI 7.2.154 at the time of the incident (auto-updated to 7.2.155 afterwards), macOS
• Two Claude OAuth accounts, routing.strategy: fill-first, session-affinity: true
• Client: Claude Code (VS Code extension), model claude-opus-5

What happened (2026-09-13, +02:00)

1. Account A hit its real 5h limit (Anthropic-Ratelimit-Unified-5h-Status: rejected, reset 14:30). Being benched was correct.
2. Account B was also reported unavailable: true by GET /v0/management/auth-files, with next_retry_after = 2026-09-12 11:00, about 25 hours in the past.
3. Account B's upstream quota was healthy: 5h at ~0-13%, 7d at 1%, Anthropic-Ratelimit-Unified-Status: allowed.
4. From 12:38 to 12:41 every request returned a local 429:
   All credentials for model claude-opus-5 are cooling down (last error: rate_limit_error: ...)
   There are 10 error logs, and all of them show the proxy rejecting the request locally.
5. At 12:41:56 the proxy restarted during the auto-update. Account B immediately became status: active, unavailable: false, and served 28 requests with 0 failures in the next bucket.

Expected
A credential whose next_retry_after has passed should be eligible again. At minimum it should be probed, especially when its own fresh quota.signals report allowed, which relates to #5639.

Workaround
Restart the proxy.

For anyone who needs to catch this before it bites, it can be detected from the management API: unavailable == true && next_retry_after < now.

[ggbdpq]

I investigated this against the latest dev. Two findings:

1. The multi-day write reproduces as reported. A credential-scoped 429 with Retry-After: 1587827 (seconds) is honored verbatim when writing the credential- and model-level cooldowns, so both models stay rejected locally for that window — there is no ceiling. A regression probe confirms selection returns model_cooldown for both claude-sonnet-5 and claude-opus-5 right after such a result.

2. The expired cooldown itself does recover on current dev. Once the stored deadlines pass, selection serves both models again without a restart or any state cleanup — locked with a regression test in branch fix/claude-expired-cooldown-stuck (commit 8fa4175, tests-only). @riccardovandra's observation that the credential stayed benched after next_retry_after had passed therefore does not reproduce here. If you still see it on 7.3.x, could you share the exact version plus the credential's next_retry_after value and the rejection response? That would point at either a packaging-layer difference or a display-only residue in GET /v0/management/auth-files (the aggregated Quota.Exceeded flag is not cleared until the next MarkResult, but it does not affect routing).

On the too-long window itself — this is the same core as #5639 (stale cooldown not re-evaluated against fresh quota signals). #5846 tried a global conductor ceiling and was withdrawn because it would clamp legitimate long windows. The remaining directions I can see: (a) provider-scoped Retry-After handling inside the Claude executor, or (b) re-evaluating a live cooldown when fresh quota signals arrive — Quota.ObserveResponseHeadersForProvider already records those headers, so a bounded re-check on observed recovery seems feasible. Both are policy changes, so I'd like the maintainers' preference before opening a fix PR; the tests-only branch is ready as a base either way.