Forty-one agents. That is how many Haiku instances one of my Claude Code workflows spun up last week, all at once, to audit and score every skill I had installed. I watched the counter climb in the terminal, 12, 28, 41, each one a full, independent Claude call grading a different skill against criteria I handed the orchestrator. The run chewed through roughly 5 million input tokens before it finished.
Here is the plain version of what happened, because this post is a field guide, not a launch announcement. Claude Code dynamic workflows, shipped by Anthropic on May 28, 2026 as a research preview, let Claude write a JavaScript orchestration script that spawns many independent agents in parallel, each grinding on its own slice of a task, with results merged in code. The plan lives in an external file instead of the chat context, and the agents never talk to each other. That is the entire feature. Everything else here is about when to reach for it, when to reach for skills, sub-agents, agent teams, or the /goal loop instead, and how each choice will quietly treat your token budget. I learned most of this the slightly expensive way; you do not have to.
And about that 5 million: it sounds like a panic bill until you notice the shape. The output was a few hundred lines of ranked report. Nearly all the spend was reading, on Haiku input pricing, in parallel. Wide, cheap, fast. That shape is the whole point.
What Shipped, Concretely
Dynamic workflows arrived alongside the Opus 4.8 release (the model got an effort dial, which I covered in my Opus 4.8 effort-levels review, and Claude Code got a way to fan that thinking wide). They run in the CLI, the desktop app, and the VS Code extension, on Max, Team, and Enterprise plans, and triggering one is almost suspiciously casual: put the word "workflow" in your prompt. "Run a workflow to audit every API route for missing auth checks" makes Claude write an orchestration script on the fly and hand it to a background runtime.
Two hard limits to tattoo somewhere visible: 16 agents run concurrently, and a single workflow caps at 1,000 agents total. My 41-agent audit was nowhere near the ceiling, but "analyze every file in this monorepo" against a few thousand files will saturate it fast, and that is the single most common way people light money on fire with this feature.
The Architectural Detail That Actually Matters
Every other orchestration primitive in Claude Code keeps its plan inside the model's context window. The main session remembers what it delegated and holds results in working memory, which is fine for a handful of tasks and falls apart at scale, because every returned result eats room needed for reasoning.
Workflows break that rule: the plan and execution state live in an external JavaScript file. Claude writes a real script, loops, branching, agent counts, per-agent inputs, merge logic, verification passes, saves it, and a separate runtime executes it in isolation. Intermediate results live and die in the script's variables. Your session sees only the final combined answer.
That is why my audit processed 5 million tokens without touching my context window: 99 percent of those tokens never entered the conversation. Two consequences I did not appreciate until I had run a few. First, because the orchestration is a saved file, workflows are rerunnable and version-controllable; commit the script, diff it, hand it to a teammate, or promote it into a slash command the way I promote everything repeatable in my daily slash-command workflow. Second, the spawned agents do not communicate. Each is an independent Claude call with its own context. They fan out, do one job, return a summary. The combining happens in script logic, not in agent conversation. Hold onto that detail, because it is the exact line between a workflow and an agent team.
The Five Primitives, Cheapest to Priciest
Most people only ever needed two of these and reached for the expensive ones out of excitement. I did. The ladder, as I actually use it now:
Skill. A reusable recipe running inside your own session, a function you call by name. No fan-out, no separate context. My SEO checks, my commit formatter, my N+1 audit recipe: all skills. This is the default rung, and the majority of "I need an agent for this" instincts are actually "I need a skill for this," a case I made in my ten best Claude skills for 2026. If you can describe it as a recipe, it is a skill.
Sub-agent. A one-way errand. Runs parallel to your session, does not share your context, cannot talk to other sub-agents, reports back once. The value is offloading: a side task handled without cluttering your main thread's memory. No coordination is the feature; it keeps sub-agents cheap and predictable.
Agent team. A small group of agents that do talk, share context, and build on each other's findings. The distinguishing word is deliberation, and it is also why teams cost real money: shared context plus back-and-forth means more rounds. Use one when the discussion itself produces something no single agent could, architecture debates, multi-perspective reviews. Not for throughput.
Workflow. Width without conversation. Many independent agents, possibly hundreds, on separate slices, merged by code, plan held outside the model's head. My 41 Haiku scorers were the textbook case: 41 independent jobs, zero cross-talk, one ranking at the end.
/goal. Different axis entirely. Everything above is about how many agents and whether they talk; /goal is about how many times one effort iterates. Hand it a target and a definition of done, and it loops, try, evaluate, refine, until the condition holds. That looping discipline has its own craft, which I unpacked separately in my loop engineering guide.
Width vs Depth: The Frame That Makes the Choice Automatic
One sentence reorganized all of this for me: workflows are width, /goal is depth.
Width is a hundred files to scan, fifty claims to verify, a flat pile of independent jobs. The win is parallelism: tokens traded for wall-clock time. Depth is one thorny problem hammered through cycles until it passes a bar. The win is persistence: time traded for quality on one hard thing.
Wide and shallow: workflow. Narrow and deep: /goal. Small and repeated: skill. Simple side errand: sub-agent. Genuine debate: team. Answer "wide or deep, collaborative or independent, large or small" honestly and the tool picks itself.
Two built-ins sit on top of the engine, one for each end of the spectrum. Ultracode (/effort ultracode) is maximum reasoning effort plus automatic orchestration: Claude decides per-task whether to plan a workflow, and one request can fan into several in a row. It is the most capable mode Claude Code has and the most expensive thing you can leave on by accident; I run it for genuinely hard work and never as a default. /deep-research is a workflow purpose-built for investigation: parallel search angles, cross-checked sources, agents voting on competing claims, one cited synthesis. And /workflows is the control surface for all of it: see what is running, open progress, and stop anything going off the rails. I have hit that stop button more than once.
The Two Mistakes That Cost Me Tokens
I used a workflow on a job that was not wide. Three sequential steps on one file, wrapped in orchestration overhead that a skill would have done in a quarter of the tokens. The orchestration costs something before any agent runs. If the task does not genuinely shatter into independent pieces, you are paying the setup tax for nothing.
I was vague, and the workflow took me literally. "Review the codebase for issues," no scope, no deliverable. It fanned out across far more files than I cared about, each agent a full Claude call, the input meter spinning like a slot machine. At the scale of parallel agents, "exactly what you said" includes every loose interpretation of a sloppy prompt.
The fix for both is boring and works: bound the scope and define the deliverable. "Audit the 14 files in app/Http/Controllers for missing authorization middleware; return a table of file, route, missing check" gives the orchestrator a wall. "Review the code" gives it a continent. My standing rule: a workflow is right only when the task is large, AND the pieces are independent, AND they are parallelizable. Miss any one and a cheaper primitive wins.
The Move That Changes the Economics: Skills Inside Workflows
The pattern that turned workflows from money pit into leverage: each spawned agent can run your existing skills. Write one tight, tested "score this file against these ten criteria" skill, then let the workflow run that identical skill 41 times in parallel against 41 targets. You get a workflow's parallelism with a skill's consistency, which is exactly why my audit's output was clean: every agent graded by the same rubric because every agent ran the same recipe.
That is the part of the cost ladder people miss. The rungs stack. Cheap primitive doing the work, expensive primitive providing only the scale. You can even stack /goal inside a workflow, width and depth together, many agents each iterating to a target; it is the most powerful orchestration I have run and by far the most expensive thing in this post. Power tool, no guard.
Reading the Bill Before You Run
The number that matters is not total tokens; it is which tokens, on which model. My 5 million were almost entirely Haiku input, a fundamentally different bill from 5 million Opus output tokens. A workflow's cost is dominated by how much its agents read times the price of the model they read with, so pick deliberately: cheap models for wide shallow crawling, expensive models only where reasoning is the bottleneck.
Pre-flight gut check: count the independent pieces. Ten or more that genuinely do not depend on each other, and parallelism will pay for the orchestration; fewer, or interdependent, and a simpler primitive wins. In-flight, watch two gauges in /workflows: agent count climbing past what you intended means stop and tighten scope; wall-clock exceeding the sequential estimate means the job was never parallelizable and you picked wrong.
When the shape is right, the payoff is unmagical and real: an hour of sequential grinding finishes in minutes because the work was wide and you let it spread.
Quick Answers
What are Claude Code dynamic workflows?
A research-preview feature (May 28, 2026) where Claude writes a JavaScript orchestration script that runs up to 1,000 independent agents, 16 concurrently, on separate slices of a task, merging results in code, with the plan held in an external file instead of the context window.
Workflow vs sub-agent vs agent team?
Sub-agents offload one errand and report back. Teams talk and deliberate in shared context. Workflows fan out wide with zero agent-to-agent communication. Offload, deliberate, fan out.
Workflow or /goal?
Workflow for width (many independent pieces), /goal for depth (one effort iterating to a target). If it is wide and shallow, workflow; narrow and deep, /goal.
Why did my workflow cost so much?
Almost always an unbounded scope or the wrong model doing the reading. Bound the file set, name the deliverable, and put cheap models on the crawling.
Before your next big job — the codebase audit, the broad research pass, the dataset you have been dreading — say the task's shape out loud: wide or deep? That one word saves more tokens than any setting. Every system in my project portfolio was orchestrated with these exact primitives, pointed at real deliverables rather than demos.
