Claude Code Dynamic Workflows Need Token Admission Control, Not a Concurrency Dial

Claude Code’s Dynamic Workflows problem is not that users can start too many agents. It is that “too many” is being measured in the wrong unit.

A concurrency cap sounds like a control. It is not a budget. Fifteen workers that each grep one small file are cheap. Fifteen workers that each inhale a chunk of a monorepo with a 1M-context model can blow through an input-tokens-per-minute limit before the operator has time to read the progress view. That is the failure mode described in Claude Code issue #70498, and it is exactly the kind of bug that appears when a chat product grows into a batch scheduler.

The reporter describes a Dynamic Workflow on Windows 11 using Claude Code, Opus 4.8 with 1M context, and background execution. The workflow fans out roughly 40 extract agents with a concurrency cap of 15. Each agent reads many often-large files. Within about 10 seconds, the run exceeds the account’s input-token-per-minute limit, hits 429s, and some agent() calls terminate after retries. The workflow then continues with the surviving agents.

That last sentence is the scary part. A failed interactive turn is visible. A failed worker inside a multi-agent workflow can become a hole in the dataset that the final synthesis papers over. The user may receive a coherent report that looks complete while a whole wave of partitions never finished.

The scheduler is now part of the product

Claude Code’s workflow documentation frames workflows as a way to run dozens to hundreds of agents per run, keeping intermediate results in script variables and showing progress with phase agent counts, token totals, and elapsed time. That is powerful. It also means the runtime is no longer just a terminal assistant. It is orchestrating distributed work under provider rate limits, account budgets, retry windows, partial failures, and token accounting.

The reporter’s cost claim is concrete: each bad concurrency guess can burn roughly 7–10% of Session Usage with no usable result, forcing manual trial-and-error reruns at lower settings such as 15 to 10 to 5, with about 15 minutes of waiting between attempts. A related report, issue #70475, describes transient workflow failures causing manual reruns, including one observed pair of workflows losing about 94k and 278k agent tokens — roughly 372k tokens redone.

This is not just a “Claude Code should retry better” complaint. It is an admission-control problem. The scarce resource is not worker count. It is input tokens per minute, output tokens per minute, requests per minute, retry debt, and the actual reset window returned by provider headers. The workflow runner should understand those resources before it starts work and adapt as they change.

Cloud systems learned this lesson a long time ago. You do not protect a database by limiting the number of microservices that can exist. You protect it with backpressure, queues, rate limiters, circuit breakers, and retry policies that respect the dependency’s capacity. Agent workflows need the same boring machinery, except the pressure metric is often tokens rather than packets or queries.

Concurrency is the wrong abstraction for operators

The user-facing knob should not be “how many agents can run at once?” That is an implementation detail masquerading as a safety control. The better questions are: how many tokens can this workflow spend, how much input can it read per minute, how much incomplete work can it tolerate, and what should happen when a worker gets rate-limited?

A serious workflow runtime would estimate token load before launching a phase. It would classify input partitions by size rather than file count. It would pace new agents based on anthropic-ratelimit-* headers and retry-after. It would requeue rate-limited partitions instead of treating them as terminal failures. It would fail loud if an expected partition is missing. And it would preserve completed work so a transient provider event does not turn into a full manual rerun.

The final synthesis also needs a contract. If only 31 of 40 extract agents finished, the output should say that plainly and list the missing partitions. The user should not have to reverse-engineer completeness from logs. “Here is the result, but 9 workers failed due to rate limits and were not included” is less polished than a confident summary. It is also the truth, and the truth is the product feature here.

Anthropic’s cost documentation already warns that agent teams and multi-agent work scale token usage with active teammates and context windows. The documentation advice — keep teams small, prompts focused, and context under control — is correct. But once Dynamic Workflows invite dozens or hundreds of agents, cost control cannot live only in docs. It has to live in the scheduler.

How engineers should run these workflows today

Until the runtime grows token-aware admission control, treat Dynamic Workflows like rate-limited ETL. Start with an indexing phase before full reads. Use grep, ripgrep, AST indexes, or file manifests to narrow the candidate set. Partition by estimated token size, not by number of files. Keep prompts narrow and deterministic. Add checkpoints between phases. Make each phase rerunnable and idempotent, so retrying a failed partition does not require replaying the entire workflow.

Most importantly, define completeness before the run starts. If the workflow is supposed to inspect 40 modules, the output artifact should include 40 status rows. If a row failed because of a 429, that is not a footnote. It is missing evidence. Do not let the model synthesize around absent data unless the final answer explicitly marks the gap.

This is also a procurement criterion for coding-agent tools. The impressive demo is “spawn 100 agents.” The production question is “what happens when worker 37 hits a rate limit after spending 80k tokens and worker 12 finishes with stale context?” Multi-agent coding tools are useful only if their orchestration layer behaves like infrastructure. Otherwise they are just very expensive autocomplete with a process tree.

The take: token admission control is now a core agent-runtime primitive. A concurrency dial is a hint. A budget-aware scheduler is the feature.

Sources: Anthropic Claude Code issue #70498, Claude Code workflows documentation, Claude Code costs documentation, related Claude Code issue #70475