Rate limit quota is shared per organizationUuid, not per account

[dancinlife]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

Rate limit quota is pooled at the organization level (organizationUuid), not per-account. All accounts sharing the same organizationUuid consume from a single quota pool — using one account exhausts the limit for all others in the same organization.

Root cause: claude login does not clear the oauthAccount field in .claude.json, causing cross-contamination of account UUIDs across config directories. These leaked UUIDs are likely sent to the backend and trigger org-level grouping. See detailed analysis in the comment below.

cc @dliedke

Evidence

I'm on the Max plan ($200/mo) and checked my accounts via the OAuth usage API (/api/oauth/usage) and local config (oauthAccount.organizationUuid in .claude.json):

organizationUuid	Accounts	Session	Weekly	Behavior
34d83544-a7e...	Account A, B, C, D, E	100% (identical)	83% (identical)	Shared — same utilization & reset times
1b8fb384-9be...	Account F	0%	100%	Independent
c2b1b50a-454...	Account G	0%	100%	Independent
1d6df450-33f...	Account H	0%	100%	Independent

• Accounts under the same org show identical utilization percentages and reset times
• Accounts under different orgs have fully independent quotas
• Billing method and phone number are not the grouping factor (verified: different cards and phone numbers within the same org group)

What Should Happen?

Each Max subscription account should have its own independent rate limit quota. Per-organization pooling is unexpected and undocumented — users paying for separate subscriptions will find them silently linked if they end up in the same organization.

At minimum, this behavior should be clearly documented so users understand what they're paying for.

How to Check Your Own Grouping

# Check organizationUuid in your config:
python3 -c "import json; d=json.load(open('$HOME/.claude/.claude.json')); print(d['oauthAccount']['organizationUuid'])"

# Or check the API response header 'anthropic-organization-id'

Related Issues

• Accounts on the same billing method share a single rate limit quota pool #41881 (closing — superseded by this issue)
• Max 20 plan: rate limit 100% exhausted within ~70 minutes after reset (never happened before v2.1.89) #41788 — Max 20 plan: rate limit 100% exhausted within ~70 minutes
• New account immediately hits rate limit with zero usage #41590 — New account immediately hits rate limit with zero usage
• [BUG] Claude Max plan session limits exhausted abnormally fast since March 23, 2026 (CLI usage) #38335, [BUG] Extremely rapid token consumption. There appears to be a critical issue with token calculation and quota management. Users, including myself, are experiencing an unusually high rate of token consumption #38239, [Bug] Prompt Cache causes excessive token consumption (10-20x inflation) #41663, [BUG] claude code - Usage Limits Show 0% Daily But 41% Weekly, Rate Limited Despite No Activity — Phantom Usage Consuming Paid Max 20x Quota #41084 — Various rate limit reports

Claude Code Version

2.1.89

[dancinlife]

Root Cause Investigation — .claude.json cross-contamination

I did a deep dive into the local config files across multiple accounts on the same machine (Max $200/mo plan). The findings suggest a client-side bug in claude login that may be contributing to (or causing) the org-level grouping.

1. oauthAccount in .claude.json is not refreshed on login

When running CLAUDE_CONFIG_DIR=~/.claude-acct{N} claude login for a new account, the oauthAccount field in .claude.json retains the previous account's data instead of being overwritten.

Account	Actual email	oauthAccount.email in .claude.json	Contaminated?
Acct 1	user-a@gmail.com	user-a@gmail.com	✅ Clean
Acct 2	user-b@proton.me	user-b@proton.me	✅ Clean
Acct 3	user-c@proton.me	user-c@proton.me	✅ Clean
Acct 4	user-d@proton.me	user-a@gmail.com	❌ Has Acct 1's data
Acct 5	user-e@proton.me	user-d@proton.me	❌ Has Acct 4's data
Acct 6	user-f@proton.me	user-d@proton.me	❌ Has Acct 4's data
Acct 7	user-g@proton.me	user-e@proton.me	❌ Has Acct 5's data
Acct 8	user-h@proton.me	user-d@proton.me	❌ Has Acct 4's data

Pattern: The previous account's oauthAccount persists into the next account's config. claude login either doesn't clear this field or writes the OAuth token without updating the cached account metadata.

2. Cache fields accumulate UUIDs from other accounts

Three cache fields in .claude.json accumulate accountUuid/orgUuid values from multiple accounts over time:

• groveConfigCache
• passesEligibilityCache
• overageCreditGrantCache

These caches are keyed by UUID but never scoped to the current account, so entries from previous sessions with different accounts pile up. Some configs had 5–6 foreign UUIDs accumulated.

3. What IS safe to share across config dirs

File/Dir	Contains account identity?	Safe to symlink?
settings.json	No (permissions/plugins only)	✅ Yes
projects/	Yes (session .jsonl files)	❌ No
.claude.json	Yes (oauthAccount, caches)	❌ No
Keychain OAuth token	No orgUuid/accountUuid	✅ (isolated by label)

4. Hypothesis

The contaminated oauthAccount data and leaked UUIDs in cache fields are sent to Anthropic's backend during normal API calls. The server sees multiple accountUuid values originating from the same client and groups them into a single organizationUuid, pooling their rate limits.

Even after cleaning all local contamination (resetting caches, deleting stale oauthAccount entries, separating projects/ directories), the server-side org grouping persists — suggesting the association is permanent once established.

5. Suggested fixes

1. claude login should clear oauthAccount and all account-scoped caches in .claude.json before writing new credentials
2. Cache fields should be scoped to the current accountUuid — stale entries from other accounts should not accumulate
3. Document that CLAUDE_CONFIG_DIR directories must not share .claude.json or projects/

6. Reproduction

# 1. Login as account A
CLAUDE_CONFIG_DIR=~/.claude-acctA claude login
# → .claude.json gets oauthAccount for A

# 2. Login as account B using a NEW config dir that was copied/templated
CLAUDE_CONFIG_DIR=~/.claude-acctB claude login  
# → .claude.json may still contain oauthAccount for A

# 3. Check contamination
python3 -c "import json; d=json.load(open('$HOME/.claude-acctB/.claude.json')); print(d.get('oauthAccount',{}).get('email','clean'))"

[dancinlife]

@dliedke TL;DR: claude login doesn't clear/refresh the oauthAccount field in .claude.json. When using separate CLAUDE_CONFIG_DIR directories, the previous account's accountUuid and email persist into the new config — causing cross-contamination that likely triggers server-side org grouping and shared rate limits.

Suggested fix: claude login should wipe oauthAccount and all account-scoped caches (groveConfigCache, passesEligibilityCache, overageCreditGrantCache) before writing new credentials.

[dancinlife]

Workaround — Automated contamination detection & cleanup

We built a tool (fix-oauth) that automatically detects and cleans oauthAccount contamination across config directories. Here's the approach:

Detection

Scan all .claude.json files across config dirs. If two accounts share the same accountUuid, the later one is contaminated:

# Simplified detection logic
for account in accounts:
    oauth = read_json(f"~/.claude-{account}/.claude.json").get("oauthAccount")
    uuid = oauth.get("accountUuid")
    if uuid in seen:
        print(f"{account} contaminated by {seen[uuid]}")
    else:
        seen[uuid] = account

Cleanup

For each contaminated account, remove these fields from .claude.json:

keys_to_remove = [
    "oauthAccount",           # the contaminated identity
    "groveConfigCache",       # accumulated foreign UUIDs
    "passesEligibilityCache", # accumulated foreign UUIDs  
    "overageCreditGrantCache", # accumulated foreign UUIDs
]

Then delete the keychain credential to force a fresh browser login:

security delete-generic-password -l "Claude Code-credentials-XXXXXXXX"

After cleanup, re-login populates .claude.json with the correct account data.

Prevention

We run the contamination scan automatically at launcher startup — if any account is contaminated, it's cleaned and the user is prompted to re-login before launching Claude Code.

Important caveat

As noted in the root cause analysis above: server-side org grouping may persist even after cleaning local contamination. This fix prevents future contamination but cannot undo org associations already established on Anthropic's backend. New accounts created after cleanup should remain independent.

Full contamination scenario matrix

For anyone running multi-account setups, here's every contamination vector we've encountered:

#	Scenario	Risk	Mitigation
1	claude login doesn't clear oauthAccount	❌ Root cause	Clean before login: remove oauthAccount + caches
2	Cache fields accumulate foreign UUIDs	❌ Amplifies #1	Remove groveConfigCache, passesEligibilityCache, overageCreditGrantCache
3	Sharing .claude.json across config dirs	❌ Dangerous	Never symlink .claude.json — only settings.json is safe
4	Symlinking entire projects/ directory	❌ Dangerous	Use per-project memory/ symlinks instead (for shared context)
5	Env file sharing across terminal tabs	🔧 Fixed	PID-scoped env files (~/.claude-env-{PID})
6	Sourcing last-used env in .zshrc	❌ Dangerous	Every new shell inherits last account → cross-tab contamination

If anyone wants the full detection/cleanup scripts, let me know.

[dancinlife]

Multi-Account Rotation — full workaround for rate limit exhaustion

Beyond the contamination fix above, here's the complete system we use to work around rate limits.

How It Works

Isolate each account via CLAUDE_CONFIG_DIR into separate config directories:

~/.claude-claude1/    # Account 1
~/.claude-claude2/    # Account 2
~/.claude-claude3/    # Account 3
...

When one account's tokens are exhausted → copy session files to the next account → resume with --resume. Project memory is shared via per-project symlinks so context survives account switches.

Components

• Account isolation: Separate config dirs via CLAUDE_CONFIG_DIR
• Session continuity: switch-account.sh — copies session files + subagent dirs to new account, resumes with --resume
• Shared memory: sync-memory.py — per project, picks the account with the most memory files as canonical, symlinks the rest
• Contamination prevention: fix-oauth auto-scan at launcher startup (see comment above) + PID-scoped env files (~/.claude-env-{PID}) for tab isolation
• Usage monitoring: Real-time per-account usage dashboard via keychain token extraction + Anthropic OAuth usage API

Why this matters for org-grouping (#41886)

Once accounts are grouped server-side by organizationUuid, rotation across those accounts is useless — they share the same quota pool. The contamination fix above prevents future grouping, and rotation only helps across accounts in different org groups.

Our current setup after cleanup:

• Accounts with independent organizationUuid → rotation works, each has its own quota
• Accounts already grouped → effectively one account, rotation pointless

This is complementary to @ArkNill's cache analysis — fixing cache helps each account/org last longer, contamination cleanup keeps orgs separate, and rotation handles remaining exhaustion.

If you want the scripts, let me know.

[dancinlife]

Full operational report — how we identified contamination vectors and built mitigations

@dliedke Here's what we discovered running 9 MAX accounts with real-time monitoring, and how we fixed each contamination vector.

What we discovered through multi-account monitoring

By watching utilization patterns across 9 accounts simultaneously via the OAuth usage API, we identified that claude login doesn't clear oauthAccount in .claude.json. The previous account's accountUuid persists into the new config, causing:

1. Server-side org grouping (this issue) — accounts sharing leaked UUIDs get pooled into one rate limit
2. Cache field accumulation — groveConfigCache, passesEligibilityCache, overageCreditGrantCache pile up foreign UUIDs over time

Every contamination vector we've mapped

#	Vector	Risk	Our fix
1	claude login not clearing oauthAccount	❌ Root cause of org-grouping	Auto-clean oauthAccount + 3 cache fields before login
2	Cache fields accumulate foreign UUIDs	❌ Amplifies #1	Remove groveConfigCache, passesEligibilityCache, overageCreditGrantCache
3	Sharing .claude.json across config dirs	❌ Dangerous	Never symlink — only settings.json is safe
4	Symlinking entire projects/ directory	❌ Dangerous	Per-project memory/ symlinks only
5	Env file sharing across terminal tabs	🔧 Fixed	PID-scoped env files (~/.claude-env-{PID})
6	Sourcing last-used env in .zshrc	❌ Dangerous	Every new shell inherits last account → cross-tab contamination

Automated detection & cleanup

We run contamination scans at launcher startup. Detection logic:

# If two accounts share the same accountUuid, the later one is contaminated
for account in accounts:
    uuid = read_json(f"~/.claude-{account}/.claude.json")["oauthAccount"]["accountUuid"]
    if uuid in seen:
        mark_contaminated(account, contaminated_by=seen[uuid])
    else:
        seen[uuid] = account

Cleanup removes 4 fields from .claude.json + deletes keychain credential to force fresh browser login:

keys_to_remove = ["oauthAccount", "groveConfigCache", "passesEligibilityCache", "overageCreditGrantCache"]

Critical caveat

Server-side org grouping persists even after local cleanup. This fix prevents future contamination but cannot undo associations already established on Anthropic's backend. New accounts created after cleanup remain independent.

Remaining bugs after v2.1.91 cache fix

Cache regression is fixed (95-99% read restored), but 4 bugs still affect rate limits:

• [BUG] Client-side rate limiter blocks requests with zero API calls when conversation transcript is large (~74MB) — false rate_limit error with synthetic model and 0 input/output tokens #40584 — False rate limiter — client blocks calls without server involvement
• [BUG] Silent context degradation — tool results cleared without notification on 1M context sessions this issue documents three separate mechanisms (microcompact, cached microcompact, session memory compact) #42542 — Silent microcompact clears tool results, forcing token-consuming re-reads
• Extended thinking generates duplicate .jsonl log entries with identical input tokens, causing ~2-3x token inflation in usage tracking #41346 — JSONL log duplication (2-3x PRELIM entries from extended thinking)
• Tool result 200K cap — maxResultSizeChars fix is MCP-only, built-in tools unaffected

Full measured data: claude-code-cache-analysis

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.