Dynamic Workflow 是什么? Claude Code Token Accounting and Gateway Governance

The most consequential thing about Claude Code's dynamic workflows feature is not just the scale — it is where orchestration, token visibility, and approval boundaries move. A dynamic workflow is a JavaScript script that Claude writes and the runtime executes in the background to coordinate many subagents. In the /workflows view, operators can inspect phases, agent counts, token totals, elapsed time, prompts, recent tool calls, and results. That turns a single user request into a measurable workflow run, not merely another chat turn. For teams that route Claude Code through a gateway or proxy, this is a new operational surface that needs explicit handling.

What happened

Anthropic documents dynamic workflows for Claude Code as an orchestration mode for codebase audits, large migrations, and cross-checked research. The feature requires Claude Code v2.1.154 or later and is available on paid plans — Pro, Max, Team, and Enterprise — with Anthropic API access and on Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. Pro users need to enable it from the Dynamic workflows row in /config.

The architecture is distinct from Claude Code's existing subagent and skill primitives. A dynamic workflow is a JavaScript script that Claude writes for the task you describe. The runtime executes that script in the background while your session stays responsive. In plain English, the dynamic workflow meaning is: Claude moves the plan out of the chat transcript and into runnable orchestration code, then uses that code to dispatch many focused agents and combine their results. The script holds the orchestration loop, the branching logic, and intermediate results in script variables — not in Claude's context window. Claude's context receives only the final synthesized answer.

The official docs describe the decision matrix clearly:

The bundled /deep-research command is the first shipped workflow: it fans out web searches across multiple angles, cross-checks sources, votes on each claim, and returns a cited report with unverified claims filtered out.

Why it matters for AI engineering teams

Token accounting is no longer only per-session. With subagents and skills, a Claude Code session produces work that scales roughly with the number of visible turns. With dynamic workflows, a single user prompt can trigger a script that fans out to dozens or hundreds of subagents over the run. The /workflows view exposes token usage by phase and agent, so operators should track cost by workflow run as well as by user and session. Otherwise a legitimate /deep-research or migration workflow can look like an unexplained usage spike.

Rate limits and plan usage still apply. Anthropic's docs state that workflow runs count toward plan usage and rate limits like any other session. The runtime bounds local execution — up to 16 concurrent agents, fewer on constrained machines, and 1,000 agents total per run — but those caps do not remove the need to test shared-key headroom before enabling broad team usage.

The governance surface expanded. With subagents, Claude decides turn by turn what to spawn next, and every decision is visible in the conversation transcript. With workflows, the orchestration logic lives in a JavaScript script that Claude writes. That script is the plan — and it runs autonomously once approved. The CLI approval flow can show planned phases, raw script review, and per-workflow consent options; the Desktop app presents Once, Always, and Deny actions. Operators should treat the workflow script as a reviewed artifact, not as invisible chat state.

Bedrock, Vertex, and Foundry users have a new routing consideration. Dynamic workflows are available across those provider paths, but every agent in a workflow uses the session's model unless the script routes a stage differently. Teams that pin lower-cost models for routine work should verify the configured model before a large workflow, and explicitly ask Claude to use smaller models for stages that do not need the strongest model.

The router/operator angle

Dynamic workflows introduce a new class of API traffic that looks different from interactive Claude Code usage:

• Burst pattern: a workflow run produces background agent activity rather than a steady stream of visible sequential turns. If your gateway applies per-second rate limiting or anomaly detection, a workflow can trigger thresholds that normal chat would not.
• Token distribution: each subagent in a workflow handles a narrow subtask, so individual requests tend to be shorter than a full-context interactive session. But the aggregate token count for a workflow run can be substantially higher than a single long session.
• Request attribution: in a standard Claude Code session, work is easy to attribute to a visible turn. In a workflow run, many agents and phases belong to one workflow. If your billing or audit system lacks a workflow-run dimension, you will see spikes without the context needed to explain them.

Operator checklist for dynamic workflows:

1. Update your token budget model. If you set per-user or per-team token budgets based on interactive session patterns, add a separate budget category for workflow runs. Start with small slices — one directory instead of the whole repo, or a narrow research question instead of a broad one — before approving large runs.

2. Check rate limit headroom. Before enabling workflows for your team, verify that your Anthropic API key or provider route has enough headroom for background agent bursts. Use Anthropic's documented caps — up to 16 concurrent agents and 1,000 total agents per run — as planning bounds, not as a reason to skip testing.

3. Log workflow run IDs. If your gateway or proxy logs Claude Code traffic, add workflow run ID, phase name, agent index, token totals, and elapsed time where available. This lets you attribute a burst of activity to one workflow rather than treating it as anomalous traffic.

4. Review the script approval flow. Dynamic workflows require launch approval depending on permission mode, but subagents run in acceptEdits mode and inherit the user's tool allowlist. File edits are auto-approved; shell commands, web fetches, and MCP tools outside the allowlist can still prompt mid-run. Enterprise teams should document when users may choose Always versus Once.

5. Test on Bedrock/Vertex/Foundry before enabling broadly. The feature is available on all three cloud providers, but behavior may differ from direct Anthropic API access depending on how each provider handles burst traffic and rate limits.

6. Require deterministic quality gates for code workflows. Community feedback around dynamic workflows is consistent: more agents do not automatically mean better code. Use tests, lint rules, type checks, architecture checks, and review policies as hard gates; prompts alone are too soft for long-running autonomous edits.

What TheRouter users should watch or try

For teams routing Claude Code through TheRouter or any OpenAI-compatible gateway, the immediate question is whether your gateway correctly handles the burst traffic pattern that workflow runs produce. A workflow that fans out many agents can create a short, dense burst of model traffic — each request still carrying its own authorization, model selection, and request body.

If your routing config applies per-request transforms (such as injecting a system prompt or rewriting the model name), verify that those transforms are stateless and can handle concurrent requests without contention. Stateful transforms that depend on mutable session context may behave unexpectedly when many agent requests from the same workflow arrive close together.

The /docs/guides/ section covers provider routing configuration. For teams using TheRouter's usage ledger for billing reconciliation, watch for workflow-run bursts in your request volume metrics — they will appear as short spikes rather than the gradual ramp of interactive usage.

Dynamic workflows are in research preview, so the API surface and billing model may change before general availability. The current behavior — each subagent as an independent API call — is the right assumption for planning purposes, but verify against Anthropic's billing documentation as the feature matures.