Jarred Sumner ported Bun from Zig to Rust — 750,000 lines, 11 days, 99.8% of the original test suite still passing. He did it with Claude Code’s dynamic workflows, which reached general availability this month for all paid plans. If that number sounds fictional, good: it’s the right reaction. Here is what actually happened and why it should change how you think about AI coding tools.
The Plan Is Now Code #
Most AI coding tools, including earlier versions of Claude Code, hold the plan in the model’s context window. Claude decides turn by turn what to do next, every intermediate result lands in the same conversation, and the whole thing is sequential. Dynamic workflows change the architecture: Claude writes a JavaScript script that orchestrates the work, and a background runtime executes it while your session stays responsive. The plan moves out of Claude’s head and into code.
That one change has three consequences developers should care about. First, the orchestration is inspectable — you can read exactly what Claude scripted, line by line. Second, it is editable and shareable — save a successful workflow as a custom slash command and your whole team runs the same process. Third, intermediate results live in script variables, not a context window, so Claude’s final output is the synthesized answer, not a 200-turn transcript.
How to Trigger a Workflow #
Three ways to start one:
- Include the keyword
ultracode
in your prompt:ultracode: audit every API endpoint under src/routes/ for missing auth checks
- Ask in plain English — “use a workflow” or “run a workflow” both work
- Run
/effort ultracode
to set session-level mode, where Claude decides when each task warrants a workflow
If you want to see a workflow before writing one, run the bundled /deep-research
command on any question. It fans out searches across multiple angles, cross-checks sources, and returns a cited report with claims that did not survive adversarial review already filtered out. It is the clearest demonstration of what the runtime actually does.
After a run you want to repeat, press s
in the /workflows
view to save the generated script as a command. It goes into .claude/workflows/
in your project (shared with teammates) or ~/.claude/workflows/
for personal use across all your projects.
Adversarial Verification Is the Point #
The 1,000-subagent ceiling gets the headlines, but the more important feature is the adversarial verification layer. After worker agents complete their findings, separate refutation agents challenge each result before it reaches you. The run iterates until answers converge — until the findings survive independent scrutiny.
This matters because the documented failure mode of AI coding agents is over-reporting completion. A single agent will tell you a migration is done when three files still have type errors. An adversarial workflow will not close until the test suite agrees. The practical instruction is straightforward: always give a workflow a concrete convergence criterion. “Use the existing test suite as the bar” is enough. “Fix the code” is not.
What 1,000 Subagents Actually Costs #
The runtime allows up to 16 agents running concurrently and 1,000 total per run. Token costs scale linearly: 100 agents at 5,000 tokens each is 500,000 tokens per run. A full 24-hour parallel job on Opus 4.8 runs $400 to $600 at current rates ($5 per million input tokens, $25 per million output tokens).
The most effective cost control is model routing: set the CLAUDE_CODE_SUBAGENT_MODEL
environment variable to route worker agents to Haiku or Sonnet, reserving Opus 4.8 for the orchestrator. That cut reduces costs 60 to 80 percent on most workflows. For smaller default scale, configure Dynamic workflow size in /config
— small
targets under 5 agents, medium
under 15, large
under 50.
Claude Code shows a “Large workflow” warning when a run schedules more than 25 agents or projects more than 1.5 million tokens. It is advisory, not a block. You can stop the run from /workflows
at any point without losing work from agents that already completed.
What to Use Workflows For — and What to Skip #
Dynamic workflows are the right tool when the task is larger than one agent can hold in context, or when the same step needs to run across many items in parallel. Common good fits: 500-file codebase migrations, security audits across entire route directories, PR reviews synthesized across all changed files, cross-checked research across multiple sources, and flaky test hunting that requires repeated suite runs.
The wrong fit is anything small. Running a workflow to change one function wastes tokens and time. Sequential tasks with real-time back-and-forth requirements are also a bad match — workflows run in the background with no mid-run input, so if your task needs sign-off between stages, structure each stage as its own workflow.
Plan Access #
Dynamic workflows are available on all paid plans with Claude Code v2.1.154 or later, and on Amazon Bedrock, Google Cloud’s Agent Platform, and Microsoft Foundry. On Pro, they are off by default — enable in /config
. On Max and Team plans they are on by default. Enterprise requires admin enablement.
The Honest Framing #
Dynamic workflows do not make AI coding trivially easy. They make a specific category of problem — large, parallelizable, verifiable — tractable in a single session instead of requiring manual decomposition across days. The Bun migration did not happen because someone typed one prompt and walked away. It happened because someone designed a workflow with clear success criteria, ran it against a real test suite, and trusted the adversarial verification loop to catch what sequential review would miss.
If your team is still running Claude one file at a time on migrations that should be automated, the infrastructure to change that is now available on your existing plan. The workflow is the part you still have to design.