You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(server): recover Claude cooldown reset times from proxy errors - #36642
Nothing needed changing. PR #36642 at 1f88524: all 35 checks passed (8 of them required). Macroscope approved it with no line comments. CodeRabbit's review says 'No actionable comments were generated' and rates the merge risk Minimal. No reviewer finding is open. The fix itself is the same as the last round: the adapter reads the CLIProxyAPI cooldown only from the outer 'All credentials … are cooling down (reset after …)' message and ignores nested 'last error' reset hints. It combines that deadline with native Claude rate-limit resets: the latest known reset wins, and an unknown native reset stays unknown.
Supersedes #26735. The change is @greyxp1's; their commits are kept.
Started a local stand-in proxy that answers each request with HTTP 429 and error message All credentials for model claude-opus-5-5 are cooling down (last error: rate_limit_error (reset after 1h)). Running the claude CLI directly against it produced API Error: Request rejected (429) · All credentials for model claude-opus-5-5 are cooling down (last error: rate_limit_error (reset after 1h)), exactly the PR's example. 2) Started the main dev server on a fresh database with the Claude provider pointed at the stand-in, and turned on 'Resume after usage limits' in Settings → Threads. 3) Added a demo project and started an Opus 5.5 thread with 'Say hi'. 4) The turn failed at 09:56:43Z. The persisted failure is {class: usage_limit, code: api_error_429, resetAt: 2026-11-14T10:56:43.553Z}, and the thread's limitRecovery has the same resetAt with autoResume: true. The UI shows 'Limited' and 'Usage limit reached · Resumes 10:56 AM'. That one-hour deadline comes only from the nested last-error text; the proxy's own message has no cooldown, so the reset should be unknown. This reproduces the first defect. 5) Second scenario (outer proxy cooldown together with a native rejected rate_limit_event): with the proxy also returning anthropic-ratelimit-unified-* rejected headers, the API-key CLI still emits no rate_limit_event (main's code notes that API-key sessions get no rate_limit_info). Native limit events need first-party Claude OAuth, which no VM has, so the 'later deadline discarded' and 'unknown native reset replaced' cases were not run end to end.
Evidence
Run the real Claude CLI through the real server and web client against an HTTP 429 stand-in whose only deadline is nested inside last error: rate_limit_error (reset after 1h). With automatic recovery enabled, open a fresh Opus 5.5 thread and send Say hi. Both sides use fresh synthetic state, Chromium on Linux, light theme, and a 1280×800 CSS viewport.
Base persisted a one-hour reset deadline and armed automatic recovery. Head persisted resetAt: null and no recovery schedule. Both received the same proxy error.
Permanent blocker: Combining a proxy cooldown with a native blocking rate_limit_event requires first-party Claude OAuth, unavailable on any VM. The later-proxy-deadline and unknown-native-reset cases were not run end to end.
The one-hour recovery timer was not allowed to expire; evidence covers the displayed deadline and persisted recovery schedule.
Tests
No new local runs this round, because no code changed. On the PR, CI passed all 35 checks on 1f88524. Last round: vp test run ClaudeAdapterV2.test.ts -t 'recovers wrapped gateway limits' passed 13 of 13, and vp run check:changed passed.
Not in this change
Automatic recovery when every proxy account is exhausted is not tested end to end (no first-party Claude OAuth or proxy pool on the VM).
CodeRabbit notes the PR description's Evidence section is still marked as being captured; the pipeline fills in the PR description, so I left it.
Who did the work
Written by Claude Opus 5.5, in Claude Code
Reviewed by GPT-6.1 Sol, in Codex, and by Claude Opus 5.5, each on its own
Proof captured by GPT-6.1 Sol and checked by Claude Opus 5.5
Claude Code ignores Anthropic's rate-limit headers when it authenticates with an
API key, so a turn rejected by a proxy such as CLIProxyAPI never learns when to
resume. Read the reset time from the proxy's cooldown message instead, even
when Claude Code labels the turn as rate limited.
Macroscope's review found this PR approvable — This change recovers proxy cooldown timestamps while avoiding nested upstream reset hints and preserving unknown-limit handling. Its effects are limited to existing usage-limit reporting and recovery timing.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
Walkthrough
The adapter now parses CLIProxyAPI cooldown text for API 429 failures. During turn finalization, it combines SDK reset times with usage-limit failure reset times and applies the latest time to the terminal usage-limit failure. Tests cover proxy responses, reset values, and failure classification.
API 429 failures that match CLIProxyAPI’s “Request rejected” and “All credentials” text use a dedicated reset pattern. Tests cover proxy message variants and classify proxy cases as usage_limit.
Combine usage-limit reset times apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts, apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts
Turn finalization includes a non-null reset time from a usage-limit result when selecting the latest reset. Tests cover SDK reset events and resetAt values for proxy and non-proxy cases.
This change improves how Claude rate-limit cooldown deadlines are recovered from proxy errors. It is narrowly scoped and has targeted tests. No merge-blocking risk was identified.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title names the main change: the Claude adapter now recovers cooldown reset times from CLIProxyAPI 429 errors. The changeset matches: it parses the outer 'all credentials cooling down' message, ig…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Description check
The description follows the template's sections (Problem, Change, Scope, Verification) and gives specific reproduction steps, before/after evidence, and test results. It also states that the author's …
Full details: Title check
Explanation
The title names the main change: the Claude adapter now recovers cooldown reset times from CLIProxyAPI 429 errors. The changeset matches: it parses the outer 'all credentials cooling down' message, ignores nested 'reset after' text, and combines proxy and native reset times. The title uses the conventional commit format and is specific, so it passes.
Full details: Description check
Explanation
The description follows the template's sections (Problem, Change, Scope, Verification) and gives specific reproduction steps, before/after evidence, and test results. It also states that the author's commits are kept and that the work is attributed to the model and harness. Required content is present, although the Problem section is not labeled as such and the Scope section does not clearly explain the bug-fix scope beyond the supersession note. The description is mostly complete and substantive.
Finishing Touches
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 5 remain after this review.
…5 (Running the fork's tests in apps/server)
Failing check: Running the fork's tests in apps/server
**What failed:** In "Running the fork's tests in apps/server", three cases in `ClaudeAdapterV2.test.ts` failed: `preserves Switchboard recovery timing for over thirty days`, `for other model` and `for trailing text`. Each expected a reset time and got `null`.
**Why:** Those cases are part of the fork's `fork: switchboard` test block. They cover proxy messages that the fork's own parser (`switchboardCooldownResetAt`) rejects on purpose: a cooldown over 30 days, a different model, or text after the reset hint. The fork never read a reset from those messages. It relied on upstream's old catch-all `(reset after …)` match, which found the hint anywhere in a 429 message, and the test comment said so. Upstream's pingdotgg#36642 ("recover Claude cooldown reset times from proxy errors") narrowed that for CLIProxyAPI's "All credentials for model … are cooling down" messages. Now only a cooldown directly after "cooling down" counts, so nested upstream errors are ignored. The fork's message form ("cooling down via provider claude (last error: …) (reset after Ns)") has text in between, so upstream no longer finds a reset there. The fork's parser still rejects them too, so the result is `null`. That is upstream's intended behavior, and upstream's code wins.
**What I changed:** Only the fork seam rows in `apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts`. The three rows now expect no reset (`expected: 0`), and the comment above them describes upstream's new reading. I didn't touch the fork's parser or any upstream code, and every other row in the block still asserts what it did before. `docs/fork/seams.tsv` needs no change because the marker count is the same. Rerunning the full `ClaudeAdapterV2.test.ts` gives 449 of 449 passing, and `check_seams` printed nothing.
Pipyakas
pushed a commit
to Pipyakas/t3code
that referenced
this pull request
Nov 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:M30-99 changed lines (additions + deletions).vouch:trustedAuthor is trusted by repo permissions or the VOUCHED list.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:trusted
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
Nothing needed changing. PR #36642 at 1f88524: all 35 checks passed (8 of them required). Macroscope approved it with no line comments. CodeRabbit's review says 'No actionable comments were generated' and rates the merge risk Minimal. No reviewer finding is open. The fix itself is the same as the last round: the adapter reads the CLIProxyAPI cooldown only from the outer 'All credentials … are cooling down (reset after …)' message and ignores nested 'last error' reset hints. It combines that deadline with native Claude rate-limit resets: the latest known reset wins, and an unknown native reset stays unknown.
Supersedes #26735. The change is @greyxp1's; their commits are kept.
Reproduction on main
Reproduced on main at 0fee26d:
All credentials for model claude-opus-5-5 are cooling down (last error: rate_limit_error (reset after 1h)). Running the claude CLI directly against it producedAPI Error: Request rejected (429) · All credentials for model claude-opus-5-5 are cooling down (last error: rate_limit_error (reset after 1h)), exactly the PR's example. 2) Started the main dev server on a fresh database with the Claude provider pointed at the stand-in, and turned on 'Resume after usage limits' in Settings → Threads. 3) Added a demo project and started an Opus 5.5 thread with 'Say hi'. 4) The turn failed at 09:56:43Z. The persisted failure is {class: usage_limit, code: api_error_429, resetAt: 2026-11-14T10:56:43.553Z}, and the thread's limitRecovery has the same resetAt with autoResume: true. The UI shows 'Limited' and 'Usage limit reached · Resumes 10:56 AM'. That one-hour deadline comes only from the nested last-error text; the proxy's own message has no cooldown, so the reset should be unknown. This reproduces the first defect. 5) Second scenario (outer proxy cooldown together with a native rejected rate_limit_event): with the proxy also returning anthropic-ratelimit-unified-* rejected headers, the API-key CLI still emits no rate_limit_event (main's code notes that API-key sessions get no rate_limit_info). Native limit events need first-party Claude OAuth, which no VM has, so the 'later deadline discarded' and 'unknown native reset replaced' cases were not run end to end.Evidence
Run the real Claude CLI through the real server and web client against an HTTP 429 stand-in whose only deadline is nested inside
last error: rate_limit_error (reset after 1h). With automatic recovery enabled, open a fresh Opus 5.5 thread and sendSay hi. Both sides use fresh synthetic state, Chromium on Linux, light theme, and a 1280×800 CSS viewport.Base persisted a one-hour reset deadline and armed automatic recovery. Head persisted
resetAt: nulland no recovery schedule. Both received the same proxy error.Proxy script · Seed script · Reproduction instructions · Observed persisted state
Not shown:
Tests
No new local runs this round, because no code changed. On the PR, CI passed all 35 checks on 1f88524. Last round: vp test run ClaudeAdapterV2.test.ts -t 'recovers wrapped gateway limits' passed 13 of 13, and vp run check:changed passed.
Not in this change
Who did the work
Run by the t3code factory in T3 Code.