[BUG] Rate limited (429) only when ~6+ desktop sessions are active at once, while plan usage reads 26-27% — began ~2026-09-16

What's wrong

Several Claude Code desktop sessions open at the same time (each a separate project) now hit
429 Rate limited and retry up to 10 times, and sometimes end the turn with a rate-limit error.
I saw none on 2026-09-14 or 09-15, the earliest days I analyzed, at similar concurrency. Plan usage
is nowhere near a limit, so it doesn't look like the 5-hour or weekly window.

Numbers (Max plan, claude-desktop entrypoint, version 2.1.280)

One oddity: the in-app get_usage readout labels this account's plan "Pro", but it is a Max
subscription. I can't tell which of the two the rate limiter is applying.

On 2026-09-24 I counted 195 system/api_error transcript records with status: 429,
error.type: rate_limit_error, message "Rate limited", rateLimits: null, retryAttempt up to
maxRetries: 10, plus 7 turns that ended on a rate-limit error message. When I checked later
that day, get_usage reported:

| window | used |
|---|---|
| 5-hour | 27% |
| Weekly, all models | 26% |
| Extra usage | off, $0.00 spent |

So this is not the plan quota running out.

I bucketed every session-minute since 2026-09-14 by how many sessions had any transcript activity in
that same minute, and counted minutes containing a 429:

| sessions active that minute | session-minutes | minutes with a 429 |
|---|---|---|
| 1 | 342 | 1 (0.3%) |
| 2 | 244 | 0 (0.0%) |
| 3 | 321 | 2 (0.6%) |
| 4 | 220 | 1 (0.5%) |
| 5 | 180 | 4 (2.2%) |
| 6 or more | 798 | 114 (14.3%) |

And it isn't simply "six sessions is always bad." Sessions at 6+ concurrent with zero 429s on
2026-09-14 (0 of 259) and 2026-09-15 (0 of 77), then 33/269 on 09-16, 17/74 on 09-21, 10/19 on
09-23 and 54/108 on 09-24. Similar concurrency, very different result from 09-16 on.

Not established (so nobody has to guess)

• Concurrency vs. throughput is not separated. Busy periods have both more sessions and more

tokens. I tried splitting the 6+ minutes by tokens per minute and got 18% / 1% / 24% across
terciles, which is non-monotonic and biased anyway: a minute full of failed requests produces
almost no tokens.

• "Active" means any transcript record in that minute, not a request in flight.
• This is one account, one machine.
• I'm not claiming a cause or that this is unintended.

What would help

1. Say which limit fired. rateLimits is null and the message is just "Rate limited", so there's

no way to tell a per-minute request cap from a concurrency cap from an overloaded backend.

1. If there is a cap on simultaneous sessions or requests per account, document it per plan, and

say why a Max account's readout shows "Pro".

1. If it's new as of ~2026-09-16, a note saying so would save people debugging their own setup.

Related but different mechanism: #77591, #92534.