[BUG] Sonnet 5 issues 1000 agents suddenly and burned 13M tokens for no reason
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
I asked it to simply code some text, but for some reason it catastrophicly failed. it read per character instead of array then it summons 1000 agents for now reason
claude-code-workflow-bug-report.md
What Should Happen?
it should fEither (a) the platform detects that args was received as a raw string when the script's usage pattern clearly expects an object/array, and fails the call immediately with a clear diagnostic (e.g. "args was passed as a JSON string, not a parsed value — did you mean to pass an object/array directly?"), or (b) at minimum, a workflow that fans out to a number of agent()/parallel() calls far beyond the platform's own stated default guideline (this session's config said "keep workflows under 15 agents") should hard-stop with a warning instead of silently proceeding to spawn thousands of agents. Separately, a workflow racking up a long unbroken run of consecutive agent failures (e.g. "session limit" errors, which are non-retryable within the session) should stop scheduling further calls rather than continuing to the full 1000-call cap. And the completion <summary> line should reflect a catastrophic error rate (e.g. "completed — 800/1000 agent calls errored") instead of reading identically to a healthy run.ix the bug at least if it should think that summoning 1000 agents is suspicious
Error Messages/Logs
agent_count: 1000, agents_done: 200, agents_error: 800, agents_skipped: 0, agents_empty_result: 0
subagent_tokens: 13,300,136, tool_uses: 3,926, duration_ms: 6,883,157 (~115 min)
[discover:0] blocked by safety classifier: Stage 2 classifier error - blocking based on stage 1 assessment
[discover:20]/[discover:21] handed row-id lists ["e"] / ["x"] — not real ids, flagged back by the sub-agent
[discover:206] ... [discover:999] failed: You've hit your session limit · resets 6:30pm (Asia/Tokyo)
parallel[1000] ... parallel[3824]+ failed: Workflow agent() call cap reached (1000). This usually means a
loop using budget.remaining() never terminates because no token budget was set — remaining() returns
Infinity when budget.total is null. Add a hard iteration cap to the loop, or pass a token budget.Steps to Reproduce
const groups = Object.entries(args)
const results = await parallel(
groups.map(([name, ids]) => async () => {
return await agent(Your row ids (${ids.length}): ${JSON.stringify(ids)}, { label: 'discover:' + name })
}),
)
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.219
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Windows Terminal
Additional Information
_No response_
3 Comments
That 1000-agent fan-out from a string-vs-array args mixup is a nasty failure mode.
A few stopgaps that have helped on my side while the platform still accepts bad tool args:
The attached workflow report is the clearest "platform must reject bad args before agent explosion" writeup I've seen this week. If you still have the session log of the first bad tool call (the string args), that single line is usually enough to reproduce.
Adding a related Billing Platform / cost-control signal, kept public-safe.
This report is a concrete version of a paid-customer risk that should not be treated as a normal usage event: a malformed or misinterpreted workflow input can fan out into hundreds or thousands of agent calls, burn paid quota / usage-credit budget, then report a completion shape that hides the catastrophic failure rate.
My direct unresolved case is on a different Claude billing surface: manual prepaid / bulk usage-credit purchases fail or fail to commit cleanly while automatic usage-credit reloads on the same paid billing setup continue charging successfully. The common owner boundary is the same: product runtime state, credit / allocation debits, support-visible account state, and customer remediation policy are not reconciled end-to-end.
Requested triage path: please route this issue family to a human Billing Platform / cost-control / agent-runtime owner with authority to inspect bad-args validation, agent fanout limits, non-retryable session-limit handling, token / credit debits, workflow completion semantics, and credit/cap restoration policy together.
Concrete guardrails that would protect paid users:
Public, privacy-sanitized evidence hub for the related billing case:
https://coolak.github.io/anthropic-claude-billing-incident/
Billing reconciliation matrix / owner map:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html
I am intentionally not posting card details, bank names, private payment IDs, invoice IDs, support IDs, raw logs, screenshots, payment URLs, one-time codes, token values, or private support-thread text here.
The string-parsed-as-array -> 1000 agent fan-out is a specific instance of a wider problem: there is no control plane between "Claude decides to spawn agents" and "agents start consuming tokens." The validation and cap enforcement happen too late (or not at all when the root cause is a malformed argument).
A few things that would address the surface area of this report:
I build tooling for managing parallel Claude Code sessions and this failure mode (accidental fan-out due to malformed or misinterpreted tool input) comes up repeatedly. The cost asymmetry is severe: a single bad argument can cost more than a week of normal usage in under 4 minutes.
Disclosure: I build Claudiverse (https://claudiverse.ai), which addresses the monitoring side of this - but the pre-spawn validation is squarely a platform fix that should live upstream.