Claude Usage → Limits shows only two of three enabled accounts; third reports Could not read limits #15967

Activity

1. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @tallboxdesign for the careful report, and for keeping it privacy-safe. What you describe matches current main and nightly 0.0.46-nightly.20261005.2667 (37de6cbde). It's a different path from #13053 and #15364, and it's in the same family as #15354.

   What I found

   • "Could not read limits." is only the probeFailed notice. limitsNotice returns it when unavailable.reason === "probeFailed" (usageLimits.ts).
   • Claude reports that reason when its capabilities probe comes back with no usage payload (ClaudeProvider.ts). usage is left out when get_usage times out or throws. That read has its own 4s deadline (DEFAULT_TIMEOUT_MS), separate from the 25s initialization budget, and a failure there isn't logged (ClaudeProvider.ts).
   • The silent omission in Second Claude account's usage never appears in the Limits tab — silently marked unsupported, never recovers #13053 and [Bug]: Claude disappears from Usage → Limits when get_usage returns rate_limits_available: true with rate_limits: null #15364 is the unsupported path, which shows no warning at all. Since you do see the warning, that isn't what's happening here. fix(server): Claude stays in Usage limits when its usage read comes back empty #15443 hasn't merged, so this build can't be showing that case either.
   • Bar sections only include accounts without a notice, so one probeFailed account drops out of Session, Weekly, and model-specific Weekly at once. Each Claude instance probes on its own, and nothing in this path caps the display at two accounts.
   • A probeFailed account still accepts a later rate_limit_event, so a turn on that account may fill in its bars afterward.

   Likely fix area

   If only the third account's get_usage read is slower than 4s, this is the same cause as #15354. Open PR #14064 raises that budget to 15s and logs the failure. Another option is making the warning more actionable, with a reason and a retry, as you suggested.

   If you can share them, these details from the affected account would help narrow it down:

   1. The Claude Code CLI version.
   2. The duration of one checkClaudeProviderStatus span from server.trace.ndjson. About 4s after initialization points to the usage timeout, and a much shorter span means the read threw.
   3. Whether running a turn on that account later shows its bars.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 5, 2026
3. tallboxdesign commented on Oct 5, 2026

   

   tallboxdesign

   on Oct 5, 2026

   Author

   More actions

   Thanks for the triage. Here are the requested details, with private account and machine identifiers omitted.

   1. Claude Code CLI: 2.1.289 (Claude Code).

   2. Timings: a recent checkClaudeProviderStatus span in the local server trace lasted 4,844.1905 ms, with exit: Success. Other recent spans were approximately 4.71–4.85 seconds. However, these spans and their parent spans contain no provider-instance attribution, so I cannot honestly identify which one belongs to the affected account or separate initialization from usage time using those spans alone.

      To resolve that ambiguity, I directly probed the affected account's configured Claude home with the installed CLI, using stream-JSON control requests and no model prompt:

      Operation	Measured duration	Result
      initialize	671 ms	Success
      get_usage (sent after initialization)	5,306 ms	Success; rate_limits_available: true; nonempty rate_limits

      This was one isolated measurement, with MCP servers disabled and a 30-second observation deadline. It did not run a model turn or change account settings. The usage call alone exceeded the app's 4-second deadline by 1.306 seconds. This strongly supports the timeout explanation, although it does not prove every previous failure had the same cause.

   3. Bars after a turn: not yet verified. The screenshot confirms they were missing before this check. The standalone control probe above does not test whether a T3-managed turn restores the dashboard through a later rate_limit_event, so I am not claiming that it does or does not recover. The user has been asked to check that behavior.

   No raw account payload, usage figures, session IDs, local paths, or screenshots are included.

   Investigated and prepared by Codex (GPT-6-Astra).
4. tallboxdesign commented on Oct 5, 2026

   

   tallboxdesign

   on Oct 5, 2026

   Author

   More actions

   Additional user clarification: all three Claude Code accounts work in terminal mode inside T3 Code, but do not work in T3 chat mode.

   This is user-reported behavior; I have not independently reproduced the terminal-versus-chat comparison for each account. It broadens the symptom beyond the usage dashboard. The failure message for each account in chat mode has not yet been collected, so I am not asserting that all three failures share the same cause.

   This does not answer whether a successful T3 chat turn restores the missing usage bars: a successful chat-mode turn on the affected account has not been established. Terminal-mode success should not be treated as verification of T3 chat-mode rate-limit-event recovery.

   The separately measured usage request exceeding four seconds remains relevant to the missing bars. The previously reported session-recovery failure is tracked in #15103; whether the other chat-mode failures are related is unconfirmed.

   No private account or work identifiers are included.