Claude Code Dynamic Workflows: The Two-Week Field Log on When They Are Worth It

I typed one sentence and Claude Code spun up forty agents.

They fanned out across my codebase, argued with each other about what they found, and handed me one report twenty minutes later. My laptop fan never moved. My token bill did.

That was my first run with Claude Code dynamic workflows, the feature Anthropic shipped in June 2026. I have now run it daily for two weeks on a real Next.js side project. Here is the honest field log: where it earned the tokens, where it quietly wasted them, and the four-question test I run before I type ultracode now.

Quick answer (July 2026)

Claude Code dynamic workflows let Claude write a JavaScript orchestration script that fans work out across dozens to hundreds of subagents, then runs it in the background while your session stays free. They are genuinely great for big, uniform, verifiable jobs: a codebase-wide audit, a large migration, cross-checked research. They are a bad deal for small tasks, because a single run can burn meaningfully more tokens than just doing the work in one conversation. The skill is not learning the syntax. Claude writes the script. The skill is knowing which tasks deserve one.

What a dynamic workflow actually is

I had the wrong mental model at first. I thought "workflow" meant a saved prompt or a macro. It is not that.

A dynamic workflow is a JavaScript script that orchestrates subagents. You describe a task, Claude writes the script, and a separate runtime executes it in the background. The official docs put it plainly: it is for tasks that need "more agents than one conversation can coordinate" (Claude Code docs, 2026).

The part that changed how I work is where the intermediate results live. With plain subagents, every result lands back in Claude's context window, and a big job fills it fast. In a workflow, the results live in script variables instead. Claude's context only ever holds the final answer. That is why a forty-agent run does not blow up the session.

You start one three ways:

# one-off: drop the keyword in your prompt
ultracode: audit every route handler under src/app/api for missing auth checks

# or just ask in plain words
use a workflow to migrate these components to Tailwind

# or hand the whole session over
/effort ultracode

The subagents are the same primitive I wrote about in my subagents field log. A workflow is just what happens when you need forty of them working at once and something has to hold the plan.

Where it earned the tokens

Three jobs this fortnight were exactly the right shape.

A codebase-wide auth audit. I asked it to check every API route for a missing session guard and to adversarially verify each finding before reporting it. It fanned out one agent per file, then ran a second pass of skeptic agents trying to disprove each hit. Out of nine flagged routes, three survived the skeptics. The other six were false alarms the verify pass killed before I ever saw them. Doing that by hand across forty routes would have eaten my afternoon.

A styled-components to Tailwind migration. Thirty-one components. It discovered the files, transformed each one in its own isolated copy so the edits did not collide, and verified each result compiled. I reviewed the diffs in one sitting instead of babysitting a conversation for an hour.

Deep research on a dependency question. The bundled /deep-research workflow fanned readers across changelogs and docs, cross-checked the claims against each other, and dropped the ones that did not hold up. I got a cited answer instead of a confident guess.

The common thread: many similar items, a clear done condition, and a result I could verify. That is the whole recipe.

Where it quietly wasted them

Now the part the launch videos skip.

Week one, I got excited and reached for a workflow on everything. Rename a prop across four files. Write one test. Explain a function. Every one of those was slower and more expensive than just asking Claude in the chat. A workflow spins up a runtime and multiple agents. For a two-file change, that overhead is pure waste.

The docs say it directly: a single run "can use meaningfully more tokens than working through the same task in conversation." I felt that on the invoice. Claude Code even flags a run as a Large workflow once it schedules more than 25 agents or projects past 1.5 million tokens. The first time I saw that warning I had asked it to "clean up the whole repo." I stopped the run. That was on me, not the tool.

The failure mode nobody warns you about is not a bug. It is the temptation to treat a hundred parallel agents as a magic button for a task that never needed them.

The four questions I ask before I type ultracode

This is the test that saved my token budget in week two.

1. Is the work more than one agent can hold in context? If a single conversation can finish it, use a conversation.
2. Does the same step repeat across many items? Files, endpoints, sources, tests. Uniform work is what fans out cleanly.
3. Can the result be verified? Compiles, passes, cross-checks. If success is subjective, parallel agents just give you parallel opinions.
4. Have I scoped it small first? I run it on one directory before the whole repo. The /workflows view shows live token counts, and I can stop it without losing finished work.

If a task fails questions one and two, I close the effort menu and just talk to Claude.

One thing that surprised me

When a run does what I wanted, I can save its script as a command. Press s in the /workflows view and it becomes /my-thing in future sessions. My auth audit is now a one-word command I run on every branch. That moved workflows from "cool demo" to "part of my actual toolkit," the same way a few custom commands earned permanent slots last month. If you want to see the shape of a real one before you generate your own, the community has already published production examples like shinpr/claude-code-workflows.

So, worth it?

Yes, but not for what the hype says. Dynamic workflows are not a general speed boost. They are a specialized tool for jobs that are too big and too uniform for one context window, and where you can check the answer. Point them there and they are the most leverage I have felt in months. Point them at a two-file rename and you are lighting tokens on fire to feel busy.

Use the four questions. Scope small first. Save the ones that work.

P.S. My auth-audit workflow found a missing guard on a route I wrote myself last week. Humbling. Kept it.

FAQ

What are Claude Code dynamic workflows?
They are a feature where Claude writes a JavaScript script that orchestrates many subagents, then a runtime runs it in the background across dozens to hundreds of agents. Intermediate results stay in script variables, so your session's context only holds the final report. They landed in Claude Code v2.1.154 (June 2026) and need a paid plan.

How do I start a dynamic workflow?
Three ways: include the keyword ultracode in a single prompt, ask in plain words ("use a workflow to..."), or set /effort ultracode to let Claude decide for every task in the session. You can also run the bundled /deep-research workflow.

Do dynamic workflows cost more tokens?
Yes. A run spawns many agents, so it can use meaningfully more tokens than doing the same task in one conversation. Claude Code shows a Large workflow warning past 25 agents or a projected 1.5 million tokens. Scope on a small slice first and watch the live token count in /workflows.

When should I not use a dynamic workflow?
For small tasks a single conversation can finish, like a two-file rename or one test. The orchestration overhead outweighs the benefit. Reach for a workflow only when the job is larger than one context window, repeats across many items, and produces a result you can verify.

Can I reuse a dynamic workflow?
Yes. In the /workflows view, select a completed run and press s to save its script as a /command, either in your project's .claude/workflows/ or your home directory. It then runs like any other slash command in future sessions.