Claude Opus 4.8 Dynamic Workflows: How to Run Hundreds of Parallel Subagents Without Burning Your Budget

If you want to run a codebase-scale migration as hundreds of parallel subagents on Claude Opus 4.8 without a surprise bill, the move is architectural, not a model setting. Put cheap, well-scoped workers on the fan-out, keep one expensive coordinator that verifies the merged result before it reports back, and run the cheap workers on the fast mode that costs roughly a third as much in my mix. Opus 4.8 (released 28 May 2026) is good enough at long-horizon agentic work that the fan-out itself mostly works. The cost and the correctness are decided by how you scope the workers and where you spend your verification budget.

I have shipped enough agent systems to know that the demo and the invoice tell two different stories. This is the teardown I wish I had read before my first big parallel run.

What makes Opus 4.8 dynamic workflows different from a fixed script?

A dynamic workflow lets the model decide at runtime how to split the work, instead of you hard-coding the steps. That is the whole unlock for codebase-scale jobs, because you cannot enumerate 400 files and their dependencies up front, but a coordinator can.

In a fixed workflow you write the loop: read file, transform, write, next file. In a dynamic workflow you hand Opus 4.8 the goal and a fan-out tool, and it scopes the units of work itself, then delegates each one to a subagent. The coordinator holds the plan and the verification logic; the subagents hold one narrow task each and almost nothing else.

This matters because Opus 4.8 is noticeably more autonomous on long-horizon tasks than the models I was using a year ago, and it is more willing to commit to a plan when you give it the full task specification in the first turn. The flip side, which I will come back to, is that it is more conservative about reaching for delegation unless you tell it explicitly when to fan out. Left alone it will sometimes grind through 30 files in one serial context rather than spinning up 30 workers.

If you are still wiring up the basics of context handling for these runs, my piece on the context rot compaction playbook ↗ covers the long-running side that this article assumes you already have.

How do I scope a codebase migration into hundreds of subagents?

Scope by independent, verifiable units of work, not by file count. The right unit is the smallest change a single subagent can make and a single test can confirm, with no shared state with its siblings.

Here is the decomposition I actually use on a real migration, say moving a service off a deprecated date library across a large repo.

1. Survey pass (coordinator, standard Opus). One agent reads the dependency graph, finds every call site, and groups them into units. Grouping is the load-bearing step: files that import from each other go in the same unit so two workers never edit the same symbol in parallel.


2. Fan-out pass (subagents, fast mode). Each subagent gets one unit, the exact change to make, and a tight instruction set. It edits, runs the unit's tests, and reports a structured result. Nothing else.


3. Verification gate (coordinator, standard Opus). The coordinator collects results, re-runs the full build, and only then decides whether to report success or re-dispatch the failures.

You are migrating ONE file off `oldlib.parseDate`.
Rule: replace `oldlib.parseDate(x)` with `newlib.fromISO(x)`.
For `oldlib.format(d, fmt)` use `newlib.toFormat(d, mapFmt(fmt))`.
Do NOT touch imports outside this file. Do NOT refactor anything else.
After editing, run: `pytest tests/test_<module>.py`
Report: {file, edits_made, tests_passed, blockers}

On "hundreds of parallel subagents": that is the conceptual model, and it is the right one. In practice your real concurrency is capped by your rate limits and your harness, so you dispatch in batches. The coordinator does not need 300 workers live at once; it needs 300 units of work and a queue. With prompt caching on the shared migration rule, batching is also where most of your savings come from, because the stable prefix gets cached once and read cheaply by every worker in the batch.

For the defensive side of fanning out untrusted work, the agent architecture that survives prompt injection ↗ is worth reading alongside this, since every subagent that touches external content is an attack surface.

What is the verification gate, and why does it run before reporting back?

The verification gate is the coordinator's pass that checks the merged result of all subagents before it tells you the job is done. It exists because parallel workers are individually confident and collectively wrong, and you do not find that out until something downstream breaks.

Each subagent reports "tests passed" for its own unit. That is not the same as the system working. Two workers can both pass their local tests and still produce a merge that fails the full build, because unit A changed a signature that unit B's local test stubbed out. The gate re-runs the whole build and the integration tests on the combined diff, in a fresh coordinator context, before any success is reported.

This is where I spend my expensive tokens deliberately. The gate runs on standard Opus at high effort, because catching a real failure here is far cheaper than the rework if I let it through. The pattern in practice:

• Workers report structured results, not prose.


• The coordinator re-runs the full test suite once, not per worker.


• Failures get re-dispatched as a small second batch with the failure output attached.


• Only after the second batch passes does the coordinator report back.

If you want to make this rigorous, score the whole trajectory rather than just the final answer. My write-up on evaluating AI agents in CI with trajectory scoring ↗ is the approach I use to turn "the gate passed" into something I can regression-test.

What does a parallel subagent run actually cost on Opus 4.8?

Cost is dominated by output tokens and by rework, not by how many workers you run. Opus 4.8 is priced at $5 per million input tokens and $25 per million output tokens, so the worker that writes a 2,000-token diff costs you far more on the output side than on the input side, and the worker you have to run twice costs double for no new result.

Here is the model I use to estimate a run before I press go. The numbers below are an illustrative 300-unit migration with prompt caching on the shared rule; your mix will differ, but the shape holds.

The single biggest lever is putting the fan-out on the fast mode. Three hundred workers on standard Opus is the version of this that produces the scary screenshot. The same fan-out on the cheaper variant, with the coordinator and the gate kept on standard Opus, is the version that ships.

The second biggest lever is prompt caching. The migration rule, the repo conventions, and the tool definitions are byte-identical across every worker in a batch. Cache that prefix once and every subsequent worker reads it at roughly a tenth of the input price. On a 300-worker run that is the difference between paying for the rule 300 times and paying for it once. The catch is that caching is a prefix match, so a timestamp or a per-worker ID interpolated into the front of the prompt silently invalidates it. Keep the volatile bits, the file path and the unit-specific detail, at the end of the worker prompt.

When is the fast mode the wrong choice?

Fast mode is the right default for cheap, well-specified workers and the wrong choice for anything that has to reason about ambiguity. The 3x saving is real, but it comes from a model variant that scopes its work more tightly, which is exactly what you want on a worker and exactly what you do not want on the coordinator.

I keep three jobs on standard Opus at high effort no matter what:

• The survey pass, because bad grouping poisons the entire run.


• The verification gate, because a missed failure here is the most expensive mistake in the pipeline.


• The re-dispatch decision, because deciding whether a failure is a worker bug or a scoping bug is a judgment call.

A few more practical settings that affect the bill:

• Set effort per role. Workers at medium or low, coordinator and gate at high. On Opus 4.8 effort is a real cost lever, and lower effort means terser, more consolidated tool calls.


• Use a task budget on the coordinator. The model sees a running countdown and wraps up gracefully instead of exploring forever. It is a suggestion, not a hard cap, so pair it with max_tokens as the enforced ceiling.


• Tell the model when to fan out. Opus 4.8 under-reaches for subagents by default. A line like "delegate to subagents when the task fans out across independent files; work directly for single-file edits" measurably raises the delegation rate.

The honest take

Opus 4.8 makes the fan-out itself a solved problem for most codebase-scale work. It plans well, it follows a clear up-front spec, and it produces correct individual edits more often than the models I used before it. That is genuinely new and worth the attention it is getting.

What has not changed is that the cost and the correctness live in your architecture. Cheap workers, an expensive coordinator that verifies before it reports, fast mode on the fan-out, prompt caching on the shared prefix, and a gate that re-runs the full build on the merged result. Get those right and a 300-unit migration is a single-digit-to-low-tens-of-dollars job that finishes in one sitting. Get them wrong and you pay several times more for output you then have to debug by hand.

If you want help putting agentic workflows like this to work without the bill surprising you, that is part of my AI solutions ↗ work.

If you are weighing whether to build this for your own codebase or want a second pair of eyes on a run that overspent, my contact page ↗ is the easiest way to reach me. I would rather talk through your scoping than watch you re-dispatch 200 workers.