fix(server): give Claude's usage read time to answer

[mkantautas]

What Changed

The Claude capabilities probe gives the SDK's get_usage read its own 15s budget instead of the shared 4s DEFAULT_TIMEOUT_MS, and logs a warning when the read fails. The existing timeout test moves to 15s; a new test covers a read that answers after 5s.

Why

Usage → Limits showed "Claude: Could not read limits." on a working Claude Max account. get_usage makes the CLI fetch the account's usage from Anthropic, and with Claude Code 2.1.283 that took 2.7–4.3s across seven runs of the probe's exact SDK options (0.3.276). The 4s timeout cut it off, the probe returned no usage, and the provider published probeFailed. The server trace shows the same thing: checkClaudeProviderStatus spans of 4.6–4.9s, which is init (~0.7s) plus the 4s timeout. Nothing was logged, so the failure was invisible outside the UI.

The probe returns its result once the usage read settles, so a read that hangs now holds the result for up to 15s instead of 4s. Initialization keeps its own 25s budget.

Checklist

• This PR is small and focused
• I explained what changed and why

Verified with vp test run src/provider/Layers/ClaudeCapabilitiesProbe.test.ts (4 passed; the new test fails on the old 4s budget), vp lint and vp fmt --check on the two files, and the server typecheck.

Summary by CodeRabbit

• Bug Fixes
  • Improved reliability of Claude capability checks when usage information is slow or unavailable. Account and command capabilities remain available if the usage request times out or fails, and usage information is included when it arrives in time. This helps ensure that delayed usage responses do not prevent other capability information from appearing in the probe results.

Fixes #15354

[macroscopeapp]

Approvability

Verdict: Approved at bee4e97

Macroscope's review found this PR approvable — This small bug fix gives Claude’s existing usage probe enough time to receive slow responses while preserving the overall probe deadline and existing capability fallback behavior. The accompanying test covers both delayed success and timeout handling.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

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

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: e7e6489d-b51f-4ff9-b028-ea1cc9c62b75

📥 Commits

Reviewing files that changed from the base of the PR and between d15210c and bee4e97.

📒 Files selected for processing (2)

• apps/server/src/provider/Layers/ClaudeCapabilitiesProbe.test.ts
• apps/server/src/provider/Layers/ClaudeProvider.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The Claude capability probe now allows 15 seconds for its optional usage request. Usage-read failures are logged as warnings. Tests cover delayed usage data and timeout behavior.

Changes

Claude usage probe

Layer / File(s)	Summary
Usage timeout and probe tests apps/server/src/provider/Layers/ClaudeProvider.ts, apps/server/src/provider/Layers/ClaudeCapabilitiesProbe.test.ts	The optional usage request uses a dedicated 15-second timeout and logs failures as warnings. Tests verify that delayed usage data is included and that initialized capabilities remain available when usage times out.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: t3dotgg

Merge Risk: ⚪ Minimal · up to bee4e

Claude usage reads have more time to return without withholding initialized account and command capabilities. No actionable merge-blocking risk is established.

Security Architecture Review

Security architecture risk: 🔵 Low · up to bee4e

The change adds no new endpoint or privilege, and a failed usage read still leaves account information available. It does newly log failure details from the usage request. Whether those details can contain sensitive information is not established.

Retained concerns

• Low · security · inferred: The new warning forwards the usage-read failure cause to server logs, including a configured remote collector, without visible application-level filtering. Sensitive contents in that cause are unverified.

Security review details

Security Blast Radius

• inferred — The newly exposed material is limited to failures of per-instance Claude capability probes, but a warning can reach server console logs and a configured remote log collector.

Security Findings and Attack Paths

• inferred — If an SDK failure cause contains authentication material, the new warning could carry it across the logging boundary. Neither such cause contents nor a credential leak is established by the available source.

Trust Boundaries and Controls

• observed — The change leaves the probe's noninteractive query construction and existing per-instance caller in place. The new log annotation passes the failure cause without visible filtering in the application path.

Resilience and Maintainability Implications

• observed — A usage timeout is captured as an optional-read failure, and the probe's completion path aborts its SDK query rather than discarding initialized capabilities.

Hardening Proposals

• proposed — Consider logging a bounded failure category instead of the complete SDK cause unless the exception contents and telemetry redaction guarantees have been verified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main change: giving Claude's usage read more time to answer.
Description check	✅ Passed	The description explains the problem and change, and gives focused verification results. It does not include the template's Scope and approval section or state why this focused fix qualifies without p…

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

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

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for digging into this. #16358 is now on main and fixes the same "Could not read limits" failure at its source: most of get_usage's time went to the CLI scanning every local Claude transcript to fill behaviors, which the probe never reads. The probe now passes skipBehaviors: true, which took the same request from about 5.5 s to about 0.4 s, well inside the existing 4 s budget. The related report, #15354, is closed as fixed by it. I'm closing this as superseded. If Limits still fails on a release that includes #16358, reply here and we can revisit a longer usage timeout.