[FEATURE] Make the billing identity (account/org) visible and attribute all limit messages to it
Status Open
Reported on v2.1.202
Maintainer reply None cached
Activity 1 comment · opened Jul 16, 2026
Problem
On a machine with several Claude identities (Enterprise seat + personal subscription + a claude setup-token), Claude Code gives the user almost no way to tell which account a session is billing to, and actively misattributes usage information. Concretely (Claude Code 2.1.202, macOS):
- No identity in the UI. The only artifact is the footer suffix "… · Claude API" (env token) vs "… · Claude Enterprise" (keychain login). No email, no org name. "Claude API" for a subscription setup-token is itself misleading — nothing is billed to a Console API key.
- Limit messages are unattributed and cross-contaminated. Usage toasts ("99% of usage used until Aug 1") and the statusline
rate_limitsreflect machine-shared state from the keychain account even in sessions billed to a different account viaCLAUDE_CODE_OAUTH_TOKEN(#68772). When the hard stop finally came —You've hit your org's monthly spend limit · ask your admin to raise it at claude.ai/settings/usage— the message did not say which org. With three identities on the machine the user has to reverse-engineer response headers to find out whose limit fired.
- Identity can change mid-session with zero indication. Running
/logininto a different account silently re-points all live sessions (credentials are re-read per request): a long-running session started under the Enterprise seat continues under the personal account after re-login. Combined with (1) there is no way to notice.
- A setup-token session cannot even resolve its own identity. The token lacks
user:profile(/api/oauth/profile→ 403) and/api/oauth/usagereturns 429, so the client falls back to showing another account's cached data instead of saying "unknown".claude auth statuswith the env token set prints a single line —Auth token: CLAUDE_CODE_OAUTH_TOKEN— with no email/org and no validity check, which reads as "not working" even when the token is fine.
- Credential sanitization + silent fallback = nested invocations switch accounts. Claude Code strips
CLAUDE_CODE_OAUTH_TOKENfrom the environment of its child processes (verified for statusline and Bash-tool commands: a child running[ -n "$CLAUDE_CODE_OAUTH_TOKEN" ]sees it absent, while custom vars pass through). Sanitizing credentials is sound, but combined with the silent keychain fallback it means any nestedclaudeinvocation (scripts,!commands, automation launched from a token session) quietly bills the keychain account instead of the session's account. Either warn on fallback or give children a way to keep the parent's billing identity.
- Setup-token consumption is invisible on claude.ai too. Inference through a setup-token demonstrably consumes the account's shared 5h/7d buckets (the
anthropic-ratelimit-unified-7d-utilizationheader ticks up with each call), but this consumption does not visibly surface in the claude.ai Usage UI, so the account owner can't see what is draining their limits. The only way I found to even identify which account a token bills to is to compare the unified reset epochs from response headers against the reset times shown on each candidate account's usage page.
Why it matters
Mixed corp/personal machines are a legitimate, compliance-relevant setup: open-source contributions must run on the personal subscription, work on the Enterprise seat. Today the user cannot audit that separation from the product UI at all — and the wrong-account toasts give exactly inverted signals about which account is near its limit.
Proposal
- Show account email + org name (and billing source: keychain login vs
CLAUDE_CODE_OAUTH_TOKENvs API key) in/status,/usage, and optionally the footer. - Attribute every limit toast/error to its account/org: "Salmon (Enterprise) monthly spend limit reached", not "your org".
- Key all client-side usage caches (
rate_limits, toasts, telemetryaccount_uuid) to the active credential, not to machine-shared state (#68772); show "usage unavailable for this token" rather than another account's numbers. - Warn in live sessions when
/loginelsewhere changes the effective identity, or pin a session to the credential it started with. - Give setup-tokens a scope that allows resolving their own account email/org (or embed a label at mint time), so sessions can self-identify.
Environment
- Claude Code 2.1.202, macOS (native install)
- Related: #68772 (cross-account rate-limit display), #70124 (precedence/attribution confusion), #76346 (enforcement vs displayed usage divergence), #30031 (multi-account switching)
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗