Claude Code becomes nearly unusable (60s+ latency) with multiple concurrent sessions on one account

What happens

Claude Code becomes nearly unusable to work with interactively — responses stall for tens of seconds, with one measured turn taking 61 seconds to first token. Other turns ran 8–17s. This makes interactive work impractical.

Environment

• Claude Code: 2.1.186
• macOS, Apple M5 (10-core)
• Network to api.anthropic.com: ~5ms RTT, 0% packet loss
• CPU load: ~3.2 on 10 cores (~32%, not saturated)

What I ruled out

Local investigation shows it is not the network (5ms) and not a saturated machine (~32% CPU). The daemon log and policy limits are clean.

Likely trigger

6 interactive claude sessions were running simultaneously under the same account (several idle for 30–46 min). They appear to share one API rate/concurrency budget, and request stalls line up with periods of concurrent activity.

Measured latency (from session transcript timestamps)

| user → first assistant token | gap |
|---|---|
| turn A | 61.0s |
| other turns | 8–17s |

Additional factor

4 MCP servers (notion, linear-server, claude.ai Google Drive, Sentry) are stuck auth-pending and reload a large tool catalog on every session start, adding per-turn prompt overhead.

Expected

Concurrent sessions on one account should not degrade each other to 60s+ latency, or there should be clearer feedback when account-level throttling is occurring.