Dynamic workflows in Claude Code: width, not depth

Claude Opus 4.8 shipped a feature called dynamic workflows, and the first thing I read about it was someone burning half their monthly plan with a single prompt. That got my attention twice over: once because it sounded expensive, and once because the shape of it felt familiar. Fan a job out across a lot of workers, run them at the same time, then fold everything back into one answer. That is a pattern I think about constantly in data work, so I spent some time figuring out what these actually are and when they earn their cost.

What it actually is

Normally Claude is the orchestrator. It decides, turn by turn, what to do, and every intermediate result lands back in its context window. A dynamic workflow moves that plan into code. You describe the goal, Claude writes a JavaScript file, and a separate runtime executes it while your session stays free. The loop, the branching, and all the messy in-between results live in script variables, so your main context only ever sees the final answer.

The nice side effect is that the script is just a file. Save it to .claude/workflows/ and you can rerun the same orchestration whenever you want, more like a saved job than a one-off chat.

The model that made it click

Claude Code already has a stack of ways to split up work, and they blur together until you separate them on two questions: how many agents are running, and can they talk to each other.

A skill is a reusable recipe.
A subagent is a parallel worker with its own context. It keeps your main session clean and reports back. Subagents don’t talk to each other.
An agent team is a small crew that does talk, with a shared task list and roles. It’s still experimental and off by default, so treat it as a preview, not a daily driver.
A workflow is a script running many agents at once, then cross-checking their results and iterating until the answers converge, rather than merging them in one pass.

The cut that helped me most was depth versus width. /goal is depth: one line of work that keeps going across turns until a condition is met. A workflow is width: a lot of agents running side by side on different pieces, pulled together at the end. That framing is mine, not Anthropic’s official taxonomy, but it’s the thing that stopped me confusing the two.

The part that costs money

Every agent in a workflow is a full Claude call with its own context window to fill. Spin up forty of them and you are paying to load context forty times over. Anthropic is upfront that a workflow can use meaningfully more tokens than doing the same task in a normal conversation, and it counts against your plan.

The discipline is the same one I’d apply to a query that’s about to scan a huge table:

Scope it. A workflow pointed at “my entire desktop” will happily crawl your entire desktop.
Run the workers cheap where you can. You set the session model, and you can ask Claude to route the heavy fan-out to a smaller model like Haiku for the stages that don’t need the strongest one.
Watch it. /workflows gives you a live view: every agent, what it’s on, tokens burned, time elapsed, and a stop button.

When I’d reach for it

Honestly, not often. Most of what I do is pipelines and analysis, and a lot of that is either a quick question or a single careful change. For that, a workflow is overkill, and that’s fine.

Where it fits is genuine fan-out work: reviewing every model in a large dbt project, a migration where each file is independent, or research you want cross-checked from several angles. That last one is built in as /deep-research, which fans out across sources, has the agents vote on each claim, and hands back a cited report with the weak claims dropped. If a job breaks cleanly into many pieces that can run on their own, width wins. If it doesn’t, don’t force it.

Knowing what a tool is for, and when to leave it alone, is most of the value. You don’t have to use every feature to feel like you’re keeping up.