Anthropic shipped dynamic workflows alongside Opus 4.8 on May 28, 2026 (announcement). The feature is a Claude Code research preview that lets a single session run hundreds of parallel subagents: an orchestrating agent splits a large task into independent work units, executes them concurrently, then verifies and synthesizes the results. Four months on, it is still labeled a research preview, while the model lineup around it has kept moving. Fable 5 launched in June, had access suspended for 19 days, and the current top tier in Anthropic’s docs is Fable 5.1.
This piece covers what the architecture looks like, which patterns fit the model well, and what running parallel subagents costs at current prices.
What dynamic workflows actually are
Dynamic workflows is a Claude Code research preview (Opus 4.8 announcement). The announcement describes it only as a Claude Code capability, not an API-level primitive: Claude plans the work, runs hundreds of parallel subagents in a single session, and then “verifies its outputs before reporting back to the user.” It is available on Claude Code for Enterprise, Team, and Max plans. Anthropic’s flagship example is a codebase-scale migration across hundreds of thousands of lines of code, from kickoff to merge, with the existing test suite as the bar.
The term “dynamic” distinguishes this from static multi-step pipelines where the number and sequencing of agents is fixed at design time. In a dynamic workflow, the orchestrating agent decides at runtime how many subagents to spawn and what work to assign each one, based on the structure of the problem it is solving. The orchestrator can fan out to many workers, wait for completion, then synthesize the results.
Opus 4.8 was the launch tier, and the announcement notes that on it “the agents can run for even longer.” The model landscape has shifted since: as of early October 2026, Anthropic’s model overview lists Opus 4.8 among the legacy models, with Fable 5.1, Opus 5.5, Sonnet 5.5, and Haiku 4.5 as the current lineup. Every current Fable, Opus, and Sonnet model carries a 1M-token context window, a generation that began with Opus 4.7’s tokenizer, so any of them can hold substantial state about in-flight subagent tasks. The docs recommend Fable 5.1 for “demanding reasoning and long-horizon agentic work,” which is exactly the profile of a heavy orchestration session.
The launch findings on model behavior still matter for orchestration quality. Anthropic’s evaluations found Opus 4.8 “around four times less likely than its predecessor to allow flaws in code it has written to pass unremarked,” and early testers reported it more likely to flag uncertainties and less likely to make unsupported claims (announcement). In an orchestration loop, those properties reduce how often a wrong or incomplete subagent output silently propagates into the final synthesis.
How map-reduce fits the parallel subagent model
Map-reduce is the most natural pattern for dynamic workflows. The orchestrator receives a problem that decomposes into N independent units of work, assigns one subagent per unit (the map phase), waits for all subagents to complete, then synthesizes the collected outputs into a final result (the reduce phase).
Concrete examples where this decomposition is clean:
- Repository-wide code audits. The orchestrator identifies N modules or packages, assigns one subagent per module to audit it against a checklist, then aggregates findings into a ranked issue list. Because modules are largely independent, the map phase can run fully in parallel.
- Multi-source research synthesis. The orchestrator receives a list of sources, assigns one subagent per source to extract claims and evidence, then reduces to a reconciled summary. The reduce phase is where the reduced rate of unsupported claims matters: the synthesizing agent is less likely to introduce invented deltas when merging subagent outputs.
- Test suite generation. Given a set of functions or API endpoints, the orchestrator fans out to one subagent per target, each writing tests independently, then merges the test files and resolves any import or fixture conflicts.
Map-reduce works best when the work units in the map phase are genuinely independent: no shared mutable state, no ordering constraints, no subagent needing the output of another subagent before it can proceed.
For a sense of the intended ceiling, Anthropic relays a report from Stripe’s early testing in which Fable 5 completed a codebase-wide migration across a 50-million-line Ruby codebase in a day, work estimated at over two months for a team by hand (Fable 5 announcement). That is a vendor-relayed customer claim, not an independent measurement, but it shows the migration workload these sessions are being built around.
Fan-out-fan-in for dependent subtasks
Fan-out-fan-in extends map-reduce to handle cases where subagents have partial dependencies. In a pure fan-out, all subagents start simultaneously. In fan-out-fan-in, the orchestrator may start a first wave of subagents, wait for a subset to complete, then start a second wave that consumes the first wave’s outputs before the full reduce phase.
A practical example: a refactoring task that requires (1) understanding the existing API contract, (2) proposing a new interface in parallel across multiple modules, then (3) updating call sites once the new interface is agreed. Phases 1 and 3 are sequential relative to phase 2, but within phase 2 the module proposals are parallel. The orchestrator fans out for phase 2, collects the interface proposals, reconciles them, then fans out again for phase 3.
What the launch materials support about Opus 4.8 here is directional rather than a scoreboard. The announcement describes the model as building “on Opus 4.7 with improvements across benchmarks” and refers readers to a comparison table and the Opus 4.8 System Card for per-benchmark detail (announcement). Among the early-tester feedback it relays, one report has Opus 4.8 ahead of prior Opus models on CursorBench across every effort level, with tool calling that needs fewer steps for the same intelligence. That last property is the one that compounds in a fan-out: a hundred subagents that each finish their unit in fewer tool calls burn less context and less budget per wave. The current model overview page lists no per-benchmark scores for Opus 5.5 or Fable 5.1, so treat these as launch-cycle comparisons rather than a standing leaderboard.
When parallel beats sequential
Parallel subagents are faster for work that is decomposable and where the bottleneck is latency per unit of work, not dependencies between units. They are not better for every task.
Parallel wins when:
- Work units are independent (no data hazards between subagents).
- The task has enough volume that fan-out setup overhead is small relative to total work. Spawning a hundred subagents for a task that would complete in two sequential steps is not efficient.
- The reduce phase is straightforward. If synthesizing outputs requires complex reconciliation logic that takes as long as the map phase, the parallelism gain shrinks.
Sequential wins when:
- Each step depends on the prior step’s exact output.
- The task requires accumulated context that would be expensive or lossy to reconstruct from independent subagent outputs.
- The total work is small enough that coordination overhead dominates.
The practical threshold depends on how much time each subagent task takes versus how much overhead the orchestrator adds. For tasks where each work unit takes several seconds or more, fan-out is almost always faster wall-clock. For trivial tasks measured in milliseconds, the overhead of spawning subagents erases the gain.
Coordination overhead and the orchestrator’s role
Every parallel workflow has coordination overhead: the orchestrator must dispatch tasks, track which subagents have completed, handle failures or stalls, and aggregate results. In dynamic workflows on Claude Code, this coordination runs within the same session (announcement).
Runtime length matters just as much. The announcement notes that agents “can run for even longer” on Opus 4.8, and the Fable 5 launch extends the same property (“work autonomously for longer than any previous Claude models”). For a session managing dozens or hundreds of subagents, fewer interruptions mean the orchestrator proceeds further into the fan-in phase before it has to surface a decision to the user.
One launch recommendation bears on this directly. Opus 4.8 defaults to high effort; Anthropic recommends “extra” effort (“xhigh” in Claude Code) for difficult tasks and long-running asynchronous workflows, and says it raised Claude Code rate limits to absorb the higher token usage of higher effort levels (announcement). A hundred-subagent orchestration session is squarely that kind of workload, but higher effort also raises per-subagent token burn, so it compounds the arithmetic in the next section.
Cost per parallel task on Opus 4.8 and Fable 5.1
Opus 4.8 still prices at $5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.7 (Opus 4.8 announcement, Opus 4.7 announcement). It is no longer the price anchor of the lineup, though: the current model overview lists Opus 5.5 at $4/$20 and Fable 5.1 at $10/$50, the same rate Fable 5 launched at in June (Fable 5 announcement). Fast mode on Opus 4.8 runs at $10/$50 and 2.5x speed, which Anthropic says makes it three times cheaper than fast mode was on previous models (announcement).
In a parallel workflow, each subagent consumes tokens independently, so total cost scales with subagent count and token volume per subagent, not with wall-clock time saved. A hypothetical example at Opus 4.8’s published rates of $5/$25 per million tokens (announcement): a 100-subagent fan-out where each subagent uses 2,000 input tokens and 500 output tokens burns 200,000 input tokens ($1.00) plus 50,000 output tokens ($1.25), or $2.25 for the map phase. The same map phase on Fable 5.1’s $10/$50 rates costs $4.50 (models overview). The orchestrator’s own usage, spanning dispatch, monitoring, and the synthesize phase, adds on top, and that overhead grows with reduce complexity more than with subagent count.
Model choice for large workflows comes down to whether Fable 5.1’s capability headroom reduces errors and retries enough to offset double Opus 4.8’s token cost. Where orchestration quality is the bottleneck (complex fan-out-fan-in coordination, high-stakes synthesis), the docs’ own recommendation of Fable 5.1 for long-horizon agentic work argues for paying it. For high-volume, lower-stakes map phases, the cheaper tiers win, and Opus 5.5 now undercuts Opus 4.8 outright at $4/$20 (models overview).
One operational wrinkle when orchestrating on Fable: at Fable 5’s launch, its safeguards automatically routed cybersecurity, biology and chemistry, and distillation queries to Opus 4.8, with users informed when it happened. Anthropic’s early data showed more than 95 percent of Fable 5 sessions involved no fallback at all (Fable 5 announcement), but that figure is per-session. A hundred-subagent security audit issues a hundred queries against that classifier surface, so some subagent work may run on the fallback model regardless of which tier you selected. That routing was documented for Fable 5 specifically; the current models overview page does not cover Fable 5.1’s classifiers or its fallback target, so verify current behavior before pinning a large audit to that tier.
For reduce phases generating large synthesis documents, the Message Batches API accepts up to 300k output tokens on Opus 4.8 and on the current Opus and Sonnet tiers via the output-300k-2026-03-24 beta header, against a 128k synchronous limit (models overview). Fast mode’s 2.5x speed at double the token price (announcement) applies to long orchestration sessions as well; for the arithmetic, see Claude Code fast mode pricing.
What the research preview status means in practice
Dynamic workflows was still described as a research preview in September 2026, four months after launch (announcement). That means the interface and behavior remain subject to change while Anthropic collects real-world usage data, and the current implementation may have edge cases (subagent failure handling, session state under high fan-out counts, orchestrator context limits) that are not fully documented. Teams building on it should validate behavior at their intended fan-out counts before committing to it as a dependency.
Model access can also pause independently of the feature. Fable 5 and Mythos 5 access was suspended on June 12, 2026 and restored July 1 (Fable 5 announcement), a 19-day window in which workflows pinned to that tier lost their model outright. A production orchestration setup needs a plan for both kinds of instability: a preview feature that may change shape, and a model tier that may briefly disappear.
The capability is real and demonstrated, but treating a research preview as a stable production primitive carries the same risks it always has.
Join the discussion
Share a useful perspective or ask a question about this article.