[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

This is a confirmed bug on main. In apps/server/src/usage/cliproxyApi.ts, readAccount sends api/oauth/usage through the hub's api-call every time it runs, with no per-account pacing and no cached reading. Any failure, a 429 included, goes through orElseSucceed and comes back as probeFailed ("The hub could not read this account's usage."). Every Limits refresh can blank the bars, and a rate limit looks the same as any other failure.

Workaround: refresh Limits no more than every few minutes. If the bars go blank, wait out the 429 window and refresh once.

Your fork branch follows the same policy as open PR #19474 (one read per interval, keep the last reading, back off longer after a refusal, forget after a redeem). A PR is welcome. Please keep it focused, reuse #19474's helper where it fits so the two don't drift apart, and add TestClock tests for the pacing, the 429 back-off and the fallback to the last reading. #10310 (respect disabled polling) is related but separate.

Seeing similar behavior on the official T3 Code v0.1.0 macOS arm64 package with CLIProxyAPI 7.3.0 and three Claude subscription accounts.

All three accounts remain registered and enabled in the proxy, but T3's Limits screen sometimes shows only one. During investigation, per-account OAuth usage requests through the hub returned HTTP 429. Later reads recovered all three without reauthentication.

We also observed 429s on direct OAuth usage reads, so we haven't established that T3 refreshes caused the throttling. The confusing part is that failed readings disappear from the pooled display, making the accounts look missing. This appears consistent with this issue and the proposed fix in #19820.

Also hitting this, and it's what you see on mobile: the iOS app's Usage → Limits shows only "No provider on the selected environments reports subscription limits.", with no error and nothing hinting at a 429.

Setup

• T3 Code server 0.1.1-nightly.20261020.3411, Linux
• iOS app 2.0.0
• CLIProxyAPI v8.0.36 as the usage source, reached over HTTPS (Tailscale Serve)
• Two Claude accounts pooled in the hub

What I checked

I repeated T3's requests by hand against the hub, with the same key, paths and headers as cliproxyApi.ts:

The hub works; Anthropic is rate-limiting the usage endpoint for both accounts. When every account comes back 429, the Limits screen falls through to the generic "no provider reports subscription limits" message. That points the user at their configuration, when the real cause is a temporary upstream rate limit. Desktop had shown the bars shortly before, which fits the burst pattern described above.

Two suggestions on top of the fix proposed here:

1. Keep the last successful reading and mark it stale, instead of dropping the account when a refresh gets a 429.
2. If every account fails, say so ("Usage temporarily unavailable, rate limited by Anthropic, retrying at …") instead of showing the "no provider" empty state.

Fresh triage: ordinary bug; no exploitable vulnerability reported.

Reproduced on Linux, Node 24.21.0, Chromium web client at main b5a226e49c, with isolated worktree state and the reporter's fake CLIProxyAPI hub on port 18317. Added the two-account hub in Settings → Providers, then opened Usage → Limits.

After resetting the fixture, Refresh limits at 00:04:48 UTC sent two probes and showed both accounts' session/weekly bars. Refresh again at 00:04:54 sent two more probes; both returned upstream 429. Both accounts disappeared and web showed “No provider on the selected environments reports subscription limits.” This matches the later mobile comment's empty-state symptom; the current web client does not show the per-account read-failure message from the original report.

Initial successful read:

Initial successful read: two Claude account bars

After a second refresh six seconds later:

After refresh: both Claude accounts disappear after upstream 429

No duplicate symptom found across the open issue list through the 90-day cutoff. Existing fix #19820 remains open and explicitly awaits a maintainer decision on pacing/backoff/retention; no competing PR opened. This pass verifies main only. Real upstream accounts, Electron, and native mobile were not verified.

8. Fresh triage: ordinary bug; no exploitable vulnerability reported. Reproduced on Linux, Node 24.21.0, Chromium web client at main b5a226e49c, with isolated worktree state and the reporter's fake CLIProxyAPI hub on port 18317. Added the two-account hub in Settings → Providers, then opened Usage → Limits. After resetting the fixture, Refresh limits at 00:04:48 UTC sent two probes and showed both accounts' session/weekly bars. Refresh again at 00:04:54 sent two more probes; both returned upstream 429. Both accounts disappeared and web showed “No provider on the selected environments reports subscription limits.” This matches the later mobile comment's empty-state symptom; the current web client does not show the per-account read-failure message from the original report. 00:04:48 usage probe #1 account 1 -> 200 00:04:48 usage probe #2 account 2 -> 200 00:04:54 usage probe #3 account 1 -> 429 00:04:54 usage probe #4 account 2 -> 429

1	Initial successful read:
2	
3	After a second refresh six seconds later:
4	
5	No duplicate symptom found across the open issue list through the 90-day cutoff. Existing fix [#19820](https://git.cafe/pingdotgg/t3code/pulls/19820) remains open and explicitly awaits a maintainer decision on pacing/backoff/retention; no competing PR opened. This pass verifies main only. Real upstream accounts, Electron, and native mobile were not verified.

Would this be a fix that would go out in Stable given the impact by chance?

@entity I can't answer that: whether and when this goes out in Stable is up to the maintainers. Here's where it stands.

#19820 is open, CI is green, and it's waiting on a maintainer decision about the pacing, back-off and retention timings, as noted in the triage above. It isn't on main yet, so current nightlies don't have it either.

What it changes, in the reproduction above:

• A refresh within a minute of a good reading reuses that reading and sends no probe. The six-second second refresh would keep both accounts' bars and send no probes.
• When a probe does get a 429, the last good reading stays up for up to 15 minutes. Each failed probe doubles the wait before the next try, up to 8 minutes.

What it doesn't change: an account that has never had a good reading since the server started still shows the "No provider on the selected environments reports subscription limits." empty state on web and mobile. The server marks that account as rate limited, but the Limits view hides accounts that have no reading. Your second suggestion, a clear "rate limited" message when every account fails, would need a client change outside this PR.

Written by Claude Opus 5.5 (Claude Code) on behalf of @JustYannicc.