Two runs, both documented, both real.

The first: a single prompt fanned out into 160 agents over three hours and twelve minutes, consumed 11.4 million tokens, and finished with 155 of the 160 agents succeeding; the output was a standardized research wiki the team kept using afterward (Echofold's write-up). The second: 62 Opus agents spawned for a code review exhausted a five-hour usage window in 18 minutes, reported in the launch thread by a user who did not enjoy it.

These are the same feature. What differed was discipline: scoping, verification structure, and which guardrails were configured before anyone typed the trigger word. All three of those are settings, and settings are a leadership concern. So the interesting question for this post isn't “how much does it cost.” It's “what shape does the cost have, and who controls the knobs.”

Sixty seconds of mental model

For the reader arriving fresh: a dynamic workflow is a small JavaScript program Claude writes for a task you describe. A runtime executes it in the background, spawning tens to hundreds of small agents; intermediate results live in program variables instead of a chat context, so the run can scale far past what one conversation holds. Every run starts from an explicit opt-in, shows you its plan before executing, and stays observable and stoppable throughout. That's the whole model. Part one is the full orientation.

The cost shape

Here's the part most cost conversations miss, and it changes the conclusion.

A conventional agent session bills like a triangle. Token pricing is linear, but a session resends its entire history on every tool-call turn. So a session that grows to 120,000 tokens over forty turns doesn't bill 120K tokens of input; it bills the area under that growth, a couple of million cumulative token-reads for one 40-file audit. Double the scope and you roughly quadruple the area. Cost quadratic in scope, from linear pricing.

Prompt caching softens this without changing it. On current Anthropic pricing, cached reads run about a tenth of base input price (writes carry a 1.25× premium), so the triangle gets close to an order-of-magnitude discount, and keeps its shape. The exponent survives the discount. It adds up anyway, and latency scales right along with it, because every turn re-reads the mountain whether or not the reads are cheap.

Fan-out changes the exponent, not the constant. In a workflow, agent 30 never carries agents 1 through 29: each starts fresh, does its one job in a few thousand tokens, and ends. Per-item cost is flat; total cost is linear in scope. The per-agent overhead that should ruin this (every agent re-processing the same system prompt and tool definitions, around 15K tokens a head) is exactly what the runtime's fan-out stagger exists to kill: siblings are held until the first agent's response begins, then released to read its cached prefix at the discounted rate.

CUMULATIVE COST PER RUN ($)

monolithic session

workflow fan-out

Three counterweights keep this honest, and you should hear them from me before a vendor skips them. Shared material that every agent needs (say a 50K-token design doc) sits after the cached prefix in each agent's own prompt and bills per agent; heavy shared context can flip the math back toward the monolith. Cache sharing requires uniform agent configuration, so a fan-out that routes half its agents to a different model builds two prefixes and pays for both. And the empirical record is that workflow runs often cost more in total, because verification is added work the monolithic session never did.

Which yields the claim that survives contact with both the math and the Hacker News thread: fan-out is cheaper per unit of work, and well-built workflows spend the savings (often more than the savings) on rigor. One more line makes it interesting: the small fresh context is simultaneously the cheap one and the accurate one, because model attention degrades over long contexts (part one covers this). The same intervention buys both.

A cost model you can put in a spreadsheet

Four numbers produce a usable estimate.

INPUT	TYPICAL VALUE
Orchestration script	≈ 0 tokens; the program itself is nearly free
Per-agent cost	~2K–20K tokens, by task depth
Verification multiplier	~2–3× agent count (our worked audit: 38 scan agents became ~90 with a verify phase)
Accounting	Runs count toward plan usage and rate limits like any other session

Worked through: a 38-file audit with verification lands near 90 agents; at an 8K-token average that's roughly 700K–800K tokens per run, a few dollars at current Sonnet-class API rates and more on Opus-class models. Hold that against the cold open and the model calibrates: the 160-agent research run's 11.4M tokens implies heavier agents (~70K average, appropriate for deep reading tasks), and the 18-minute window burn is what ~60 Opus-class agents look like against a subscription allowance rather than API billing. The spread is wide; the model is for order-of-magnitude and trend, and the live per-agent token view is for truth.

The levers, in the order I'd pull them: route subagents to a cheaper model, globally or per stage (the strongest single knob); keep fan-out configurations uniform so the cache sharing you just read about actually happens; set a token budget ceiling on large runs, which is hard, not advisory; pilot every new workflow on a small slice (one directory, one narrow question) with the token view open; and set a size guideline so generated workflows aim small by default (next section).

I've built the four-input estimator as a spreadsheet that accompanies this post: plug in your item count, per-agent depth, verification factor, and model rate, and it produces per-run and monthly estimates with the caching discount modeled.

The guardrails inventory

What to configure before the pilot, organized by what each control bounds.

CONTROL	BOUNDS	WHERE IT'S SET
Explicit opt-in triggers	Who can start a run	Built-in; typed keyword, session setting, direct request, or named command
Human-origin gating	What can start a run	Built-in since v2.1.210
Size guideline	How big generated workflows aim to be	Config or settings files, org-wide if desired
Large-run warning	When humans get flagged	Built-in; >25 agents or >1.5M projected tokens
Budget ceiling	Hard token cap per directive	Per-prompt
Runtime caps	1,000 agents/run; ~16 concurrent	Built-in
Tool allowlist	What agents may do without asking	Session/org permission settings
Model allowlist	Which models agents may use	Org model settings
Kill switches	Whether workflows exist at all	User config, env var, managed settings, admin console

Five of these repay a paragraph.

Who can start a run. Every run begins with explicit opt-in (a keyword the user types, a session-level setting, a direct request in the user's own words, or an invoked command), followed by an approval prompt showing the planned phases, with the raw script one keystroke away. And since v2.1.210 the keyword only counts in prompts a human actually typed: webhooks, CI jobs, scheduled tasks, and pull-request comments cannot start a run by smuggling the word in. The trigger surface is deliberately human-shaped.

How big runs aim to be. The size guideline tells Claude what to target when it writes a workflow: small (under 5 agents), medium (under 15, the default), large (under 50), or unrestricted. It's advice to the script author, not a cap (a prompt that genuinely calls for more overrides it), but it moves the default heavily, and it's settable org-wide through settings files.

When you get warned. A run that schedules more than 25 agents or projects past 1.5 million tokens gets a visible “large workflow” advisory pointing at the live view. Two fine-print items surprise people, so here they are in the body text: a size guideline you chose replaces the 25-agent threshold with its own, and sessions running in the always-on ultracode mode don't show the warning at all, because turning that mode on is the consent to large runs. If that trade bothers you, the mode is visible and revocable.

What agents may do. Stated without varnish, because this is the paragraph your security review will quote: workflow subagents run in accept-edits mode and inherit the session's tool allowlist, regardless of the session's own permission mode. File edits inside the workspace are auto-approved. Shell commands, web fetches, and MCP tools outside the allowlist still prompt a human mid-run. The practical consequence: allowlist hygiene is workflow governance. Review the allowlist the way you'd review a CI runner's permissions, because that's what it is. Relatedly, an org model allowlist substitutes any disallowed model an agent requests and surfaces a warning naming both. Routing discipline holds even when a script asks for something it shouldn't.

The kill switches. Individuals can turn workflows off with a config toggle, a settings key, or an environment variable. Organizations can turn them off everywhere through managed settings or the admin console; disabling removes the bundled workflow commands, the trigger keyword, and the ultracode option, not just the front door. Assign an owner for that switch before the pilot, on the general principle that you install the brake before the engine.

Observability: attribute, audit, watch

Spend you can't attribute becomes a budget fight. Here's the attribution that exists.

Claude Code's OpenTelemetry stream tags workflow activity with the run id and the workflow's name (v2.1.202 and later), so per-workflow spend lands in whatever observability stack already ingests your telemetry. Naming matters more than it sounds: release-audit showing up in a dashboard supports a decision; an anonymous run id supports an argument. This is one reason to move teams from ad-hoc runs to named, saved workflows early. Attribution follows identity.

During a run, the live view shows per-phase and per-agent token totals with pause and stop: an audit trail that exists while the money is being spent, not after. And after a run, two artifacts persist: the orchestration script itself, written to disk on every run, and the journal recording what every agent actually returned. Read that back as a policy statement: every workflow run is reproducible, reviewable code plus a complete result log. Most automation your org already trusts (CI pipelines included) clears a lower bar than that, which is the honest counterweight to the black-box worry.

One norm to adopt as policy rather than advice: first run of any new workflow happens on a small slice, with the token view open. And one pointer for the practitioner track: what makes a workflow reviewable before it runs (argument contracts, code review norms, version pinning) is part four's subject.

Where the ROI is real, and the steelman

Three task shapes carry the economics comfortably. Verification-heavy work (audits, migration checks, large-PR review) where adversarial filtering substitutes machine tokens for scarce reviewer attention. Unknown-size discovery, where the script's loop guarantees the search actually runs to exhaustion instead of stopping when a model feels done. And org-wide sweeps too large for any single context to hold honestly.

Now the other side, conceded in full, because the strongest criticisms of this feature are correct as far as they go. The most-quoted launch-thread objection: throughput was never the bottleneck; review is, and a machine that produces more artifacts per hour makes the bottleneck worse. True. The “slop debt” worry: mediocre output compounding across agent passes until someone human pays the interest. Real. And the flagship demo, Bun's 750,000-line rewrite, drew expert skepticism about output quality, including tests that restated the implementation. Fair.

Notice what all three criticisms assume: workflows that generate. The policy line follows directly. Fund workflows that shrink the pile a human must review (verify, deduplicate, rank, filter) and decline workflows that merely produce more artifacts per hour. Which kind a given workflow is shows up in its structure: does it end with a verification phase and a ranked, deduplicated summary, or with forty raw outputs? You can check in the approval dialog, before it ever runs.

That line suggests the metric this whole post has been circling. Don't track findings produced; track reviewer-minutes per confirmed finding. The arithmetic, order-of-magnitude and labeled as such: a verified 90-agent audit costs a few dollars in tokens, and a loaded engineering hour costs something like $150. If the verification phase saves a reviewer even ten minutes of wading through false positives, it paid for the entire run twice over. A workflow that surfaces 12 verified findings beats one that dumps 60 unverified candidates, and the token bill is the cheap half of that comparison in every scenario I can construct.

A rollout playbook

Four phases, each with an exit criterion, so this is an operating plan rather than encouragement.

Phase one: pilot. One team, opt-in triggers only, size guideline left at the default, small-slice discipline as stated policy. Exit criterion: three named workflows the team reruns on purpose. Not three experiments, three habits.

Phase two: library. Promote the rerun workflows into the repo or a plugin, with code review, real names, and documented argument contracts; retire the personal one-offs. Exit criterion: a teammate who didn't write a workflow runs it successfully from its name alone. (Part four is the manual for this phase.)

Phase three: composition. Where multi-stage processes emerge, sequence the library's workflows under higher-level scripts instead of growing monoliths. Exit criterion: one end-to-end process (release readiness is the archetype) running as composed, individually-reviewed pieces. (Part five.)

Phase four: review. After a month, pull the telemetry by workflow name. Keep what pays under the reviewer-minutes metric, fix or retire what doesn't, and revisit the size guideline and the allowlist with real numbers instead of priors.

Day-one defaults, so nothing above waits on a meeting: guideline at medium, budget directives on anything large, the allowlist reviewed, kill-switch ownership assigned, and telemetry flowing before phase two starts.

What to do next

Three actions this week. Run /deep-research yourself on a real question from your own backlog; ten minutes watching the progress view fill in will change the quality of every subsequent conversation about this feature. Pick the pilot team and write down phase one's exit criterion where they can see it. And check whether your telemetry pipeline already captures the workflow attributes, because phase four depends on it and it's a five-minute question now versus a quarter-long gap later.

The division of labor for the series: parts two through five are what your pilot team reads; this post and part one are what you forward upward.