fix(usage): show streamed limits for Claude setup-token accounts#24119

Approvability

Verdict: Approved at e411a3e

Macroscope's review found this PR approvable — This is a focused fix to expose Claude OAuth usage windows that are already emitted by the SDK, with explicit guards preserving behavior for API-key, custom-endpoint, and unsupported accounts. The additive contract and merge changes are backward-compatible and supported by targeted regression tests.

^{You can add or adjust custom eligibility rules. Learn more.}

Review in Change Stack →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

Fixed the outside-diff availability finding from review 5628824467 in a226378c87. A valid top-level session/weekly window now marks the stream update available even when unifiedWindows is missing, empty, or malformed. Three regression cases reproduced the hidden-account failure before the fix and now pass through the actual mapper and usage-limit merge. Unsupported-account guards remain covered. check:changed passed with 278 related tests; the two directly focused suites passed 24 tests.

Model/harness for this follow-up: GPT-6 / Codex desktop.

Addressed the new outside-diff finding in b2d9f33c93. When capabilities have no usage payload, the provider now reuses claudeUsageResponseToLimits rather than unconditionally returning probeFailed. Eligible first-party OAuth/setup-token accounts keep the streamed-limits notice; other account sources remain unsupported. The existing account matrix now covers both absent and explicitly unavailable usage.

Before: 8 new missing-usage cases failed. After: 286 tests across 4 related files and all affected format/lint/knip/GraphQL/typechecks pass. No real credentials or provider calls were used.

@coderabbitai review

Model/harness: GPT-5-based Codex / Codex desktop.

Follow-up on the conflicting outside-diff suggestion: after checking ClaudeCapabilitiesProbe and the actual usage request, e411a3e904 retains probeFailed when usage is absent and adds the notice only for eligible streamed-limit accounts. Absence means request failure, not an explicit unsupported response; mapping it to unsupported would discard last-good windows. The expanded matrix now exercises this retention with the real refresh merge. Explicit negative responses remain classified by eligibility. 286 scoped tests and affected checks pass.

@coderabbitai review

Model/harness: GPT-5-based Codex / Codex desktop.

Merged main c3888da8b4 in e5357aa87d without rewriting history. The conflict was limited to main's shortened comment next to the existing availability reset: retained both the concise comment and the PR's unavailable-state clearing behavior. check:changed passed all scoped gates and 315 tests across four files.

@coderabbitai review

Please review the current head e5357aa87d. The previous automatic review paused before this merge update; main integration retained the unavailable-state clearing behavior, and the current-head CI and scoped checks have passed.

Additional confirmation for ordinary native-subscription logins, beyond this PR’s setup-token case.

Environment: macOS, T3 Code 0.1.3, Claude Code 2.1.311, direct Claude Max subscription; no CLIProxyAPI.

I reproduced get_usage returning: { "rate_limits_available": true, "rate_limits": null }

The CLI’s sanitized debug output identifies HTTP 429 from /api/oauth/usage. Live sessions still emit valid session and weekly readings under rate_limit_info.unifiedWindows.

Against main 36d4d711b79c73eb33131944f73ea4a8c6156484, I tested a focused local candidate combining the mapper from #14441 with the available:true recovery mechanism from this PR:

• Main: the captured nested-only event is discarded. • Mapper alone: the event parses, but probeFailed persists and collectLimitAccounts still excludes the account. • Both pieces: the account becomes visible and a subsequent failed probe retains its readings.

Verification: 66 focused tests passed across the mapper, usage merge, managed provider, and shared display-selector files. check:changed passed. A local replay accepted all 155 captured native usage events and kept the account visible through simulated subsequent probe failures. CodeRabbit reported no findings.

This verifies those mechanisms together on current main, not this PR’s full branch or setup-token authentication changes. No installed-app UI, live post-patch session, or native mobile verification was performed. Recovery still requires a usable live usage event; it does not remove Anthropic’s endpoint rate limit.

Could the mapper and recovery changes be reconciled for shipping together? I have a focused patch and regression available if useful. Credit remains with the authors of #14441 and #24119.

Candidate assembled and verified with GPT-6.1 Sol through Codex in T3 Code.

Thanks for the native-subscription evidence. I checked the current branch against the reported combination: this PR already contains both nested unifiedWindows session/weekly parsing and the available: true recovery path. A rate_limits_available: true, rate_limits: null response is classified as probeFailed; a usable event clears that state, including unchanged window values, and subsequent failed probes retain the published reading. These parts are not limited to setup-token logins. The extra authentication gate applies to otherwise-unsupported first-party OAuth logins.

The mapper test covers nested session/weekly readings without top-level utilization and top-level precedence; the provider-core test covers failed-probe recovery and retention across another failed refresh. #14441 remains an overlapping mapper PR and includes nested overage handling beyond the session/weekly case discussed here. The two branches should preserve those cases when reconciled; whichever lands second should retain the landed mapper and carry only its remaining behavior/tests. I have kept that relationship explicit in this PR's description rather than creating a third overlapping implementation.

Your live native-event evidence usefully complements this branch's synthetic adapter/UI verification. It does not establish a live setup-token validation, so the current evidence limitations remain unchanged.

Closing in favour of #24128, which makes the same change. Thanks for the work here!