Claude Can Now Command 1,000 Agents at Once, But Watch Your Token Spend
Anthropic gave Claude the ability to orchestrate 1,000 sub-agents in parallel, delivering massive capability at a massive token cost.
Tools · Source: The Decoder
What happened
Anthropic just rolled out dynamic workflows for its Claude Managed Agents. This update brings multi-agent orchestration directly to the platform. A single lead agent can now take a complex job and break it into smaller pieces. It then distributes those tasks to sub-agents. Up to 1,000 of these sub-agents can run in parallel per execution. This is a massive shift from sequential processing.
Once the sub-agents finish their work, the lead agent stitches the results back together. The underlying managed agent infrastructure has existed for a while. Automating the task distribution across a massive swarm is the new capability. Developers can activate this by selecting the multiagent_20261001 agent type. They can also use a quick setup command by running /claude-api managed-agents-onboard in Claude Code.
The performance gains look impressive on paper. Anthropic tested the system by hiding 70 bugs inside a 116,000-line codebase. A standard single agent caught between 14 and 27 bugs per run. The new dynamic workflow setup consistently found 66 bugs. That is a massive jump in accuracy. But Anthropic itself warns that these workflows burn through a lot of tokens. They advise teams to start small rather than throwing 1,000 agents at a problem right out of the gate.
Key facts
- 1,000 — Maximum number of sub-agents that can run in parallel per execution.
- 70 — Number of bugs Anthropic hid in a 116,000-line codebase for testing.
- 66 — Bugs consistently caught by the dynamic workflow swarm.
- 14 to 27 — Bugs caught by a single agent per run in the same test.
- multiagent_20261001 — The agent type developers must select to activate dynamic workflows.
Why it matters
This changes the math on how we build complex AI applications. Instead of relying on a single prompt to do heavy lifting sequentially, developers can now brute-force massive codebases or datasets using parallel compute. But this capability comes with a steep price tag. Swarm orchestration multiplies API calls exponentially. Merging outputs from hundreds of agents is computationally heavy. It is also incredibly difficult to debug when something goes wrong in the middle of a massive parallel run.
The second-order effect is a looming divide in AI development strategies. We are seeing a clear split between brute-force parallel orchestration and highly optimized single-agent workflows. A senior OpenAI engineer recently dismissed agent swarms as a massive waste of tokens. Founders will have to decide if a massive increase in task completion rate is actually worth the explosive API costs. Researchers should watch for real cost-per-task comparisons against single-agent baselines. Until those numbers are public, you are betting production workloads on swarms nobody has fully priced out yet.
For builders
Test on narrow tasks first
Do not throw 1,000 agents at a vague problem. Use this for well-defined, parallel tasks like bug hunting or data extraction. The ROI must justify the massive compute cost.
Monitor your token burn rate
Founders pay the ultimate price for parallel orchestration. Set strict API limits before testing the multiagent_20261001 model. A runaway swarm will drain your startup credits overnight.
Evaluate single-agent baselines
Always compare the swarm results against a single, well-prompted agent. If the swarm only gives a marginal improvement, you are paying for parallelism you do not actually need. Optimize your single agents first.
My take
I love the ambition here, but throwing 1,000 agents at a problem feels like a lazy way to solve bad prompting. Compute is not free, and multiplying your API calls by a thousand is a great way to go bankrupt. Build smart single agents first, and only use swarms when you absolutely need the brute force.
Original reporting: The Decoder. This is my rewrite and opinion.