Claude Code Dynamic Workflows: The Complete Guide Anthropic's Claude Code dynamic workflows enabled Jarred Sumner to port 750,000 lines of Zig to Rust with 99.8% of Bun's test suite passing in eleven days by codifying orchestration in JavaScript scripts rather than relying on the model's context window. The approach uses primitives like agent(), parallel(), and pipeline() to manage subagents, with costs scaling linearly from $0.16 for small audits to over $100 for large migrations. In eleven days, Jarred Sumner ported 750,000 lines of Zig to Rust — 99.8% of Bun’s test suite passing — using Claude Code dynamic workflows. That number gets shared as proof that AI agents can handle large migrations. What gets less attention is why it worked: the orchestration lived in a script, not a context window. That distinction is what separates dynamic workflows from just “spawning more agents,” and it’s what most tutorials miss. What Workflows Actually Are With Claude Code’s standard subagent model, Claude acts as the orchestrator: it decides turn-by-turn what to spawn next, and every intermediate result lands in its context window. At a few agents, this is fine. At fifty, the context fills up, coherence degrades, and you’re fighting the model to stay on task. Dynamic workflows flip the architecture. Claude writes a JavaScript orchestration script for the task you describe, and a runtime executes it in the background. Intermediate results stay in script variables. Claude’s context receives only the final synthesized answer. The plan lives in code — a loop you can read, rerun, and version control. This is why the Bun migration was possible. It wasn’t just about running more agents; it was that the orchestration itself was codified. When something needed re-running, the same script handled it. That repeatability is the real value. How to Trigger One The simplest trigger is the ultracode keyword anywhere in your prompt: ultracode: audit every API endpoint under src/routes/ for missing auth checks Natural language works too — “use a workflow to…” or “run a workflow that…” both register. If you want Claude to automatically plan a workflow for every substantive task in your session, run /effort ultracode . That setting uses more tokens on everything, so it’s best reserved for sessions dedicated to a single large task. Before writing a custom workflow, try /deep-research — the bundled workflow Claude Code ships with. It fans out web searches across multiple angles, cross-checks sources by having agents verify each other’s findings, filters claims that don’t survive scrutiny, and returns a cited report. It’s the fastest way to understand what workflows actually feel like to use. Requirements before you start: Claude Code CLI v2.1.154 or later https://code.claude.com/docs/en/workflows , a paid plan Pro, Max, Team, or Enterprise , and on Pro you need to enable dynamic workflows from the Dynamic workflows row in /config . The Three Primitives And the Mistake Everyone Makes Workflows use six primitives, but three matter most day-to-day: agent prompt, opts? — spawns a single subagent. Add a schema option when you need structured JSON output you’ll parse downstream. Without it, you’re hoping the agent formats its response correctly. parallel thunks — runs concurrent tasks and waits for all of them before continuing. This is a synchronization barrier. pipeline items, …stages — streams items through stages without waiting. Item A can be in stage three while item B is still in stage one. The most common beginner mistake: overusing parallel . If your middle stage has no cross-item dependency — and most don’t — you don’t need every item from stage one to finish before stage two starts. Use pipeline by default and reach for parallel only when you genuinely need the barrier. Unnecessary synchronization points add wall-clock time without adding correctness. The hard limits: 16 concurrent agents CPU-dependent and 1,000 agents total per run. In practice, most tasks need 20 to 100 agents. The 1,000 cap exists to prevent runaway token spend, not because the architecture can’t go further. The Real Cost Including a Gotcha That Bites People Costs scale roughly linearly with agent count. A three-agent security audit runs about $0.16 at Sonnet rates. A migration touching a hundred files will run $10–50. Large codebase work can exceed $100. These aren’t dealbreakers for serious engineering tasks, but they’re not free, and workflows aren’t the right tool for tasks a single conversation can handle. There’s a specific gotcha worth knowing: the cache cliff. Workflow phases separated by more than 300 seconds miss the default five-minute TTL cache window. When that happens, the runtime falls back to full cache re-writes — 12.5 times more expensive than cache reads. On a long workflow, this adds up fast. Fix: enable the one-hour TTL extension before starting a multi-phase run. The best cost-control practice is also the best quality-control practice: test on a small slice first. Run the workflow on one directory instead of the whole repo. The /workflows dashboard shows each agent’s token usage live, and you can stop the run at any point without losing work that’s already completed. When Not to Use Them Dynamic workflows are the right tool for breadth tasks — audits, migrations, research requiring cross-verification. They’re the wrong choice for sequential work where step B cannot start until step A completes use standard subagents instead , for anything a single conversation handles fine, and for situations where agents need shared state. Each agent runs with an isolated context and has no visibility into what peer agents are doing. Architectures that assume shared state fail silently. One more constraint: the orchestration script is plain JavaScript. The runtime has no transpilation layer. TypeScript annotations cause parse errors. Where to Start Run /deep-research on any question to see dynamic workflows in action before touching your codebase. Then describe a bounded task and add ultracode to the prompt. Review the planned phases before approving the run, check /workflows while it executes, and test the full workflow on a small slice before committing to a repo-wide run. Anthropic’s announcement post https://claude.com/blog/introducing-dynamic-workflows-in-claude-code has additional case studies from Klarna and CyberAgent, and the deterministic orchestration deep-dive https://alexop.dev/posts/claude-code-workflows-deterministic-orchestration/ on alexop.dev covers the pipeline-vs-parallel decision well if you want to go further. The Bun rewrite happened because someone used the right tool for the right job. Eleven days, 750,000 lines, one script. That’s not magic — that’s a plan in code.