Second Claude account's usage never appears in the Limits tab — silently marked unsupported, never recovers #13053

Activity

1. juliusmarminge commented on Sep 22, 2026

   

   juliusmarminge

   on Sep 22, 2026

   Member

   More actions

   Triage

   Verdict: Confirmed on v0.0.42 (719a76ca1) and current main (aff9318bf). Keep open. Not fixed by nightlies after 0.0.42 (including the cited 0.0.43-nightly.20260919.1978). Not a duplicate of #12170. No later commit touches claudeUsageResponseToLimits / the unsupported lock in applyUsageLimitsUpdate.

   This is a real server usage-limits bug. A second Claude instance can be permanently classified as unsupported after the boot get_usage probe, then silently omitted from Usage → Limits with no bar and no notice — even while mid-turn rate_limit_event data proves the account has real subscription windows.

   What you reported

   Two Claude provider instances, separate Anthropic accounts, each with its own homePath / CLAUDE_CONFIG_DIR. Only one ever appears under Usage → Limits. The other never gets a bar, warning, or error. Hitting a real rate limit on the missing instance surfaces utilization in a turn warning (five_hour at 109%, seven_day at 45% for claudeAgent_bagri), but Limits still shows nothing for it. Persists across days; refresh does not heal it.

   That matches the code.

   What the code does

   1. Probe → unsupported. probeClaudeCapabilities calls the experimental get_usage API per instance (with that instance’s CLAUDE_CONFIG_DIR from makeClaudeEnvironment). claudeUsageResponseToLimits collapses both of these shapes to unavailable: { reason: "unsupported" }:

      if (!response.rate_limits_available || !response.rate_limits) {
        return { limits: makeUnavailableUsageLimits({ checkedAt, reason: "unsupported" }), ... };
      }

      So rate_limits_available: false (API-key / Bedrock intent) and rate_limits_available: true with rate_limits: null (transient fetch failure — the fix(claude): keep limits when the usage fetch fails #10597 shape) are indistinguishable. The raw probe body is not logged, so this report’s exact trigger is unconfirmed; either path yields the same lock.

   2. Limits UI hides unsupported completely.

      • collectLimitAccounts skips any provider where limitsNotice(...) !== null. For unsupported, limitsNotice returns “This account has no subscription limits.”
      • collectLimitNotices then explicitly continues past reason === "unsupported", so that message never appears on the Limits tab either.
      • Net: no bar, no notice — silent disappearance.

   3. Mid-turn data cannot recover. applyUsageLimitsUpdate returns previous unchanged when previous?.unavailable?.reason === "unsupported", on the assumption “an account that cannot have subscription windows will not start reporting them mid-turn.” The logged rate_limit_event / runtime.warning for claudeAgent_bagri falsifies that for this instance: real five_hour / seven_day utilization is produced and then discarded.

   4. Re-probes re-lock. resolveUsageLimitsAfterProbe treats unsupported as authoritative (it replaces published limits). Every successful probe that re-derives unsupported keeps the instance buried. Unlike Claude usage limits: a rate_limit_event after a failed probe is published as a complete window list #12170’s probeFailed path, this does not self-heal on the 5-minute refresh.

   homePath isolation itself is fine (ClaudeHome.ts / adapter tests). The bug is classification + lock + silent UI skip, not config-dir mixing.

   Related, not duplicates

   Work	What it is	Why this is separate
   #12170 / open #12700	Sparse rate_limit_event after probeFailed published as a complete one-window list	Transient / self-heals; different unavailable reason. This issue is a permanent unsupported lock with no Limits row.
   Closed #10597	Map available: true + rate_limits: null → probeFailed instead of unsupported	Would help if that is the second instance’s probe shape. Closed (V2 freeze note); never landed. Does not cover a true available: false on a subscription account. Landing it without #12170/#12700 would also widen the sparse-merge hole.
   Open #12799	Grok: false unsupported → same silent Limits vanish	Same UI/contract footgun, different provider mapper. Pattern confirmation, not a Claude fix.

   No open issue tracks “second Claude account stuck as unsupported and invisible on Limits.”

   Suggested fix

   Keep this a small server (+ optional shared UI) bugfix. Do not invent a new limits protocol.

   1. Narrow unsupported in claudeUsageResponseToLimits. Reserve it for accounts that can never report subscription windows (API key / Bedrock / Vertex). Map rate_limits_available: true + missing rate_limits to probeFailed (the fix(claude): keep limits when the usage fetch fails #10597 distinction). If interactive OAuth / Max accounts can still return available: false under a separate CLAUDE_CONFIG_DIR, treat that as probeFailed (or log and investigate) rather than a permanent can-never-report mark.
   2. Do not let a false unsupported discard mid-turn windows forever. Options (pick one, keep it small):
      • Allow rate_limit_event updates to clear / demote a mistaken unsupported (then apply the Claude usage limits: a rate_limit_event after a failed probe is published as a complete window list #12170/fix(server): keep usage-limits incomplete after sparse post-probe updates #12700 incomplete-marker rules so sparse updates do not look complete), or
      • Stop treating probe-derived unsupported as irreversible when the same instance later emits utilization events.
   3. Log the get_usage shape (rate_limits_available, whether rate_limits is null) on the probe path so the next multi-instance report is not inferred.
   4. UI (small, optional): for an authenticated Claude instance marked unsupported, show a notice instead of the total omit in collectLimitNotices. True API-key accounts can stay muted; subscription-looking accounts should not vanish.
   5. Tests: second-instance / available:true+null → not permanent silent omit; unsupported + mid-turn { id: "five_hour" } must not stay a black hole if you choose (2); existing API-key → unsupported case stays green.

   Coordinate with #12700 so a probeFailed reclassification does not reintroduce weekly-only “complete” snapshots.

   Do not treat “refresh Limits,” “wait for provider health,” or landing #10597 alone as the fix.

   Workaround

   None that restores the Limits row while the probe keeps returning the failing shape. Mid-turn rate-limit warnings still carry real utilization for that instance. Ensuring both instances are interactively signed in under their own homePath (and that env overrides like CLAUDE_CODE_OAUTH_TOKEN are not pointed at the wrong account) is worth checking, but this report’s evidence already shows a live subscription on the missing instance.

   Classification: bug · accepted · medium (server usage-limits; multi-Claude-instance; permanent unsupported lock; silent Limits omit; related to #12170 / #10597 / #12799)
2. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

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

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 22, 2026
3. fatalist commented on Oct 3, 2026

   

   fatalist

   on Oct 3, 2026

   More actions

   Hit this with a single Claude instance (no second account, no CLAUDE_CODE_OAUTH_TOKEN override), and I can confirm which get_usage response triggers it.

   Setup: T3 Code (Nightly) 0.0.46-nightly.20261003.2638, Claude Code CLI 2.1.288, Claude Team subscription, macOS 27.2. Usage → Limits only shows Codex. Claude isn't there at all, and there's no notice either.

   What the CLI returns: I ran the same calls the capabilities probe makes (initializationResult() and then usage_EXPERIMENTAL_MAY_CHANGE_DO_NOT_RELY_ON_THIS_API_YET()) through @anthropic-ai/claude-agent-sdk against the same CLI binary:

   {
     "subscription_type": "team",
     "rate_limits_available": true,
     "rate_limits": null
   }

   I got the same result with settingSources: [], so it isn't caused by my user settings.

   So the account clearly has subscription limits (rate_limits_available: true), but rate_limits is null. In the 2.1.288 bundle, rate_limits is only null when the CLI's own usage fetch doesn't come back with status: "ok", e.g. an in-band error, a 429, or an empty body. In other words, the fetch failed on the CLI side. It doesn't mean the account has no limits.

   claudeUsageResponseToLimits treats both cases the same way:

   t3code/apps/server/src/provider/Layers/claudeUsageLimits.ts

   Lines 162 to 167 in 8d84666

   	if (!response.rate_limits_available || !response.rate_limits) {
   	return {
   	limits: makeUnavailableUsageLimits({ checkedAt, reason: "unsupported" }),
   	names: { overageIncluded: undefined },
   	};
   	}

   and then collectLimitNotices skips "unsupported" without showing anything:

   t3code/packages/shared/src/usageLimits.ts

   Lines 302 to 304 in 8d84666

   	// An account that can never report (API key) is left out; one that
   	// failed, or reported nothing at all, is worth a line.
   	if (provider.usageLimits?.unavailable?.reason === "unsupported") continue;

   Suggestion: only use "unsupported" when rate_limits_available === false. When it's true but rate_limits is null, treat it as probeFailed, so the user sees a notice, later rate_limit_events aren't locked out, and the next probe can recover.

   Screenshots: the composer is on Claude Opus 5, and the Limits tab shows only Codex.

   
4. saphid

   added a commit that references this issue on Oct 5, 2026

   fix(server): report a signed-out Claude CLI instead of hiding its limits

   ...

   8c6163d
5. caitlon commented on Oct 5, 2026

   

   caitlon

   on Oct 5, 2026

   More actions

   Confirmed one trigger for the silent unsupported: a token from claude setup-token passed through CLAUDE_CODE_OAUTH_TOKEN.

   Same Claude Max account, same machine, same SDK probe T3 runs (initializationResult() + usage_EXPERIMENTAL…()):

   auth	account.subscriptionType	get_usage
   CLAUDE_CODE_OAUTH_TOKEN from claude setup-token	undefined	rate_limits_available: false
   /login (credentials file, scopes include user:profile)	Claude Max	true, windows present

   It shows up as soon as T3 runs on a remote machine over SSH: the macOS keychain is locked in an SSH session, so a setup token is the usual way to sign Claude in there. The Limits tab then says "No provider on the selected environments reports subscription limits", while Tokens and Cost still work, so nothing points at the token.

   Telling apart "no subscription" from "signed in with an inference-only token" would make this self-explanatory: the init result already reports tokenSource: CLAUDE_CODE_OAUTH_TOKEN, so the Limits tab could say that limits need a full claude /login instead of staying silent.
6. saphid

   added 2 commits that reference this issue on Oct 6, 2026

   fix(server): report a signed-out Claude CLI instead of hiding its limits

   ...

   1b9f5fe

   fix(server): report a signed-out Claude CLI instead of hiding its limits

   ...

   d2080c5
7. fixfon commented on Oct 12, 2026

   

   fixfon

   on Oct 12, 2026

   Contributor

   More actions

   I'm picking this up. I reproduced it on main with a failing test: claudeUsageResponseToLimits maps rate_limits_available: true with rate_limits: null to unsupported, which hides the account from Limits and discards streamed windows. The fix narrows unsupported to rate_limits_available: false and maps the true + null shape to probeFailed, so it shows a notice and recovers on the next probe or streamed window. It is separate from #12170 / #15116 (sparse rate_limit_event handling) and from the CLAUDE_CODE_OAUTH_TOKEN setup-token case, which really reports rate_limits_available: false.

   👍React with 👍1Reacted by jaypopat
8. juliusmarminge

   closed this as completedin #18624on Oct 20, 2026