Anthropic has upgraded Claude Code's Dynamic Workflows from research preview to general availability, extending access to Pro plan subscribers for the first time — a meaningful expansion that brings the tool's most powerful capability to users who previously needed a $100-per-month plan to reach it. The feature, which lets Claude write its own orchestration scripts and coordinate up to 1,000 parallel subagents in a single run, demonstrated its ceiling last month when it drove the six-day, 960,000-line port of the Bun JavaScript runtime from Zig to Rust with 99.8% of the existing test suite passing — a task that historically would have taken a team of engineers several months.

The architectural move underneath Dynamic Workflows is quieter than its agent count suggests. In every prior Claude Code pattern, the model held the orchestration plan in its conversation context window — meaning every intermediate result, every dead end, and every retry accumulated there until the window filled. For a 500,000-line codebase, that ceiling arrived well before the task did. Dynamic Workflows externalizes the plan: Claude writes a JavaScript orchestration script, a separate runtime executes it in the background, and the model's context receives only the final synthesized answer. The distinction matters because it determines whether a multi-day autonomous run is architecturally possible at all, not merely whether it finishes faster.

The Patterns Anthropic Said You'd Have to Write Yourself

In December 2024, Anthropic published a widely cited engineering guide that documented five orchestration patterns — prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer — and explicitly told developers to implement them in hand-coded systems. Seventeen months later, Dynamic Workflows automates exactly those patterns on demand. A developer who previously needed to build an orchestrator-workers loop by hand can now describe the task in plain language and receive a JavaScript script that implements the same architecture, tailored to the specific job.

The evaluator-optimizer pattern is where Dynamic Workflows earns its most significant distinction from simpler fan-out approaches. When Claude breaks a task into parallel subtasks and dispatches worker agents to each, a separate layer of adversarial agents then challenges those findings before anything reaches the user. A migration agent that reports 99% completion is not accepted; a refutation agent is tasked with finding what it missed. The run iterates until findings converge under that adversarial check. This is the structural answer to a well-documented failure mode in LLM-based agents: models asked to verify their own work consistently over-report success.

What Moved Out of the Context Window — and Why That Changes Everything

The context window constraint has shaped every approach to autonomous AI coding for the past three years. A single LLM agent running through a large codebase accumulates every intermediate result in its working memory. By step 25 or step 50, the model has lost the function signatures from step 5. It continues generating code that no longer matches the interfaces it established earlier, and it does not notice.

Dynamic Workflows's JavaScript runtime solves this at the infrastructure level. Each subagent receives a clean, focused context window containing only the specific task assigned to it — one file, one endpoint, one security check. The orchestration logic, the branching decisions, the intermediate results, and the verification loop all live in the script that the runtime executes, not in any single model's memory. According to Anthropic's documentation, a workflow can run up to 16 agents concurrently with a hard cap of 1,000 total agents per run. Progress is saved continuously, so an interrupted multi-hour migration can resume from its last checkpoint rather than starting over.

The Bun Port: What 960,000 Lines in Six Days Actually Proves

The most widely cited proof point for Dynamic Workflows is the port of the Bun JavaScript runtime from Zig to Rust. One disclosure the launch coverage largely omitted: Bun's creator Jarred Sumner has been an Anthropic employee since Anthropic acquired Bun in December 2025. The Bun port is an internal Anthropic team demonstrating Anthropic's tool on Anthropic's own codebase — a genuine and significant engineering achievement, but one that should be understood in that context rather than as independent third-party validation.

The port itself ran across four phases over six days of agent execution — approximately 11 calendar days from first commit to the merge of the branch. One workflow mapped the correct Rust memory lifetime for every struct field in the Zig source. A second dispatched hundreds of parallel agents to produce behavior-identical .rs files for every .zig file, with two adversarial reviewers assigned to each output. A fix loop then drove the build and test suite until both ran clean. The final phase identified unnecessary data copies and opened a pull request for each.

The result was roughly 750,000 lines of Rust output from approximately 960,000 lines of Zig input, with 99.8% of the existing test suite passing on Linux x64. Independent technical analysis of the Rust branch has identified one significant limitation: the port contains approximately 13,000 to 14,000 unsafe blocks. In idiomatic Rust, unsafe blocks mark areas where the compiler's memory-safety guarantees no longer apply — they are explicitly annotated exceptions, not errors. The Bun port's high count reflects the realities of a line-by-line machine translation from Zig's explicit allocator model into a language that normally enforces strict borrowing rules at compile time. Sumner has described it as a structurally rough transliteration rather than an idiomatic rewrite, with the expectation that Rust's compiler tooling will serve as the long-term enforcement mechanism going forward. Full Mac and Windows test suite results are still pending.

What Does a Multi-Day Agent Run Actually Cost?

The token math for Dynamic Workflows is non-linear in a way that matters before a team commits to it. Parallel agents do not share tokens — each agent consumes tokens independently, which means a 10-agent run costs approximately 10 times the tokens of a single-agent run for the same wall-clock time. At Claude Opus 4.8 pricing of $5 per million input tokens and $25 per million output tokens, a full 24-hour parallel run can cost between $400 and $600. Anthropic warns that Dynamic Workflows "consume substantially more tokens than a typical Claude Code session" and recommends starting with a scoped task before attempting a full-codebase operation.

The Futurum Group's Mitch Ashley, VP and practice lead for software lifecycle engineering, identified verification as the harder organizational problem: "When one session fans out into hundreds of subagents across a migration or an audit, change outpaces what a team can review by hand. Organizations adopting this need verification, governance, and evidence capture that scale at the pace of generation. Treat that as an afterthought and you inherit verification debt faster than the tooling pays it down."

Who Can Access Dynamic Workflows Now — and How to Start

With the general availability update, Dynamic Workflows are now available across all paid Claude Code plans:

Pro plan ($20/month): Available but off by default. Enable through /config in the Claude Code interface — a one-time setting that persists for the session.

Max and Team plans: On by default.

Enterprise plans: Off by default. Organization administrators must enable the feature through managed settings or the Claude Code admin settings page.

The feature runs across the Claude Code CLI, Desktop application, and VS Code extension, as well as through the Claude API and three major cloud platforms: Amazon Bedrock, Vertex AI, and Microsoft Foundry.

To start a workflow, include the word "ultracode" in a prompt or ask Claude directly to "create a workflow." The first time a workflow triggers, Claude Code shows the planned phases and asks for confirmation before proceeding. For session-level automation, enabling the ultracode setting in the effort menu instructs Claude to decide autonomously when a given task warrants the full multi-agent treatment — a setting Anthropic recommends turning off for routine work and reserving for sessions where most tasks are large, ambiguous, or high-stakes.

How Dynamic Workflows Differ from OpenAI Codex's Parallel Approach

OpenAI's Codex, the primary competing agentic coding tool, supports parallel task execution through isolated cloud containers — each task runs in its own sandboxed environment with network access disabled once execution begins. The architectural difference from Dynamic Workflows is where coordination lives. Codex queues parallel tasks and runs them independently; Dynamic Workflows runs a verification and adversarial-review layer across the outputs before anything reaches the developer. In practice, Claude Code's approach is better suited for tasks that require agents to share findings and iterate toward a converged answer — migrations and audits where one agent's discovery should inform the scope of another's. Codex's cloud-delegation model is generally preferred for teams that want to hand off a well-defined task and receive a pull request without maintaining a local running session.

Frequently Asked Questions

What is the architectural difference between Dynamic Workflows and Claude Code's previous subagent approach?

In previous Claude Code multi-agent patterns, every coordination decision and intermediate result lived in the model's conversation context window. The window has a fixed size, and a large migration could exhaust it before the task finished. Dynamic Workflows moves the orchestration plan into a JavaScript script that a separate runtime executes in the background. The context window receives only the final answer. The practical effect: Claude can coordinate hundreds of agents across a multi-hour run without any single context window filling up, and the script is a readable, rerunnable artifact rather than a performance that cannot be reproduced.

How do Dynamic Workflows compare to OpenAI Codex for AI code migrations?

Both tools support multi-agent parallel execution, but they handle coordination differently. Claude Code Dynamic Workflows include an adversarial verification layer: after parallel agents complete their assigned work, separate agents are specifically tasked with challenging the findings before results converge. OpenAI Codex runs tasks in isolated containers and returns pull requests but does not ship an explicit adversarial-review layer in the same way. For tasks where correctness must be verified across findings — security audits, large-scale migrations with a test suite as the success bar — the Dynamic Workflows verification architecture is the more relevant differentiator.

What does a Dynamic Workflows run actually cost, and is there a way to control it?

Token costs scale linearly with agent count. At Claude Opus 4.8 pricing, a large 24-hour parallel run can cost $400–$600. For Pro and Max plan subscribers, the feature draws from plan usage limits rather than billing separately. Anthropic recommends starting with a scoped task — auditing a single directory rather than a full repository — to calibrate costs before scaling up. Setting a token budget in the prompt and using the /workflows view to monitor spending per agent are the primary tools for keeping costs predictable.

What is the "ultracode" setting and when should I use it?

ultracode is a session-level effort setting that sets Claude to its maximum reasoning level (xhigh) and allows Claude to automatically decide when a task warrants a Dynamic Workflow rather than a standard single-agent approach. It applies to every subsequent task in the session, so each request takes longer and uses more tokens. Anthropic recommends enabling it only for sessions where most tasks are large, complex, or high-stakes. For routine work, drop back to /effort high to avoid running expensive workflows on tasks a single agent could handle faster and cheaper.