Max 20x subscriber rate-limited within usage limits during Claude Code subagent orchestration (no early warning / no budget visibility)

Status Open
Maintainer reply None cached
Activity 3 comments · opened Jul 9, 2026

Summary

Claude Max 20x subscriber rate-limited during an extended Claude Code session while believing I was within my plan's usage limits, with no early warning that a cap was approaching.

Environment

  • Plan: Claude Max 20x
  • Client: Claude Code (model claude-fable-5)
  • Session type: long-running multi-phase build using heavy subagent orchestration

Usage pattern that triggered it

An extended build in Claude Code that repeatedly fanned out 3–6 concurrent Opus subagents (implementers + reviewers) per phase, running in the background, over several hours. Background subagents appear to draw concurrently from the same token pool as the main loop, so parallel orchestration multiplied consumption much faster than a single-threaded session — and the consumption was not visible anywhere before hitting the wall.

Expected behavior

As a Max 20x subscriber within usage limits, either:

  • (a) not be rate-limited at this usage, or
  • (b) get a clear, early signal of remaining budget and what is consuming it — especially given that parallel/background subagents make consumption opaque and non-obvious to pace against.

Actual behavior

Hit a rate limit mid-build with no prior warning; the active session stalled. (Work itself was preserved via git commits.)

Impact

Interrupted an active build/demo. The lack of visible budget/consumption for subagent fan-out made it impossible to pace usage before the limit.

Requests

  1. Confirm whether this rate-limit trip was correct for a Max 20x plan at this usage.
  2. If expected, surface subagent / parallel-agent token consumption and remaining budget in Claude Code so users can pace before hitting the limit (a running "budget remaining" + per-subagent consumption view).

View original on GitHub ↗

3 Comments

rithyD · 1 month ago

+1, same root cause, different symptom.

I hit this on Pro over the last two days: daily and weekly limits exhausted repeatedly, to the point I paid for extra credit top-ups expecting them to buy roughly a week of margin — each top-up instead burned down almost immediately, for comparatively little delivered work. I ended up switching to Max just to get a usage ceiling I could reason about, which isn't really a fix, just a bigger bucket for the same invisible leak.

Digging into my local session transcripts (~/.claude/projects/**/*.jsonl) after the fact, the driver was clearly subagent fan-out, matching what's described above:

  • 28 Explore/general-purpose subagents spawned in a single day across 3 sessions (13 in one session alone)
  • 3 single-session transcripts reaching 23 MB/6430 lines, 13 MB/4749 lines, 8.3 MB — i.e. long-running sessions that kept fanning out subagents rather than doing targeted lookups
  • No signal anywhere in the CLI, during the session or at top-up time, that this pattern was the cause — only visible by manually inspecting local transcript files after the money was already spent

Strongly agree with request (2): a running "budget remaining" + per-subagent consumption view would have let me stop or intervene long before hitting a limit or paying for a top-up that evaporated in minutes.
It would also help distinguish "expensive because the task is genuinely large" from "expensive because of avoidable cold-start subagent fan-out" (each subagent spawn re-derives context from scratch with no cache reuse from the parent session — that's a meaningful chunk of the cost by itself).

Edit: Pulled the full week (July 3–9) of local transcripts instead of just the single worst day, and the pattern is even clearer:

  • 93 session files that week, 97 MB total - 72 of those 93 are subagent spawns (Explore/general-purpose) — roughly

20 parent sessions produced 72 cold-start subagent spawns - Daily session-file count escalates sharply: 2 (Jul 3) → 15 (Jul 6) → 18 (Jul 7) → 20 (Jul 8) → 38 (Jul 9)

  • The spike on Jul 9 lines up exactly with the day I had to buy multiple same-day top-ups before switching plans — the subagent fan-out and the billing pain track each other almost 1:1 in my data.
rithyD · 1 month ago

Edit 2: Following up on this — I went through the support process to see if this could be addressed on a case-by-case basis, and the experience itself turned out to be a related but distinct problem worth flagging here.

  • Filed a request via the in-app chat (Fin AI Agent) on July 9. Got an automated policy denial, then an explicit promise of transfer to a human agent (case ID 215475029918272). No human response followed.
  • Reopened the chat 5 days later, explicitly asked for a human. Got a second "transferring you to a human agent" message (case ID 215475090656996).

Again, no human response followed.

  • Switched to emailing support@anthropic.com directly with the full writeup and invoices. Every single reply — including on email — came back signed "Cette réponse a été composée par Fin AI Agent, l'AI Agent de Anthropic."

At one point it stated outright that it "is not able to guarantee or promise further human review of this case."

  • When I pushed further, it pointed me to the article documenting Anthropic's DSA-designated point of contact for EU users (support.claude.com/.../point-de-contact-designe-pour-les-utilisateurs-de-l-ue).

That article states the designated contact point is the same in-app chat
tool
I'd already exhausted — so for EU users, the DSA contact point and
the automated billing bot are, in practice, the same dead end.

None of this changes the root cause already discussed in this thread (subagent fan-out with no cost visibility), but it compounds it: when that behavior generates a support case, the support path for EU users currently appears to be fully automated end-to-end, with no verifiable human touchpoint across two promised transfers and multiple channels. Flagging it here since it seems relevant to anyone else who ends up filing a related request because of this issue.

kcarriedo · 1 month ago

The subagent fan-out + no cost visibility combination is the worst failure mode in this class of workflows. You're right that these are two separate problems that compound each other: rate limiting during orchestration (the infrastructure ceiling) and no per-subagent spend breakdown (the visibility gap). The second makes the first impossible to diagnose in real time.

A few things that have helped when running scheduled multi-agent workloads (a coordinator that dispatches several Claude agents on a cron, similar shape to what you're describing):

On the rate limiting side: the only reliable workaround right now is to serialize rather than fully parallelize subagent fan-out. Running 3 parallel subagents with 2s staggered starts is meaningfully different from spawning all at once. Not ideal, but it moves the rate-limit collision from infrastructure ceiling to usage-budget ceiling, which is at least predictable.

On the visibility side: ccusage (https://github.com/ryoppippi/ccusage) parses the local .jsonl transcripts and gives per-session cost breakdowns after the fact. It does not solve the in-session budget awareness problem, but it does let you do a post-mortem on which subagent runs were expensive without manually reading raw JSONL.

The real ask here -- a running cost display during subagent orchestration, with a per-subagent breakdown -- has no good workaround today. The "no early warning / no budget visibility" framing in the title is the right one. Without that signal, the only way to manage cost in a multi-subagent run is to cap fan-out count at the orchestrator level and hope the individual subagents stay bounded.

The EU support routing failure you documented is a separate problem but worth flagging to a real human at Anthropic -- if you haven't already, the GitHub issue itself tends to get more traction than the support channels for technical billing issues like this one.

(Disclosure: I'm Kyle Carriedo, building Claudeverse -- claudeverse.ai -- which tracks session lifecycle and spend across Claude Code runs. The per-subagent cost visibility gap is something we're working on at the tooling layer while waiting for native support.)