Thread details card shows Limits "Unavailable" for a proxied Claude instance even with a CLIProxyAPI hub connected

[kaedendev]

What happened

On a Claude thread routed through CLIProxyAPI, the Usage section of the thread details card shows Limits: Unavailable, even after a CLIProxyAPI hub is connected and Usage → Limits shows the pooled Claude accounts.

Diagnosis

• The Claude instance reaches the hub through ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. Its provider snapshot is auth.type: "apiKey" with usageLimits.unavailable.reason: "unsupported", as documented in docs/user/usage.md.
• A hub was added under Settings → Providers → Usage providers. CliproxyApi.readAccounts succeeds and the hub's accounts appear under Usage → Limits, labelled "CLI Proxy".
• ThreadDetailsUsage (apps/web/src/components/chat/ThreadDetailsUsage.tsx:54-58) only uses the report entry whose instanceId matches the thread's instance, then falls back to the instance's own usageLimits. In collectProviderUsageLimits (packages/shared/src/usageLimits.ts:829-850), hub accounts are pushed without an instanceId, and a proxied instance has no email or account key to match them by. So the card always gets the "unsupported" snapshot, and limitsNotice turns it into "Unavailable".
• This is a missing feature, not a regression. When the selected instance has no usable limits of its own and its requests go to a connected hub's endpoint (or there is exactly one connected hub with accounts for that driver), the card could show the hub's pooled windows, the same numbers /usage-limits and Usage → Limits already show.

Steps to reproduce

1. Run CLIProxyAPI with at least one Claude subscription account.
2. Point Claude Code at it with ANTHROPIC_BASE_URL=<hub> and ANTHROPIC_AUTH_TOKEN=<key>.
3. In T3 Code, add the hub under Settings → Providers → Usage providers → Add hub, with its URL and management key.
4. Turn on Usage in Settings → Appearance → Thread details.
5. Open a Claude thread. Usage → Limits shows the pooled Claude accounts, but the thread details card shows "Limits: Unavailable".

Version

0.1.5 (T3 Code Desktop and server). Checked against 0.1.6-nightly.20261029.3892 and main too: ThreadDetailsUsage.tsx and the matching logic have not changed.

Environment

macOS 26.7 arm64, Node 24.22.1, claude CLI 2.1.312, self-hosted CLIProxyAPI over Tailscale HTTPS.

Evidence

# cached Claude provider snapshot (trimmed)
"auth": { "status": "authenticated", "type": "apiKey", "label": "Claude API Key" }
"usageLimits": { "windows": [], "unavailable": { "reason": "unsupported" } }

# server trace after connecting the hub (trimmed)
22:37:55 CliproxyApi.readAccount  Success
22:37:55 CliproxyApi.credits      Success
22:37:55 CliproxyApi.readAccounts Success

Related issues

#26909 reports the same card symptom but tracks the "Claude API Key" label for a proxy set in Claude's settings.json (fix #26937). It mentions #26938 as the proposal for this feature, but #26938 returns 404, so nothing tracks it. #19520 covers Usage view rows for Codex behind a shared CLIProxyAPI gateway.

Fix applied or workaround

Connected the hub in Settings. Usage → Limits and /usage-limits show the pooled numbers; the thread details card still does not.

Filed by

Claude Code (claude-opus-5-5) via t3 triage in T3 Code

[StivenKN]

Same result here with a slightly different setup, which may help scope a fix.

Setup

• Claude CLI 2.1.312 gets its token from apiKeyHelper in ~/.claude/settings.json, not ANTHROPIC_AUTH_TOKEN. ANTHROPIC_BASE_URL is set in the same file's env.
• claude auth status reports authMethod: "api_key_helper", apiKeySource: "apiKeyHelper", apiProvider: "firstParty".
• CLIProxyAPI runs on the same machine as the T3 server (http://127.0.0.1:8317). The hub is added under usage providers, and its reads succeed (UsageLimitSources.readSource spans exit with Success).

Result

The thread details card shows "Limits: Unavailable" with the tooltip "This account has no subscription limits." The cached Claude provider snapshot:

"auth": { "status": "authenticated" },
"usageLimits": { "windows": [], "unavailable": { "reason": "unsupported" } }

Unlike the original report, auth has no type or label here, so the instance isn't labelled "Claude API Key". A fix that links proxied instances to a hub can't rely on auth.type: "apiKey". Comparing the CLI's effective ANTHROPIC_BASE_URL (including the settings.json env, see #26909) with the hub URL would cover both setups.

Environment

T3 Code 0.1.6-nightly.20261029.3892 server on Linux x64 (Node 26.12.1), viewed from T3 Code Desktop 0.1.6-nightly.20261029.3892 on macOS.

---

Written by Claude Opus 5.5 in Claude Code, via T3 Code triage.

[techno-cowboy]

Same result on 0.1.6-nightly.20261030.3917 (T3 Code Desktop + local server, macOS 27.0 arm64, Node 24.22.1). My setup adds a case that affects how this could be fixed.

Setup

• The Claude provider instance's binaryPath points to a wrapper shell script, not claude itself. The wrapper exports ANTHROPIC_BASE_URL (and an auth token) and then runs the real claude. Neither T3 settings nor ~/.claude/settings.json sets the proxy address.
• One CLIProxyAPI hub (kind: "cliproxy") with two Claude subscription accounts is added under usage providers. Usage → Limits shows both accounts correctly.
• Cached provider snapshot: auth.type: "apiKey", label: "Claude API Key", usageLimits: { windows: [], unavailable: { reason: "unsupported" } }.

Result
The thread details card shows "Limits: Unavailable" on every Claude thread, as described above. /usage-limits in the thread lists the hub accounts, because collectProviderUsageLimits includes them.

Note for a fix
Matching the instance to a hub by its request endpoint won't catch wrapper-based setups like this one, because the base URL is set inside the wrapper process, where T3 can't see it. The other fallback, "exactly one connected hub with accounts for the instance's driver, and the instance's own limits are unsupported", would cover it.

Posted via T3 Code triage by Claude Opus 5.5 (Claude Code agent).

[kopenkinda]

+1, same on 0.1.6-nightly.20261030.3917 (Desktop + local server, macOS arm64). It also affects Codex routed through the same hub, not only Claude.

Building on the two comments above: endpoint matching misses wrapper scripts, and auth.type isn't set for apiKeyHelper setups. So instead of inferring the link, let the provider instance config say which usage pool it draws from:

• In a provider instance's settings, when at least one CLIProxyAPI usage source is enabled, add a "Usage limits from" picker: This account (default, current behaviour) or one of the connected hubs.
• When a hub is chosen, the thread details card, the composer limits panel, and auto-resume/fallback use that hub's accounts for the instance's driver instead of the native probe. With several accounts in the pool, show the pooled windows the same way Usage → Limits does.
• Skip the native limits probe for that instance, or at least don't show its errors. That also removes the Codex JSON-RPC -32600 warning for proxied instances ([Bug]: Usage Limits shows Codex -32600 warnings for custom proxy providers without OpenAI auth #11873) and the misleading "This account has no subscription limits." tooltip on Claude.

This is explicit, works for env vars, apiKeyHelper, wrapper binaries and remote hubs alike, and doesn't guess which account a thread uses.

My setup: Claude via apiKeyHelper (claude auth status → api_key_helper, cached usageLimits.unavailable.reason: "unsupported"), Codex not logged in locally (probeFailed, "Codex could not read usage (JSON-RPC -32600)"), one cliproxy usage source on a Tailscale HTTPS host. claude 2.1.312, codex-cli 0.166.0, Node 24.22.1.

Posted by Claude Code (claude-opus-5-5) via T3 Code triage.

[PedroNavHur]

Same on 0.1.6-nightly.20261030.3917 with Claude pointed at a CLIProxyAPI hub through ANTHROPIC_BASE_URL in ~/.claude/settings.json, and the same hub added as a usage source.

I have a small fix on my fork, waiting on a maintainer's go-ahead before I open a PR: PedroNavHur/t3code@main...PedroNavHur:t3code:pedro/thread-limits-from-hub

What it does:

• When the selected instance has no usable limits of its own, the thread details card looks at the connected hubs. If exactly one hub account serves the instance's driver, the card shows that account's windows, and each row's tooltip says "From ".
• With no hub account, or several (on one hub or across hubs), the card keeps today's "Unavailable" row, since nothing tells it which account the thread spends.
• It doesn't depend on the endpoint, so it covers the wrapper-script and apiKeyHelper setups above.
• The change is limited to ThreadDetailsUsage.tsx plus a pure ThreadDetailsUsage.logic.ts with unit tests. collectProviderUsageLimits and the Limits page are unchanged.

Two questions on scope:

1. With several accounts in one hub, should the card show the pooled windows the way Usage → Limits does, or stay "Unavailable"?
2. Would you rather have the explicit per-instance "Usage limits from" setting suggested above instead of an inferred fallback?

Happy to open the PR in whichever shape you'd accept.

---

Posted by Claude Code (claude-opus-5-5) via T3 Code triage.

[PedroNavHur]

Note

Opus 5.5 (claude-opus-5-5) posting on behalf of Pedro.

Follow-up to my comment above: the fix is now open as #27740, so it can be read as a diff. It doesn't replace an approval here, and I'm happy to close it if you'd rather go another way.

What #27740 does:

• When the selected instance has no usable limits of its own (unsupported, or Codex's probeFailed), the thread details card falls back to a connected hub. Each row's tooltip says which hub the numbers come from.
• It only falls back when exactly one hub account matches the instance's driver, email, and workspace, and every hub could be read. With several candidate accounts, an ambiguous workspace, or a failed hub read, the card keeps today's notice.
• It doesn't match on the endpoint URL, so it also covers the apiKeyHelper and wrapper-script setups described above.
• Usage → Limits and the server don't change.

#27901 now proposes an explicit "clients route through this hub" flag on a usage source. That's the kind of explicit link suggested in the comments above, so the fallback could be gated on it instead of inferring the account.

Could a maintainer say which direction you want?

1. The fallback as it is in fix(web): thread details card shows a proxied instance's limits from its usage hub #27740.
2. The same fallback, but only for hubs with feat(usage): let a hub that clients route through supply their limits #27901's flag on.
3. Neither, for now.

I'll update or close #27740 to match.

---

Posted by Claude Code (claude-opus-5-5) via T3 Code triage.

[EhsanulHaqueSiam]

A data point for question 1, several accounts in one hub: stock CLIProxyAPI already records which account served each Claude Code session, so the card doesn't have to guess.

• GET /v0/management/usage-queue returns one record per proxied request. Each record has session_id (Claude Code's X-Claude-Code-Session-Id, normalized) and auth_index. auth_index also appears in /auth-files, which the hub source already reads.
• I checked this on a hub with two Claude accounts. The session_id from a claude -p run matched its queue record exactly, and its auth_index named the account that served it. A thread's nativeThreadRef.nativeId is that same session id, so the client already has the key.
• It needs usage-statistics-enabled: true on the hub (off by default upstream). It also needs session-affinity: true so a thread stays on one account; the CLIProxyAPI setup guide linked from the FAQ already turns that on.

Caveats:

• Reading the queue removes the records. There is no read-only HTTP endpoint, so this has to be opt-in per hub. Another reader of the same queue, such as a second T3 environment or CLIProxyAPI Home, would miss the records T3 took.
• Records are kept for 60 seconds by default, so the server has to read the queue at least once a minute while threads run.
• After a failover or when affinity expires, the binding can change. The card would show the latest account seen for the session.

This fits #27740 as the tie-breaker when several hub accounts match: pick the account whose recent sessions include the thread's session. It is read-only with respect to routing, so it stays clear of the account-switching concern in the FAQ. I'll put the server half (queue read and sessionIds on hub accounts) up against #27740's branch so it can be reviewed together.