[Bug]: Native Claude reset-credit read retries /api/oauth/usage every 5 minutes after a 429 and ignores Retry-After, so the account stays rate-limited #37053

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Sign in to Claude Code with one Pro or Max login, and use the native Claude provider in T3 Code.
2. Keep T3 Code open while other clients on the same login also read GET https://api.anthropic.com/api/oauth/usage (Claude Code itself, or a usage widget).
3. Wait until the endpoint answers HTTP 429 to any request on the login.
4. Read the server traces in ~/.t3/userdata/logs/server.trace.ndjson* for url.full = https://api.anthropic.com/api/oauth/usage?cedar_ember=1&skip_spend=1 (the readClaudeResetCredits span).

Expected behavior

After a 429, the reset-credit read waits until the Retry-After time before it asks again, and keeps the last good reset data in the meantime.
The wait survives a server restart, and every route that reads the endpoint shares it.

Actual behavior

The reset-credit read keeps its 5-minute cadence through the 429:

Another client on the same login honors Retry-After:

• Its request at 02:27:51 got 429 with a wait until 03:19:42. That is exactly one hour after T3 Code's first 429 at 02:19:43.
• Its next request, at 03:22:30, after that wait ended, got 429 again with a new wait of exactly 3600 seconds.

The endpoint seems to block the whole login for one hour, and the retries inside the block appear to keep the login over the limit.
Every client on the login then loses the endpoint for hours, including Claude Code's own usage reads.

On main (e2afd25), readClaudeResetCredits in apps/server/src/provider/claudeResetCredits.ts still has no 429 branch.
filterStatusOk fails on the 429, and Effect.orElseSucceed(() => undefined) turns the failure into "no reset data", so the caller can't tell a rate limit from an empty balance and has no wait time to honor.

Impact

Minor bug or occasional failure

Version or commit

T3 Code (Beta) 0.1.8 desktop. Claude Code 2.1.322.
The reader is the same on main at e2afd25 (after 0.1.9).

Environment

Windows 11, one Claude Pro login, native Claude provider. No CLIProxyAPI hub.

Logs or stack traces

{"name":"GET","attributes":{"url.full":"https://api.anthropic.com/api/oauth/usage?cedar_ember=1&skip_spend=1","http.response.status_code":200},"exit":{"_tag":"Success"}}
{"name":"GET","attributes":{"url.full":"https://api.anthropic.com/api/oauth/usage?cedar_ember=1&skip_spend=1","http.response.status_code":429,"error.type":"429"},"exit":{"_tag":"Failure","cause":"HttpClientError: StatusCode error (429 GET https://api.anthropic.com/api/oauth/usage)"}}

The spans start at 02:14:42, 02:19:43, 02:24:44, and 02:34:45 local time on 2026-11-14.
The traces are sampled, so the table can miss requests.

Related

• [Bug]: Native Claude provider: usage probes hit /api/oauth/usage with no back-off and drop the last good reading (429s) #27772 asks for the same back-off on the native Claude capability probes (the CLI processes). This report is about the separate direct reset-credit request, which goes through readClaudeResetCredits, not through a probe process.
• [Bug]: Limits hub blanks Claude accounts after a few refreshes because every refresh re-probes /api/oauth/usage and 429s are shown as a read failure #19807 has the same problem for hub reads.
• fix(server): banked Claude resets are read at most every ten minutes per account #19474 proposed "banked Claude resets are read at most every ten minutes per account", and was closed without a merge on 2026-11-12.
• fix(server): Claude reset credits survive failed refreshes #33979 (open) caches the reset-credit read to at most once a minute and keeps the last grant for five minutes after a failure. It does not read Retry-After, so its reads would continue inside the one-hour block.
• fix(server): poll provider usage only while visible #31032 (open) moves quota reads to visible usage surfaces and also changes claudeResetCredits.ts.

Suggested behavior

1. On 429, read Retry-After and send no reset-credit read before that time. Without the header, wait at least 15 minutes.
2. Keep the last good reset data while rate-limited.
3. Share the wait with the other /api/oauth/usage routes in [Bug]: Native Claude provider: usage probes hit /api/oauth/usage with no back-off and drop the last good reading (429s) #27772, so that one throttle covers the login.

Workaround

None known in T3 Code.