Opus 4.8 ships Dynamic Workflows — hundreds of parallel subagents per session. Read this before you wire it into prod.

Anthropic's Opus 4.8 announcement on May 28 spent most of its word count on benchmarks. CursorBench up. Terminal-Bench 2.1 beats GPT-5.5. OSWorld-Verified at 82.3%. Online-Mind2Web at 84%. The legal-agent benchmark broke 10% on all-pass for the first time. Those are the numbers the headline writers grabbed.

Buried under the benchmark table is the line that actually changes how you ship agents:

Dynamic Workflows. Run hundreds of parallel subagents. Handle codebase-scale migrations spanning hundreds of thousands of lines.

That is not a benchmark. That is a new programming model. And it is shipping as a preview, which means the defaults are not what they will be in 90 days. If you are running agents in production and you do not pin your config before the next minor release, your bill is going to surprise you.

Here is what the preview actually does. Three tasks it eats alive. One class of work where it loses you money. And the exact config to pin before the dynamic-workflow defaults move under you.

What Dynamic Workflows actually changed

Before 4.8, parallel subagents on the Anthropic stack meant one of two things. Either you called the Agent tool from inside Claude Code and got a fixed number of side-task subagents — usually capped somewhere around four or eight concurrent. Or you wrote your own orchestrator in TypeScript or Python, called the Messages API in a Promise.all, and handled the queueing yourself.

The Agent path was ergonomic but capped. The DIY path was uncapped but the orchestration was your problem — retries, structured output validation, cache invalidation, all of it.

Dynamic Workflows in 4.8 collapses both. You write a script — JavaScript, not a separate orchestrator binary — that calls agent(), parallel(), pipeline(), and phase() as primitives. The runtime handles concurrency, structured output validation against JSON Schema, retries on validation failure, and progress reporting. The concurrency cap is min(16, cpu_cores - 2) per workflow. The lifetime cap is 1,000 agents per workflow, set as a backstop against runaway loops.

The "hundreds of parallel subagents" line is not marketing. You can hand pipeline() an array of 800 items and every one runs. The cap is on simultaneous in-flight, not on total dispatched.

Here is the smallest workflow that demonstrates the shape:

export const meta = {
  name: 'review-changed-files',
  description: 'Review changed files across dimensions, verify each finding',
  phases: [{ title: 'Review' }, { title: 'Verify' }],
}

const DIMENSIONS = [
  { key: 'bugs', prompt: 'Find bugs in this diff. Return findings with file, line, severity.' },
  { key: 'perf', prompt: 'Find performance regressions in this diff.' },
  { key: 'sec',  prompt: 'Find security issues in this diff.' },
]

const results = await pipeline(
  DIMENSIONS,
  d => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS_SCHEMA }),
  review => parallel(review.findings.map(f => () =>
    agent(`Adversarially verify: ${f.title}`, {
      label: `verify:${f.file}`,
      phase: 'Verify',
      schema: VERDICT_SCHEMA,
    }).then(v => ({ ...f, verdict: v }))
  ))
)

const confirmed = results.flat().filter(Boolean).filter(f => f.verdict?.isReal)
return { confirmed }

Three things to notice. First, pipeline() is not a barrier — dimension bugs can be in the verify stage while dimension perf is still in review. The default control flow is streaming, not waterfall. Second, schema: forces the subagent to call a StructuredOutput tool — validation happens at the tool-call layer, not by parsing free text. You do not need a JSON.parse(try/catch) block. Third, the budget is shared. Every subagent counts against budget.spent() which the parent script can read mid-flight to scale down depth on the fly.

If you've been writing your own orchestrator on top of the Messages API, this replaces it. Not augments — replaces.

Why it matters: the 4× honesty number, not the 84%

The headline benchmarks are real but they are not what makes Dynamic Workflows load-bearing. The number that makes the feature usable is buried in the model card: Opus 4.8 is ~4× less likely to allow code flaws to pass unremarked than 4.7.

That sentence sounds like a marketing claim until you think about what fan-out actually does to error rates. If a single subagent has a 5% false-positive rate on "this is a real bug," running fifty of them in parallel produces a finding list that is mostly noise. The reviewer-overhead curve is brutal. You get more findings, you trust each one less, you triage longer, you stop using the workflow.

Drop the false-positive rate by 4× and the curve inverts. Fifty subagents at a ~1% rate produces a list you can actually read in fifteen minutes. The fan-out becomes worth it. This is the precondition that makes the workflow feature viable; without the honesty improvement, hundreds of subagents would just amplify the slop.

Number two: tool-calling efficiency. Anthropic's release notes say 4.8 uses "meaningfully fewer steps" per task. That matters because Dynamic Workflows charge you per agent per phase. A workflow that fans out to 200 subagents where each used to take 12 tool calls and now takes 7 is not 1.7× cheaper — it is 1.7× cheaper and 1.7× faster and 1.7× less likely to hit a rate limit. The compounding is what makes the feature economic.

Number three: the Messages API change. System entries are now accepted mid-task without breaking the prompt cache. Read that one twice. In the 4.7-and-prior world, injecting a new system instruction during a long-running agent run blew the cache for every prior turn. In 4.8, you can do it. Which means a workflow that runs for an hour, with the parent script injecting fresh context based on what subagents returned, keeps cache hit rates that were previously only available to one-shot prompts. The Dynamic Workflows feature would not be cost-viable without this change.

The three numbers compound. 4× honesty × 1.7× efficiency × cache-stable mid-task injection. That is why the preview can actually ship hundreds of subagents and not just five.

Mechanism: what `pipeline()` does that `parallel()` does not

The two control-flow primitives look similar in the docs. They are not. The distinction is the one mistake every team makes in their first three Dynamic Workflows.

parallel(thunks) is a barrier. It awaits every thunk before returning. If you have ten subagents and one of them takes 90 seconds while the other nine take 10 seconds, the call returns at 90 seconds. The fast nine sit idle for 80 seconds.

pipeline(items, stage1, stage2, ...) is not a barrier. Each item flows through all stages independently. Item A can be in stage 3 while item B is still in stage 1. The wall-clock cost is the slowest single-item chain, not the sum of slowest-per-stage.

For a two-stage workflow — find then verify — the math is the difference between:

parallel of 50 finds, then parallel of all-findings-verify: max(find_times) + max(verify_times)
pipeline of (find then verify) for 50 items: max(find_time + verify_time) for one item

For reviews where find times vary 3× across dimensions, pipeline is roughly 50-60% faster wall-clock. The cost is the same — same number of agent calls. Only latency moves.

The barrier is correct in exactly three cases. First, when stage N needs cross-item context from all of stage N-1 — dedup across the full finding set, for example, before expensive downstream work. Second, when you need an early-exit signal that depends on the full set — "if zero bugs were found, skip verification entirely." Third, when the prompt of stage N literally references "the other findings" for comparison.

Everything else should be pipeline. The default-to-barrier instinct from Promise.all muscle memory is the single biggest source of wasted wall-clock in dynamic workflows.

Here is the corrected pattern, written so a future reader can see the shape:

// WRONG — parallel barrier between stages
const found = await parallel(DIMENSIONS.map(d => () => agent(d.prompt, { schema: BUGS })))
const flat = found.filter(Boolean).flatMap(r => r.bugs)
const verified = await parallel(flat.map(b => () => agent(verifyPrompt(b), { schema: VERDICT })))
// Wall-clock = slowest find + slowest verify. Fast finds sit idle.

// RIGHT — pipeline, verify starts as each find returns
const verified = await pipeline(
  DIMENSIONS,
  d => agent(d.prompt, { schema: BUGS }),
  findings => parallel(findings.bugs.map(b => () =>
    agent(verifyPrompt(b), { schema: VERDICT })
  ))
)
// Wall-clock = slowest (find + verify) for one dimension's chain.

Opposing view: "we already had this with our own orchestrator"

I have seen this argument three times this week. The shape: "We already wrote a TypeScript orchestrator that calls the Messages API in Promise.all. We have retries. We have structured output. We have progress reporting. Dynamic Workflows is a wrapper around something we already do."

It is not wrong. It is just incomplete.

What the orchestrator-already-built crowd is missing is the cache-sharing model. A DIY orchestrator that calls the Messages API from your code is hitting Anthropic's API as a fresh client per call. Each call carries its own prompt cache state. Workflow agents share the parent run's concurrency cap, agent counter, abort signal, and — critically — token budget. The budget is pooled across the main loop and all workflows. budget.spent() in a workflow reads from the same counter as the main agent. You cannot replicate that from outside.

The second thing the DIY crowd misses is structured output validation at the tool-call layer. The Workflow runtime forces a StructuredOutput tool call on the subagent. If validation fails, the model retries — automatically, inside the subagent's own loop, without round-tripping to your orchestrator. From the parent's perspective, the call returns a validated object or it throws. There is no parsing step. There is no schema-mismatch fallback. You have been writing the same if (parsed?.findings) defensive check in every orchestrator for two years. The runtime eats that check.

The third thing is the concurrency cap. Your DIY orchestrator does not know about other workflows running in the same session. The Workflow runtime caps at min(16, cpu_cores - 2) per workflow, but it also coordinates across nested workflows — workflow() called from inside a workflow shares the parent's cap. You did not write that. You cannot write that from outside.

This is not a wrapper. It is a runtime that owns the cache, the budget, and the concurrency. Three things your DIY code touches but does not own.

There is a fourth thing, less obvious: resume. The Workflow runtime journals every agent() call. If your script crashes, or if you stop and edit it and rerun, the runtime replays the longest unchanged prefix from cache and only runs the edited or new calls live. Same script plus same args equals 100% cache hit. Your DIY orchestrator, hand on heart, does not do this. You re-run the whole pipeline and re-pay. On a 200-agent workflow that re-pay is meaningful — easily a $40 difference per failed run on an Opus-heavy script.

The right read on Dynamic Workflows is: it makes the orchestrator-already-built code obsolete in 60 days, not because your code is bad but because the new runtime owns the substrate. Plan the migration. The teams that move first will be the ones whose existing orchestrators are most painful to maintain — which is, in my experience, every team that wrote one more than six months ago.

Playbook: pin these three configs before the defaults move

Dynamic Workflows is a preview. Previews change. Three things will almost certainly drift in the next minor release, and if you have not pinned them, your behavior will silently change.

One: pin the concurrency cap explicitly. The default is min(16, cpu_cores - 2). If Anthropic raises the per-workflow ceiling to 32 in a minor release — which the docs hint is on the roadmap — your existing workflows will start dispatching twice as many concurrent calls. Most of them will be fine. The ones that hit a downstream rate limit (your database, your CI system, the external API you are calling from a tool) will not be fine.

There is not a public API for explicit cap-setting yet, so the practical workaround is to chunk your work yourself: pass items to pipeline() in batches of N rather than handing it the full list. The runtime will not dispatch more than N concurrently because there are not more than N in flight.

Two: pin the model on every agent() call where it matters. The opts.model parameter on agent() is optional. If omitted, the subagent inherits the main-loop model — which is the session model, which can change. If you wrote your workflow under 4.8 and you depend on the 4× honesty improvement, set model: 'claude-opus-4-8' explicitly on every adversarial-verify agent. When a session falls back to 4.7 — which can happen during 4.8 outages, and has happened twice in the last 30 days — your verify step's false-positive rate jumps 4×. Pin it.

Three: pin the token budget. The budget.total value is null if no target was set. budget.remaining() returns Infinity in that case, and your loop-until-budget pattern runs straight to the 1,000-agent backstop. The 1,000-agent cap exists for a reason — it has been hit in production within the last 30 days by a workflow that scaled depth proportional to budget.remaining() and assumed it was bounded.

The pattern that breaks:

// DON'T — loops to the 1000-agent cap if budget.total is unset
const findings = []
while (budget.remaining() > 50_000) {
  const result = await agent('Find more bugs.', { schema: BUGS })
  findings.push(...result.bugs)
}

// DO — guard explicitly on budget.total
const findings = []
while (budget.total && budget.remaining() > 50_000) {
  const result = await agent('Find more bugs.', { schema: BUGS })
  findings.push(...result.bugs)
}

This is a one-character fix. The cost of not making it is real money, fast.

Four (bonus): cap your loop-until-dry pattern. The loop-until-dry pattern — keep spawning finders until K consecutive rounds return nothing new — is one of the strongest workflow shapes for exhaustive discovery. It also has no natural upper bound. If your fresh-finding deduplication has a bug, the loop spawns infinitely. The 1,000-agent backstop will catch it eventually, but you will have paid for several hundred wasted subagents by then. Wrap every loop-until-dry in an outer round counter — while (dry < 2 && rounds < 20) — and log when the outer counter trips. That log line is your canary for a broken dedup, and it has saved teams real money in the last 30 days.

Want my pinned-config snippet? Reply with your workflow shape and I will rewrite it.

When it breaks: the one task class where 4.8 loses you money

Dynamic Workflows is not free. Per-agent overhead is roughly 200-500ms of setup before the first token. Most workflows amortize this trivially — a 30-second subagent does not care about a 300ms setup. But two task classes break the economics.

First class: workflows where each subagent makes one tool call and returns. If your subagent's job is to "fetch this URL and return the title," you have written a parallel HTTP client with a $0.005 tax per call and 300ms of setup overhead. The right answer is Promise.all(urls.map(fetch)) in your orchestrator. Do not put it in a workflow. You will pay 10× the cost and gain nothing.

Second class: workflows that use isolation: 'worktree' defensively. The worktree isolation flag spins up a fresh git worktree per subagent. It is the right answer when subagents mutate files concurrently and would otherwise conflict. It is the wrong answer everywhere else. Worktree setup is 200-500ms plus disk I/O per agent. Used as a "just to be safe" default, it makes a 50-agent fan-out cost an extra 25 seconds of wall-clock and a noticeable disk footprint. The Anthropic docs are explicit: it is "EXPENSIVE." Use it only when you have proven the conflict.

The broader pattern: Dynamic Workflows is optimized for the case where the subagent does meaningful work. Stage your decision on the per-agent floor cost. If your subagent's expected runtime is under 5 seconds and it is not doing model inference, you have probably picked the wrong tool.

A related anti-pattern I have already seen twice: using a workflow to fan out 30 subagents that each call the same external API with a different ID, then aggregating. This is a parallel HTTP client wearing a workflow costume. The model is doing no work — it is constructing one tool call, waiting for it, and returning the result verbatim. You are paying per-token costs to do curl. The correct shape is one subagent that calls the API in a loop with the IDs in its tool, or — better — your orchestrator doing the Promise.all and only invoking the workflow to interpret the aggregated result. Reserve subagents for the part of the job that benefits from independent context windows. That is the whole reason the runtime exists.

Non-obvious takeaway: the meta is shifting from skill to harness

For the last 12 months the model-comparison meta has been about skills — your Claude Code skill collection, your Cursor rules, your Copilot instructions. The capability differentiator was "which assistant has the better domain skill for my stack."

Dynamic Workflows shifts that. The differentiator is now the harness — the orchestration shape you wrap around the model. Two teams with the same skills, the same model, the same prompt, will get different results based on whether they fan out adversarial verifiers, whether they use pipeline or parallel, whether they have a completeness critic at the end.

The trending GitHub repos are already moving. revfactory/harness showed up in trending this week — "a meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use." The cursor/plugins spec, also trending this week, bundles MCP servers, skills, rules, and orchestration patterns into a single deployable unit. Both moves are toward the harness being the unit of value, not the skill.

The bet I am making: in 90 days, the conversation about which model is best for coding will be subsumed by which harness is best for coding. The harness will pick the model per phase. The model will be a commodity input. The orchestration will be the moat.

If you are building agent infrastructure, this is the time to stop optimizing your skills and start writing your harness. The skill collection is a flat investment that decays as models change. The harness compounds across model releases — the same workflow that ran on 4.7 with worse verifiers runs better on 4.8 with no changes.

Which brings me to the one thing you should not do this week: do not migrate every existing agent to a Dynamic Workflow. The right targets are the ones where you already wished you had parallel subagents — code review, migration sweeps, multi-source research. The ones where you are fanning out for completeness, not for speed. For everything else, the single-agent path is still cheaper and faster.

What to do this week

Audit your DIY orchestrators. Find every Promise.all of messages.create calls in your codebase. List them. Sort by call volume. The top three are your migration targets for Dynamic Workflows. Estimated time: two hours.
Write one workflow end-to-end. Pick a task you do weekly — code review across changed files, dependency audit, content moderation pass. Write it as a pipeline with adversarial verify. Pin the model. Pin the budget. Ship it as a script. Estimated time: one afternoon.
Add the budget guard everywhere. Open every existing orchestrator that has a loop-until pattern. Add the budget.total && guard. This is the cheapest insurance you will buy this month. Estimated time: thirty minutes.

If you want a second pair of eyes on a workflow before you ship it, send me the script — I will run it through the checklist and send back the three things I would change.

The headline of Opus 4.8 is the benchmark numbers. The actual story is the runtime. Pin your config before the defaults move, and you will be using this in 90 days. Wait, and you will be debugging it.

推荐订阅源

DEV Community