Accounts on the same billing method share a single rate limit quota pool
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
Accounts sharing the same billing method have their usage quotas linked server-side, causing all accounts under the same payment method to hit rate limits simultaneously — even if only one account is actively being used.
Evidence from the OAuth usage API (/api/oauth/usage):
| Accounts | Session | Weekly | Reset Times | Extra Usage |
|----------|---------|--------|-------------|-------------|
| claude1, claude5, claude6, claude7 | 100% (identical) | 83% (identical) | Same reset times | Same |
| claude4, claude8 | 0% session | 100% weekly | Same reset times | used_credits: 63299, utilization: 31.65% (identical) |
| claude2, claude3 | Independent | Independent | Different reset times | Independent |
- Accounts 1/5/6/7 are on the same billing method → identical utilization and reset times
- Accounts 4/8 are on another shared billing method → identical
extra_usagedata and reset times - Accounts 2/3 are on separate billing → fully independent quotas
What Should Happen?
Each account's rate limit should be tracked independently, regardless of the billing method. A Max subscription is per-account, so the quota should be per-account as well. Sharing a quota pool across accounts that happen to use the same credit card is unexpected and undocumented behavior.
Related Issues
- #41788 — Max 20 plan: rate limit 100% exhausted within ~70 minutes
- #41590 — New account immediately hits rate limit with zero usage
- #38335, #38239, #41663, #41084 — Various rate limit reports
How to Reproduce
- Create multiple Claude Max accounts using the same billing method
- Use only one account actively
- Check
/api/oauth/usageon the other accounts — they will show the same utilization percentages and reset times
Claude Code Version
2.1.89
5 Comments
Correction: After double-checking, one of the accounts in the first group (claude1/5/6/7) is actually on a separate credit card from the others. So the shared quota grouping may not be based on billing method alone.
Other possible grouping criteria:
The core finding still stands — accounts are clearly grouped and share quota pools — but the exact mechanism for grouping needs further investigation.
Additional data point: the phone numbers used for signup are all different across accounts. So phone number is also ruled out as the grouping criterion.
Remaining candidates:
Root cause identified:
organizationUuidis the grouping key for shared quota.Dug into the local config files (
.claude.json→oauthAccount.organizationUuid) and API response headers (anthropic-organization-id):| organizationUuid | Accounts | Quota behavior |
|-----------------|----------|----------------|
|
34d83544-a7e...| claude1, claude5, claude6, claude7, claude8 | All share the same session/weekly utilization ||
1b8fb384-9be...| claude4 | Independent ||
c2b1b50a-454...| claude2 | Independent ||
1d6df450-33f...| claude3 | Independent |Accounts under the same
organizationUuidshow identical utilization percentages and reset times via/api/oauth/usage. Accounts with differentorganizationUuidhave fully independent quotas.So the rate limit pool is per-organization, not per-account. This is likely by design but is undocumented — users who create multiple accounts expecting independent quotas will find them linked if the accounts end up under the same organization.
How to check your own grouping:
Superseded by #41886 — root cause identified as organizationUuid-based quota pooling, not billing method.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.