Anthropic shipped Dynamic Workflows for Claude Code on June 2. The headline number is 1,000 subagents per run. The more relevant number is 16.

Here's the distinction. A dynamic workflow can coordinate up to 1,000 agents total — meaning Claude can spawn, dispatch tasks to, and collect results from 1,000 subagent instances across the lifetime of a run. But the concurrency ceiling is 16 agents running simultaneously (lower on machines with limited CPU cores). The rest queue behind them.

For most engineering tasks, 16 concurrent agents doing real work is already more parallelism than you'll ever need. But the mental model of "1,000 parallel agents" is just wrong. What you have is a rolling queue of 16, with a total budget of 1,000 dispatches. That's a different thing — and a more honest description of what it does.

How it actually works

When you trigger a dynamic workflow, Claude writes a JavaScript orchestration script based on your prompt. Not you. Claude. You describe what you want done — "audit all API endpoints in this service for injection vulnerabilities" or "migrate all deprecated database calls in this repository" — and Claude generates the script, plans the fan-out, dispatches agents, and collects results. You see the orchestration script before it runs, and you can review it. But the planning is Claude's.

Then it runs. Agents fan out. Work happens in parallel up to the 16-agent ceiling. Subagent results fold back into a coordinated output. You get one answer.

The use cases that Anthropic describes are real ones:

• Security audits across an entire service
• Migrations touching hundreds of files
• Bug hunts that need every corner of a codebase investigated
• Architectural analysis of complex, multi-component systems

These are the problems that currently either don't get done or get done slowly by being manually partitioned across sessions. A Claude-orchestrated workflow that investigates all of them in parallel is genuinely useful for that class of work. The question is whether the problems you have are that class.

The token math is the buried lead

Anthropic says dynamic workflows "can consume substantially more tokens than a typical Claude Code session." That is doing a lot of work.

A single non-trivial Fable 5 session might use a few million output tokens. A 16-concurrent-agent workflow running for an hour, each agent doing meaningful work at $10/$50 per million input/output, can land billing you didn't expect. The orchestration script generation adds tokens. The agent dispatches add tokens. The result consolidation adds tokens. And if you're running this against a large codebase on Fable 5, those numbers compound fast.

This is not an argument against using it. It is an argument for setting token-consumption budget alerts before you let a workflow run unattended.

Anthropic's recommendation is to start with smaller, well-scoped tasks before scaling up. That's sensible and also reveals something: "research preview" here means they haven't yet fully characterized the cost-predictability envelope. This is real, shipping, usable capability — but with enough caveats that Anthropic wants you to understand you're participating in the beta of the billing story as much as the technical one.

What this actually competes with

The comparison isn't to a single Claude Code session. It's to three things:

1. Manual parallel work by a human team. A security audit that takes two engineers three days can now be scoped to a workflow that runs overnight. Token cost of the workflow vs. engineering-hours cost of the alternative is the relevant math.
2. Fragmented multi-session Claude workflows. If you've been approximating parallelism by running six Claude Code sessions in different terminal tabs and manually stitching the results, dynamic workflows replaces that with coordination at the model level.
3. Purpose-built code-analysis tools (Semgrep, CodeQL, custom static analysis). For specific, well-defined analysis tasks, those tools are still faster and more cost-predictable. Dynamic workflows is for the fuzzy, open-ended questions those tools can't answer.

Source spread

• Anthropic — Introducing dynamic workflows in Claude Code [hype] — official announcement, use cases, capability description.
• Anthropic Claude Code Docs — Orchestrate subagents at scale [builder] — technical reference; 1,000/16 agent constraints specified here.
• InfoQ — Claude Code Adds Dynamic Workflows for Parallel Agent Coordination [builder] — solid technical explainer of the orchestration architecture.
• DevOps.com — Claude Code's Dynamic Workflows Take on Tasks Too Big to Automate [builder] — practical framing; 16-concurrent ceiling sourced here.
• Lushbinary — Claude Code Dynamic Workflows: Harness Guide [skeptic] — raises cost predictability questions in practice.

Pros & cons

What's real:

• For the right class of problem — security audits, large migrations, cross-service bug hunts — this is a real capability that doesn't exist anywhere else at this level of coordination.
• Claude generating the orchestration script removes a workflow-engineering burden from the builder. You describe the outcome; Claude handles the fan-out design.
• The 16-concurrent ceiling is a sensible constraint that prevents runaway consumption while still delivering meaningful parallelism.
• Research preview availability across API, Bedrock, Vertex, and Foundry means enterprise deployments can test this in their existing infrastructure.

What deserves a side-eye:

• "Research preview" is doing real work here. Billing predictability is not fully characterized yet. Token consumption can be substantially higher than expected, and the orchestration script's quality depends on Claude's planning — which is very good, not infallible.
• Claude writes the orchestration script. For high-stakes work — security audits, financial analysis, compliance checks — the generated script should be reviewed carefully before execution. That review step is non-optional.
• 16 concurrent agents is the real ceiling, not 1,000. The headline number will set wrong expectations for builders imagining true massive parallelism.
• Max/Team/Enterprise only. No Fable 5 fast-burn access for solo Pro developers.

What builders need to know

• Available today in Claude Code CLI, Desktop, and VS Code extension on Max, Team, and Enterprise plans. Enterprise requires admin enablement.
• Also available via the Claude API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry — no UI required.
• Before starting a workflow run: review the generated orchestration script. Claude shows it to you before execution. Spend 60 seconds on it. For security audits and compliance work especially.
• Set a token-consumption budget alert before your first run. This is not optional if you're on a metered plan.
• Start with a well-scoped test case — one service, one type of analysis — before throwing a 200K-line monorepo at it.
• The 16-concurrent-agent ceiling is the operative constraint. If you need more than 16 simultaneous investigations, queue planning becomes important. The orchestration script handles this automatically, but know the model.

Further reading

• Anthropic — Introducing dynamic workflows in Claude Code — official announcement and use cases
• Claude Code Docs — Orchestrate subagents at scale — technical reference, agent limits, API surface
• InfoQ — Dynamic Workflows for Parallel Agent Coordination — technical architecture explainer
• DevOps.com — Workflows that were too big to automate — good framing of the use case space