On May 28, 2026, Anthropic shipped dynamic workflows in Claude Code. The headline number is dramatic: Claude can now write its own orchestration scripts that run tens to hundreds of parallel subagents in a single session, with independent verifier agents checking work before it reaches you.

The proof point is louder than the announcement. Jarred Sumner (the creator of Bun) used dynamic workflows to port the entire Bun runtime from Zig to Rust. Roughly 750,000 lines of Rust. 99.8 percent of the existing test suite passing. Eleven days from first commit to merge. One workflow mapped Rust lifetimes for every struct field in the Zig codebase. Another wrote every .rs file as a behavior-identical port, with hundreds of agents working in parallel and two reviewers on each file. A fix loop drove the build and test suite until both ran clean.

That is genuinely a different category of engineering work than what was possible six months ago.

But there's a sentence buried three times in Anthropic's own announcement that nobody is leading with: "dynamic workflows can consume substantially more tokens than a typical Claude Code session." It appears in the launch note, in the documentation, and in the in-product warning when you first trigger a workflow. Anthropic is telling you, repeatedly, that this is expensive.

This post is the honest builder read on what dynamic workflows are, what they're worth, and what the token economics actually look like once you scale them past a demo.

What Dynamic Workflows Actually Are

The mechanics matter, because they explain both the power and the cost.

When you trigger a workflow, Claude plans dynamically based on your prompt, breaks the task into subtasks, and fans the work out across subagents running in parallel. Each subagent gets its own context window and its own slice of the problem. Results are checked by separate verifier agents before they're folded back in. The coordination happens outside the conversation, which is why a workflow can stretch into hours or days without losing the plot.

There are two ways to start one. You can ask Claude directly ("create a workflow for this"), or you can switch on a Claude Code setting called ultracode that sets the effort level to xhigh and lets Claude decide on its own when a task is workflow-shaped.

The use cases Anthropic surfaces in the launch are concrete:

• Codebase-wide bug hunts, profiler-guided audits, and security audits. Claude searches in parallel, then runs independent verification on every finding so the final report surfaces real issues instead of hallucinated ones.
• Large migrations and modernization. Framework swaps, API deprecations, language ports that touch thousands of files.
• Critical work that needs double-checking. When the cost of a wrong answer is high, the workflow gives Claude independent attempts at the problem plus adversarial agents trying to break the result before you see it.

That last pattern is the most interesting one from a software engineering perspective. The workflow doesn't just produce an answer. It produces an answer that has already been attacked by other agents specifically designed to refute it. The iteration continues until the answers converge.

This is a meaningfully different shape than what came before. Most agent tooling so far has focused on two layers: the outer-loop orchestrators (Devin, Symphony, Composio's Agent Orchestrator) that turn tickets into agent workspaces, and the tool surfaces (MCP servers, API integrations) that agents call from inside those workspaces. Dynamic workflows are a third thing: an internal orchestrator inside Claude Code itself, where Claude is now its own subagent manager.

The agent stack just got another layer.

The Bun Proof Point, Read Carefully

The Bun rewrite is the most quoted example for good reason. It's also the example most worth slowing down on, because the headline numbers hide the operational reality.

What actually happened: hundreds of Claude agents working in parallel for eleven days. Two reviewer agents on every single ported file. A fix loop iterating against the build and test suite until both passed. An overnight workflow afterward that addressed unnecessary data copies and opened a PR for each.

That is a lot of agent-hours. A lot of context windows. A lot of model invocations.

Anthropic hasn't published the token cost of the Bun port. We can guess at the order of magnitude. 750,000 lines of Rust, two reviewers per file, iterative fix loops on a build that probably broke many times before it ran clean, overnight optimization passes after the port landed. Even with aggressive caching and prompt optimization, you're looking at billions of tokens consumed across the eleven days. The dollar number is genuinely hard to estimate without internal data, but it's almost certainly in the tens of thousands of dollars, possibly six figures, depending on which Claude variant the subagents ran on.

This isn't a criticism of the rewrite. For a project where the alternative was months of senior engineering time at much higher cost, the math probably works. The point is that the math isn't a small calculation anymore. The unit economics of dynamic-workflow engineering need a different mental model than "I'll just spin up Claude Code and see what happens."

The Three-Times Warning Deserves a Section

Anthropic's launch post mentions the token cost warning three separate times:

1. In the intro note: "dynamic workflows can consume substantially more tokens than a typical Claude Code session"
2. In the "how it works" section: "dynamic workflows consume meaningfully more usage than a typical Claude Code session"
3. In the rollout details: dynamic workflows are off by default on Enterprise plans, and admins must explicitly enable them

That third point is the most telling. Anthropic clearly anticipated that Enterprise admins would have strong opinions about uncapped token consumption and chose to ship with the feature gated by default. When a vendor builds in friction against their own most-marketed capability, they're telling you the cost question is real.

The first-run UX reinforces this. The first time a workflow triggers in Claude Code, it shows you what's about to run and asks for confirmation before kicking off. That's not standard for Claude Code features. It's a deliberate intervention for a feature that can spend more in five hours than your previous month of Claude usage.

Read together, these signals say: this is powerful, this is expensive, and we don't want you discovering both at the same time on your monthly bill.

When Dynamic Workflows Are Worth It (And When They're Not)

The right way to think about dynamic workflows is as a different category of engineering tool, not a faster version of Claude Code. Faster Claude Code is still Claude Code. Dynamic workflows are closer to commissioning a small contract engineering team for a bounded project.

Here's a rough rubric:

Worth it when: the task is large enough that a human engineering team would scope it in weeks or months, the surface area is repetitive enough that parallel subagents can divide it cleanly (a migration, a port, a codebase-wide audit), the result has a clear verification signal (tests pass, scan returns clean), and the cost of doing it the human way is significantly higher than the cost of the tokens.

Not worth it when: the task is small enough that a single Claude Code session would handle it, the work is novel or one-off enough that the verification overhead exceeds the work itself, the verification signal is weak (vibes-based design decisions, ambiguous product requirements), or you're using it because it's exciting rather than because the task is workflow-shaped.

The Bun rewrite is exactly workflow-shaped. A landing-page redesign is exactly not.

The risk we'd flag for builders: dynamic workflows make it easy to spend a lot of money very quickly on tasks that didn't need a workflow at all. The ultracode setting that lets Claude decide automatically when to trigger one is convenient, but it's also a switch that removes the human checkpoint from a decision with significant cost implications. We'd recommend keeping that switch off until you have at least a week of usage data from explicit workflow invocations.

The Validation-Scales-Slower Problem

A principle worth stating directly: generation scales effortlessly, validation does not.

Dynamic workflows ship with verifier agents built in. That's good. It's also incomplete. The verifier agents check that the work meets a defined criterion (the tests pass, the code compiles, the lint is clean). They don't check whether the criterion was the right one. They don't catch architectural drift, subtle behavioral changes that pass tests but break in production, or the slow accumulation of "technically correct" code that becomes unreviewable in aggregate.

For the Bun rewrite, the test suite was the criterion, and a 99.8 percent pass rate is a strong signal. For a security audit, the criterion is harder to specify and the verifier's confidence harder to trust. For a refactor that touches business logic, the criterion may not exist in your test suite at all.

The practical implication: dynamic workflows are most trustworthy where your existing engineering rigor is highest. They are most dangerous where your test coverage, type system, and CI quality are weakest, because that's exactly where the verifier agents will mistakenly signal success.

If your codebase isn't ready for a single Claude Code session to ship reliably, it's not ready for a hundred of them.

What This Means for MCP and Creative Tool Builders

Here is where the three-week story converges for anyone building MCP tools.

In a dynamic-workflow world, your MCP server doesn't get called by one agent at a time. It gets called by tens or hundreds of parallel subagents, each with their own context window, each potentially invoking your tools concurrently. The traffic shape is fundamentally different from human-driven MCP usage.

For Vanikya, this changes the operational model significantly. Our MCP server at vanikya.ai/mcp brings image, vector and SVG, Lottie animations, and video generation directly into Claude as native tools. In a dynamic-workflow scenario where a single workflow needs creative assets for hundreds of generated UI components, marketing pages, or documentation files, the call pattern is bursty, parallel, and operationally demanding.

Three things any MCP server needs to survive that pattern:

Idempotency. If a subagent retries a creative generation, the second call should return the same asset, not a different one. Otherwise you've doubled the cost of a single intended output.

Cost guardrails at the server level. Workflow-scale traffic can quickly exceed sensible budgets. Server-side rate limiting, per-workflow cost ceilings, and asset caching are not nice-to-haves anymore.

Authorization that survives fanout. If a hundred subagents authenticate separately, your auth model has to handle the load without becoming the bottleneck. OAuth 2.1 with short-lived tokens and a refresh strategy that doesn't thrash.

This is the operational profile we've been building Vanikya for. The MCP wave validates the bet that creative generation belongs in the tool surface. Dynamic workflows validate that the tool surface needs to be built for high-fanout traffic, not interactive human use.

What Founders and Engineering Leaders Should Do on Monday

Six concrete moves, in order.

One. If you're on a Max or Team plan, dynamic workflows are on by default. Decide whether they should be. Get explicit about which engineers can trigger them and on which projects, before the first month's bill arrives with a surprise.

Two. Pick one scoped task to pilot. Anthropic's own guidance is to start small. A focused audit, a contained migration, a security pass on a single service. Use the pilot to build an internal cost-per-outcome benchmark.

Three. Track the right metrics. Tokens consumed, time saved, defect rate, review friction, and post-merge incidents. Landed PRs alone is a vanity metric for agent-driven work.

Four. Audit your codebase for workflow readiness before adopting at scale. Test coverage, CI quality, type safety, observability. If these aren't strong, the verifier agents will mislead you in proportion to your weakness.

Five. If you ship an MCP server, model what your operational profile looks like at workflow-scale fanout. Build idempotency, server-side cost guardrails, and a fanout-aware auth model. The MCP servers that survive the next twelve months will be the ones built for this traffic shape.

Six. Be honest with finance about what changes. Engineering capex doesn't disappear in a dynamic-workflow world. It moves from headcount to inference. Make sure your CFO knows that line item exists before it shows up unannounced.

The Frame

Dynamic workflows are the most powerful addition to Claude Code since launch. They are also the most expensive thing in the product. Both deserve attention.

The teams that pull this off in 2026 will be the ones that treat agent-driven engineering as a budget category, not just a capability. The teams that don't will discover the math the hard way, usually on the first invoice.

Hundreds of agents in parallel is now a feature, not a research demo. The feature costs money to use. Use it carefully, measure it honestly, and price the work it does against the work it actually replaces.

The Bun rewrite is the proof of what's possible. The token bill is the proof of what changes.

Insights by Vanikya AI is a publication for builders, founders, and engineers shipping practical AI products. Read more at vanikya.ai.

Vanikya's creative MCP is built for the high-fanout traffic shape that dynamic workflows create: image, vector and SVG, Lottie, and video generation, with idempotent calls, server-side cost guardrails, and an auth model designed for parallel agent traffic. Connect at vanikya.ai/mcp.