[BUG] 5-hour usage limit for one Team account is consumed by activity in a different Team account (server-side accounting bug, not client-specific)

[den2207]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When I'm signed into multiple Team accounts (e.g. Team A and Team B), the 5-hour rolling usage window for Team B keeps being consumed even though I'm not actively using Team B — I only opened a chat there once and sent a single message, then went back to working exclusively in Team A. The usage limit for Team B still ticks down as if it were being actively used.

This happens regardless of client — reproduced both in the Claude Desktop app and via Claude Code CLI — which points to the usage-window accounting being wrong on the backend, not a client-side bug.

This also happens across two separate physical machines: if one client is open and signed into Team A on one laptop, and another client is open and signed into Team B on a second laptop, working only under Team A still consumes usage from Team B's 5-hour limit.

What Should Happen?

The 5-hour usage limit for a Team account should only be consumed by requests actually made under that account. Leaving a chat/session open under Team B (without sending further messages) should not draw down Team B's limit while I'm actively working under Team A.

Error Messages/Logs

this is a usage/limit accounting issue, not a crash or visible error.

Steps to Reproduce

1. Sign into Claude Code CLI with Team B account, send one simple message (e.g. "hi").
2. Without closing that CLI session, sign into the Claude Desktop app with Team A account and start actively working there for an extended period (both clients open/signed-in simultaneously, on the same or different machines).
3. Check the 5-hour usage window/limit for Team B — it continues to accrue/count down even though no further activity happened under Team B after step 1, all the actual work was done under Team A in the other client.

Additional repro: same result when Team A and Team B are each open in a separate Desktop app instance on two different machines — working only on the Team A machine still consumes Team B's limit.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

• Reproduced with multiple Team accounts under the same login.
• Reproduced both within a single machine (two sessions in one Desktop app) and across two separate machines (one Team account signed in per machine).
• Suspected cause (unconfirmed): usage-window accounting may be tied to a shared session/device identifier or a background keep-alive process rather than to the specific account actually receiving requests.

[daniil-k-headway-inc]

+1

[kcarriedo]

The cross-account usage bleed you're describing -- Team B's 5-hour window ticking down while you're only active in Team A -- points to the usage-window accounting being keyed to something shared across accounts (device ID, auth session token, or a background keepalive process) rather than to the specific account that actually made requests.

The cross-machine repro is the most telling detail. If two separate laptops, each signed into a different Team account, both draw from Team B's limit while only one is active, the accounting signal has to be coming from something that both machines share -- most likely a per-user or per-subscription identifier that gets attached to background keepalive or heartbeat traffic, not just to actual requests.

A few things worth checking while waiting for a fix:

• Is there a background daemon or desktop process running for Team B on the "inactive" machine? Killing it (not just closing the CLI) might stop the drain.
• Does signing out of Team B completely (not just switching to Team A) stop it?

This matters beyond just billing fairness -- for anyone running multiple Claude Code deployments across teams or projects, it makes per-team cost attribution unreliable. You can't tell from the limit counter whether Team B was actually used or just bled.