A workflow's cost is its fan-out, and none of the guides to workflows mention it. Anthropic's own documentation is the right place to learn what dynamic workflows are and how to write one. This page answers the question you have immediately afterwards: what does running one cost, and which knob changes that.
Short version — a workflow that fans out to five subagents is roughly five agents' worth of tokens, not one. That is the point of it and it is also the bill.
The arithmetic
# A workflow's cost is not "one task". It is the fan-out.
#
# workflow_cost = orchestrator_steps x step_cost
# + subagents x subagent_steps x step_cost
#
# A step is 25,000 in / 1,200 out — the same sizing used on
# every other cost page here, so these numbers are comparable.
#
# Claude Sonnet 4.6 $0.037 / step
# Claude Haiku 4.5 $0.012 / step
#
# Same job, three shapes:
#
# one thread, 20 steps, all Sonnet
# = 20 x $0.037 = $0.744
#
# 5 subagents x 8 steps + 6 orchestrator steps, all Sonnet
# = 46 x $0.037 = $1.71
#
# same fan-out, subagents on Haiku, orchestrator on Sonnet
# = 40 x $0.012 + 6 x $0.037 = $0.719
#
# The fan-out costs more than the single thread. Mapping the fan-out
# to the cheap tier is what buys most of it back.Read the three shapes as the same job done three ways. The fan-out is more expensive than the single thread in every case — what changes is how much more, and that is decided almost entirely by which tier the subagents run on.
The one line that changes it
Subagent work in a workflow is usually bounded and mechanical: read a file, summarise a diff, check a condition, report back. That is what a small model is for. The orchestrator is the opposite — it holds the plan, and a bad plan wastes every subagent underneath it, so that is where a strong tier earns its price.
# The one line that changes every workflow run: the tier the
# background and sub-task work lands on.
export ANTHROPIC_BASE_URL=https://api.kunavo.com
export ANTHROPIC_AUTH_TOKEN=sk-kn-...
export ANTHROPIC_MODEL=claude-sonnet-4-6 # orchestration
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5 # the fan-outClaude Code routes its automatic sub-task calls to whatever is mapped to the Haiku tier, so this mapping is doing work on every run whether or not you are using workflows explicitly. The break-even for the orchestrator's tier — how much worse a cheaper model has to be before it stops being cheaper — is on Opus vs Sonnet vs Haiku.
Two things the estimate will miss
Retries. A subagent that fails and re-runs is billed twice, and fan-out multiplies the chances that at least one does. This is invisible in any plan-time estimate and shows up only in the usage record.
Cached context. Pulling the other way: subagents launched from the same orchestrator often share a stable prefix, and a cache hit is billed at a fraction of the input rate. On a long workflow that is the largest single reduction available — bigger than the tier change above. The mechanism, and the three ways routing through a gateway breaks it, are on Claude prompt caching.
Deciding whether to fan out at all
Workflows are not a cost optimisation and it is worth being clear about that, because the framing decides the answer. They buy latency and breadth: several subagents working at once finish sooner and cover more ground than one thread grinding through the same list. The question is whether that is worth the multiple, and the arithmetic above gives you the multiple for your own shape.
For the feature itself — how to define a workflow, how subagents are orchestrated, what the syntax is — Anthropic's documentation is authoritative and this page does not try to restate it. What runs the models underneath is a base URL and a key, and the subscription-versus-token side of the same decision is on Claude Pro and Max limits.
FAQ
What does a Claude Code workflow cost?
More than the same work in a single thread, because a workflow's cost is its fan-out. Model it as orchestrator steps plus subagents times their steps, all multiplied by the cost of one step. At Kunavo rates a step of 25,000 input and 1,200 output tokens is $0.037 on Claude Sonnet 4.6: a 20-step single thread is about $0.744, while five subagents of eight steps each plus six orchestrator steps is 46 steps and about $1.71. The fan-out buys parallelism and breadth; it does not buy a discount.
How do I make workflows cheaper without giving up the fan-out?
Put the fan-out on the cheapest tier and keep the orchestration on a strong one. Sub-tasks in a workflow are usually bounded and mechanical — read this, summarise that, check the other — which is what a small model is for, while the orchestrator holds the plan and needs to be right. Mapping the same 46-step example that way costs about $0.719 instead of $1.71, and the change is one environment variable rather than a rewrite.
Are workflows worth it if they cost more?
Often yes, but decide it on the right axis. A workflow is not a cost optimisation, it is a latency and breadth optimisation: several subagents working at once finish sooner and cover more ground than one thread doing the same work serially. The question to ask is whether the parallelism is worth the multiple, not whether the multiple exists — it does, and any page telling you otherwise has not done the arithmetic.
Which model should the orchestrator use?
The orchestrator makes the plan and reads the results, so it is the one place a weak model costs you the most — a bad plan wastes every subagent under it. Claude Sonnet 4.6 at $1.20 / $6.00 per 1M tokens is the working default; Claude Opus 5 at $2.00 / $10.00 earns its price on genuinely ambiguous work. The attempt-count break-even between the tiers is on the tier comparison page.
Do workflows work through a custom API endpoint?
Yes — workflows are a client-side orchestration feature, so they run wherever Claude Code runs, and Claude Code reads ANTHROPIC_BASE_URL natively. Every subagent call goes to the same endpoint as the orchestrator's, which is also what makes the cost visible in one place: a workflow's fan-out shows up as a burst of requests in one usage view rather than being spread across accounts.
How do I see what a workflow actually spent?
Read it per request rather than estimating from the plan, because the number of subagent steps is decided at runtime and rarely matches your guess. On a per-token key each call in the fan-out is a line you can add up, including the retries a failing subagent produced — which are billed and are invisible in any up-front estimate.