[BUG] Rate limits blocking multi-agent Claude Code workflows even at highest paid tier

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/60562
2. https://github.com/anthropics/claude-code/issues/53922
3. https://github.com/anthropics/claude-code/issues/40273

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The distinction you draw — "Server is temporarily limiting requests (not your usage limit) · Rate limited" — is the important one and the one the documentation does not cover. Two structurally different limits with the same surface symptom (API Error):

1. Monthly usage budget (Max 5x / 20x quotas, cache_creation drift, what the Pro Max anomaly cluster tracks)
2. Infrastructure request-rate ceiling (concurrent parallel-instance throttle, what your error explicitly names)

These are independent. An operator can be at 12% of monthly budget and still hit (2) when running 5–6 parallel instances. The opaqueness you flag — the error doesn't say which limit, current consumption, or reset time — is what makes the two impossible to distinguish from the user side without proxying the API to inspect headers.
A few notes that may help while this is open:

• The duplicate-detection bot linked #60562, #53922, and #40273 above. If those are usage-budget rather than infrastructure-rate, they are not duplicates — the symptom is shared, the mechanism isn't. Worth flagging back to the bot so this issue stays distinct.
• The "multi-agent agentic coding is the emerging pattern" framing in your additional context is the structurally correct one: the Anthropic-side decision is whether infrastructure rate limits should scale with paid tier (your option 1), become transparent (option 2), or grow a parallel-agent-aware mode (option 3). Today's behavior — opaque + intermittent + uncorrelated with paid tier — is the worst of the four options you list. Worth making that explicit if the issue stays open without movement.

The error-path actionability ask (which limit / current / reset / what would help) is the lowest-cost concrete fix and the one that would unblock the most users in the shortest time.
---
Edit: removed an earlier paragraph suggesting a specific stagger interval (5–15s) and a token-bucket characterization of the ceiling. I had not verified either on a real account before posting and the limit's actual shape (per-second vs per-minute, per-account vs per-org) is what your issue is asking Anthropic to make transparent — so guessing at it here works against that ask.

I'm going to add that I am getting the same errors on workflows repeatedly which makes the tool essentially unusable as envisioned. I have to rate limit to 2 parallel workflows for now which is quite frankly ludicrous for a $200/m subscription. Only difference from the original poster is I'm on Mac and operating on iterm2.

I can confirm. Same problem with 20x Max Plan. Can't use workflows.

Chiming in with a few things that may be useful while this is open.

The distinction you draw between infrastructure request-rate limiting and monthly token/usage budget is the right one to keep sharp, and it keeps getting collapsed in Anthropic's public discussion. They are two separate ceilings. The error text ("not your usage limit") is the tell, and it is buried in a generic API error surface that gives you nothing actionable.

On the "what would help" front:

The most practical near-term ask is the one you list as option 3 in your issue: error responses that include which limit was hit, current consumption against that limit, and a reset timestamp. That alone would let operators build sensible backoff and retry logic instead of treating rate limit errors as noise to swallow.

Longer term, parallel-agent patterns are not going away. The tools that have emerged in the last several months (worktree fan-out, agent-view, background session management) all push toward running more instances, not fewer. Limits that do not scale with that usage pattern will become a harder and harder ceiling.

The 5-15s stagger that gets suggested in threads like this is a workaround, not a solution - and as yurukusa noted above it is based on guesswork about the actual shape of the ceiling. Until the limit's shape is documented (per-second vs per-minute, per-account vs per-org, what the actual ceiling is at each tier), any stagger interval is just a random retry interval with extra steps.

On the competitive point: the issue is real. Developers running parallel Claude Code fleets are making infrastructure choices, and opaque intermittent limits affect those choices.

The framing here is exactly right -- this is an infrastructure tier problem, not a token budget problem.

When you run 5-6 concurrent instances, each session independently replays its full system prompt and context on every turn. The request rate multiplier is roughly (concurrent_sessions turns_per_minute context_tokens_per_turn). At that scale, even caching doesn't fully absorb it because each session has a different cache key.

A few things that have helped with sustained multi-agent work:

• Staggering session starts by 30-60 seconds reduces the peak request burst
• Keeping per-session context minimal (lean CLAUDE.md, explicit task scoping) cuts per-turn token counts significantly
• Running agents in git worktrees means each session has a bounded working set rather than loading the whole project

None of these are real solutions -- they're friction management. The right fix is tier-aware rate limiting that accounts for multi-instance patterns, which requires Anthropic to instrument for it.

Disclosure: I'm building Claudiverse (claudeverse.ai), a session orchestration layer for Claude Code. Rate limit behavior across concurrent sessions is something we track closely.