[Bug]: Limits view merges one Claude login's separate organizations into a single bar #13674

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

1. Use one Claude login that belongs to two organizations, e.g. a personal Claude Max org and a company Claude Team org.
2. Add two Claude provider instances, each with its own CLAUDE_CONFIG_DIR, one signed in to each org. Settings → Providers shows both as authenticated (one "Claude Max Subscription", one "Claude Team Subscription"), same email.
3. Open Usage → Limits.

Expected behavior

Two bars, one per organization. Each org has its own session and weekly quotas and its own reset times.

Actual behavior

Only one bar is shown, under the first instance's display name. The second org's limits don't appear anywhere on the Limits view.

Both instances have correct data in their own caches (~/.t3/caches/claudeAgent*.json). The instance that's hidden was at 69% session, 81% weekly, and 98% Weekly · Fable used, with different reset times from the one that's shown. The view showed only the other org's 2% / 18% / 30%.

Cause: accountKey in packages/shared/src/usageLimits.ts:82 keys accounts by driver + email only:

function accountKey(driver: ServerProvider["driver"], email: string | undefined): string | null {
  const normalizedEmail = email?.trim().toLowerCase();
  return normalizedEmail ? `${driver}:${normalizedEmail}` : null;
}

collectLimitAccounts treats "same email" as "same quota bucket". For Claude, quotas belong to the organization, not the login. collectProviderUsageLimits, used by the composer, lists each native instance separately. But it uses the same key to match hub accounts and reset credits to native instances, so an org mix-up could happen there too.

Possible fix, for the maintainers to decide: add the organization to the key when the provider knows it. The Claude CLI config already has oauthAccount.organizationUuid, and claudeResetCredits.ts reads it. That would need an optional field on ServerProviderAuth. One open question: CLIProxy hub accounts only report an email, so they'd need a rule for matching native rows that do have an org.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Alpha) 0.0.42 desktop; code refs at main @ e5a46d6

Environment

macOS 27.0, Claude Code 2.1.282, two Claude instances (Max + Team) on one machine

Workaround

The composer's per-instance limits popover still shows the hidden org's usage. You can also run /usage in Claude Code with that instance's CLAUDE_CONFIG_DIR.