[BUG] Usage immediately jumps to 100% after switching to it (having been using another account)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
This may be a dupe of https://github.com/anthropics/claude-code/issues/5001 and https://github.com/anthropics/claude-code/issues/3857, but both got closed (hilariously saying each is a dupe of the other, not leaving either open)
- I use Opus 1m context on some claude terminals, on one of my accounts (it's a company Teams account)
- I run out of usage (reach 100%), my terminals stop with "hit limit" type error so I logout using one of the terminals
- I login using my personal Max account (it has 0% usage, it's a fresh session)
- On the other terminals I just say "carry on", and they carry on with the tasks
- They all immediately stop and say "hit limit" again! Usage for my personal account reaches 100% instantly!
Now, this did not used to happen I remember I time I could easily do this, it used to work perfectly, I'd hit my limit on one account so switch to the other - no problems.
The timing of this bug exactly started at the exact same time as: https://github.com/anthropics/claude-code/issues/39841. I think the two bugs are related (or just correspond to the same release).
What Should Happen?
Usage doesn't immediately hit 100% after switching accounts
Error Messages/Logs
Steps to Reproduce
- I use Opus 1m context on some claude terminals, on one of my accounts (it's a company Teams account)
- I run out of usage (reach 100%), my terminals stop with "hit limit" type error so I logout using one of the terminals
- I login using my personal Max account (it has 0% usage, it's a fresh session)
- On the other terminals I just say "carry on", and they carry on with the tasks
- They all immediately stop and say "hit limit" again! Usage for my personal account reaches 100% instantly!
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.114 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
If switching from an exhausted account to a fresh one causes the new account to jump straight to 100%, that is a severe account-boundary failure. The whole point of account switching is that billing/usage state should follow the authenticated account, not leak or be inherited from the prior one.
The especially important detail here is the historical comparison: the user says this workflow used to work and then regressed around the same time as another usage/account bug. That makes this feel much more like a state-isolation regression than simple confusion about limits.
From the operator perspective, this is scary because it suggests one of two bad possibilities:
Either way, the product is breaking a fundamental control-plane invariant: account identity should cleanly determine usage state.
I just did a test, where I switched accounts and started a completely fresh prompt (no previous context, no previous sessions), and my usage doesn't immediately shoot up to 100%.
A VERY aggressive prompt, and letting it spawn half a dozen agents does make it use my allowance very quickly, like I can make it burn through 50% in 15 mins, BUT no where near 100% in just a few seconds.
So I don't think switching the 4 terminal's context straight over to the other account is the problem ...
It might be related to me switching to the Basic plan and just not realising how incredibly nerfed that is.
Basic doesn't have Opus 1M context, so I think when I switch from one account to the Basic one, the Basic one's usage gets "BROKEN" by the existing Opus 1M context from the other account.
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.