For a year, the ceiling on what a coding agent could do in one shot was the context window. Everything the agent needed to reason about — the plan, the files, the intermediate results — had to fit in the same window, and once it filled up, quality fell off a cliff.

Dynamic workflows move that ceiling. Instead of holding the whole plan in its head, Claude Code writes a short JavaScript program that is the plan, then a runtime executes it — spawning a fleet of subagents in the background while your session stays free. Anthropic calls it “a harness for every task”: rather than you hand-building a scaffold of subagents and review steps, Claude builds one on the fly, sized to the job in front of it.

The proof point Anthropic led with is a big one, and it traces back to a primary source. Jarred Sumner — Bun’s creator — used about 50 dynamic workflows, running up to 64 Claude agents at once, to port Bun’s runtime from Zig to Rust in eleven days (first commit May 3, merged May 14). In his own writeup he counts 535,496 lines of Zig ported across 6,502 commits, ending with every supported platform’s test suite green and zero tests skipped or deleted — at a cost of roughly $165,000 in API tokens. Treat that as a ceiling, not a promise: it’s the scale this feature is built for, not what a first try on your codebase will look like. This post is about the boring middle: what a workflow actually is, how to start one, where it’s worth the tokens, and where it isn’t.

What a dynamic workflow actually is

Here’s the one-sentence version: a dynamic workflow is a JavaScript script that Claude writes for the task you describe, which a runtime runs in the background, orchestrating many subagents.

The mental model that makes it click is that the plan moves into code. In a normal Claude Code session, the plan lives in the conversation — every step, every intermediate finding, every “okay now do the next file” is more text in the context window. In a workflow, that logic becomes a program: loops, conditionals, fan-out. Intermediate results live in script variables, not in Claude’s context. So when a hundred agents each read a file and report back, you don’t pay to stuff a hundred reports into one window. Only the final answer lands back in your conversation.

That’s the difference from the tools it sits next to. It comes down to who holds the plan:

Tool	Who holds the plan
Subagents	Claude, turn by turn, in context
Skills	The prompt / skill file
Agent teams	A lead agent
Dynamic workflows	The script

Putting the plan in code buys you one thing you can’t get from a single agent: a repeatable quality pattern. Because the orchestration is written down, a workflow can do things like spawn several independent agents to review each other’s findings and throw out anything they can’t corroborate — the same structure, every run, without you babysitting it.

And to head off the obvious question: the scripts are JavaScript, and they run locally or in the cloud. That’s straight from Boris Cherny on the Claude Code team, answering it directly in the launch thread: “JavaScript, running locally or in the cloud.”

How you actually trigger one

There are three ways in, and they escalate in how much you’re handing over.

1. The ultracode keyword. Drop it in a prompt and Claude treats that one task as a candidate for a workflow, without changing your effort setting. Lightest touch. (Before v2.1.160 the keyword was workflow — worth knowing if an old habit or a conflicting command bites you.)
2. /effort ultracode. Bumps effort to xhigh and lets Claude decide, per task, whether a workflow is worth it. This is the “lean on it” setting.
3. Plain English. “Use a workflow for this” or “run a workflow” works too — you don’t have to memorize a keyword.

Nothing fans out behind your back. Before a workflow spawns anything, Claude Code shows you the planned phases and a token caution, and you approve it — the exact behavior depends on your permission mode. Once it’s running, /workflows gives you a live progress view: the phases, how many agents are going, and a running token total. You can pause, resume, or stop, and if a workflow was useful you can save it as a reusable command by pressing s. One caveat worth knowing: runs are resumable within the same session, not across restarts.

The zero-setup way to see all of this is the bundled /deep-research command. Ask it a real question and it fans out searches, cross-checks what it finds across sources, and hands back a cited report with unsupported claims filtered out. It’s a workflow you can run today without writing a line of JavaScript.

Real-life use cases — where it earns its keep

The tasks where a workflow beats a single agent share a shape: many similar items, or one job worth checking from several angles. A few that come up repeatedly:

• Codebase-wide sweeps. A missing-auth audit or a bug hunt where you run one agent per file, then have separate agents adversarially verify each finding before it’s reported.
• Large mechanical migrations. A 500-file framework or styling migration where each file is transformed in an isolated copy so parallel edits don’t collide, and each result gets verified.
• Cross-checked research. Fan out readers across sources and synthesize — the /deep-research shape, pointed at a competitive analysis or a literature scan.
• Loop-until-green. Run a checker, fix what failed, repeat until the suite passes or the workflow stops making progress. The bundled /loop command does exactly this.
• Profiler-guided optimization and security audits with independent verification — two of the early-access uses Anthropic cites.

For a sense of what the team actually ships with it, Boris Cherny listed a few of his own uses in the launch thread — verbatim: “Autonomously landed 20+ optimizations to reduce Claude Code’s token usage by ~15%… Made our CI faster, and repeatedly found and fixed flaky tests (with /loop)… Reduced Claude Agent SDK startup time by 61%.” Worth reading as a self-report from the vendor, not an independent benchmark — and, fairly, some of the thread pushed back on exactly that, which we’ll get to.

Anthropic also floats non-coding shapes: adversarial review of a business plan, or scanning your own history for recurring mistakes. The pattern generalizes past code.

The catch — cost, verification, and guardrails

Now the honest part. A workflow can burn meaningfully more tokens than doing the same task in a single conversation, because you’re paying for a fleet of agents plus the review passes that check their work. Runs count toward your normal plan usage and rate limits — there’s no separate meter. The practical advice: scope your first run to one directory or one narrow question, watch what it costs in /workflows, and widen from there.

The guardrails are there to keep a runaway fan-out from becoming a runaway bill:

• Up to 16 concurrent agents, and 1,000 total per run.
• A Large workflow warning before it commits, triggered past roughly 25 agents or 1.5M projected tokens.
• A size guideline in /config (small / medium / large) so you can cap ambition up front.

There’s a design argument underneath the cost, and it’s the strongest case for the whole feature. Anthropic frames workflows as a fix for three ways a single agent quietly fails: agentic laziness (stopping before the job’s really done), self-preferential bias (trusting its own output instead of checking it), and goal drift (wandering off what you asked for). Giving each subagent an isolated context and one focused goal — plus other agents whose job is to disagree — is meant to blunt all three. Whether that’s worth the token multiple is the real question, and it’s exactly where practitioners split.

What practitioners are actually saying

The launch thread on Hacker News is the best read on the reception, and it’s genuinely mixed.

The enthusiasm is that this formalizes something developers were already doing by hand — the harnesses, custom commands, and review pipelines people had been assembling ad hoc. That tracks with a view we’ve argued here before: the harness around the model matters as much as the model itself.

The skepticism is sharper and it clusters on cost. Deukhoofd’s read: the whole thing “very much reads like an exciting new way to burn up as many tokens as possible.” “Large amounts of parallel agents that all have all their work double-checked by multiple other agents, and that keeps running for a longer period of time? I feel like there are more efficient ways to tackle the issues given.” Another commenter, mattas, was blunter: “My initial reaction was that this is tokenmaxxing disguised as a product.”

The most useful critique reframes the whole thing: the bottleneck isn’t Claude’s speed, it’s correctness. As trjordan put it, “It feels like we’re far past the point of where having AI do more faster is helpful… In my experience, AI still drifts from what I meant it to do on anything bigger than building a widget. My time is spent suspiciously reviewing output for changes the agent snuck in, or invariants it broke.” More agents only help if something actually validates their work.

There’s a rebuttal to that, too, and it’s fair: ithkuil noted you “cannot complain that agents don’t produce high quality code while at the same time not allowing them to thoroughly go through all the steps required to produce high quality code.” And kian pointed at where the leverage really is — the plan stage: “a significant part of this is due to an involved /plan stage — going back and forth on building out a plan for what you want the AI to do involves surfacing the assumptions that you would have called drift if you asked them to implement it directly from your prompt.”

Not all the friction is philosophical. Some is plain UX: vblanco flagged that the workflow keyword “conflicts with [my own version] rather heavily” and asked for a way to disable it (there is one — see below). And when Cherny listed Anthropic’s internal wins, verve_rat wasn’t buying it as guidance: “None of those are helpful examples we could mimic to figure out how to use the tools. This reads like a CV, not trying to help or educate.”

The honest summary: nobody in the thread doubts the mechanism works. The open question is whether spending 3–10x the tokens buys you a better outcome, or just a faster wrong answer — and the answer depends entirely on whether you’ve got a check the workflow has to pass.

The docs in one screen

If you read nothing else:

• What it is: Claude writes a JavaScript orchestration script; a runtime runs it in the background across many subagents; intermediate results stay in script variables.
• Availability: generally available on all paid plans (Pro, Max, Team, Enterprise), with Anthropic API access, and on Amazon Bedrock, Google Cloud’s Agent Platform, and Microsoft Foundry. Requires Claude Code v2.1.154 or later; on Pro, switch it on from the Dynamic workflows row in /config.
• Three triggers: ultracode keyword, /effort ultracode, or plain “use a workflow.”
• Try it free: /deep-research (and /loop) are bundled workflows.
• Limits: 16 concurrent / 1,000 total agents; Large workflow warning past ~25 agents or ~1.5M projected tokens.
• Cost: counts toward normal plan usage and rate limits; scope narrow first.
• Turn it off: disableWorkflows: true in settings.json, the CLAUDE_CODE_DISABLE_WORKFLOWS=1 environment variable, or the Dynamic workflows toggle in /config.

Canonical further reading: the dynamic workflows documentation and the launch post, “A harness for every task.”

When to reach for it — and when not to

Reach for a workflow when the task is bigger than one context window, when it’s the same step repeated across many items, or when the result is worth cross-checking from several angles and you’ve got a way to validate it.

Skip it for quick single-file edits, and for anything where you’d spend longer reviewing a fan-out than just doing the work yourself. If there’s no check the workflow has to satisfy — no test suite, no adversarial pass, no clear pass/fail — more agents mostly buy you more tokens.

For a decision tree on when to hand Claude the orchestration versus keep the harness yourself, see When to Let Claude Write the Harness. The lowest-risk way to form your own opinion, though, is to run /deep-research on a real question you actually have. You’ll see the phases, the agent count, and the token total, and you’ll know within one run whether the fan-out earned its keep on your work.