Coordination & Cost

Introduction

Multi-agent systems can clearly win — Anthropic's research system beat a single agent by 90.2% (L143). But that win has a price tag most teams discover after the bill arrives. A supervisor with a handful of workers can quietly burn 15× the tokens of a single chat, and a runaway loop can burn far more. This lesson is the economics: where all those tokens go, the levers that control them, and how to keep a clever architecture from becoming an expensive one.

Two costs ride along with every multi-agent system: coordination (the overhead of agents talking, routing, and synchronizing) and compute (the tokens — and dollars — they spend doing it). Ignore them and you get a system that's smarter on paper and ruinous in production.

The good news: the cost is largely controllable, and the most important lever flips the mental model — multi-agent quality comes from spending more tokens, so the goal isn't to spend nothing, it's to spend deliberately on a task that's worth it.

In this lesson:

The cost multiplier — why multi-agent runs 4×–15× (and sometimes 100×+) a single chat
Where the tokens go — context duplication, supervisor overhead, coordination, the MCP tax
Cost is the mechanism — the reframe, made tangible (hands-on cost lab)
The optimization levers — model tiering, prompt caching, context scoping
Controlling spend — token budgets as hard ceilings, loop caps, and cost attribution

Scope: this lesson is the economics & coordination overhead. Assembling everything into a full system is the finale (L148 — Designing a Multi-Agent System). Builds on L143 (Why Multiple Agents?) (the value calculus), L144 (Supervisor / Hierarchical Architectures) (supervisor bottleneck), and L146 (The A2A (Agent-to-Agent) Protocol) (A2A's missing cost controls).

An infographic titled 'Coordination & Cost' showing the economics of multi-agent systems. The center is a bar chart of the token multiplier versus a single chat: a single agent uses about four times the tokens, while a multi-agent system uses about fifteen times, and at long horizons the agent path can exceed one hundred times because cost compounds nonlinearly. A panel breaks down where the cost goes: context duplication, where the same context is re-sent to every agent (measured at 53 to 86 percent redundancy in real frameworks); supervisor overhead, the orchestrator routing and aggregating even when no domain work happens; coordination round-trips between agents; retries and verification; and the tool-schema MCP tax of roughly 10,000 to 60,000 tokens per turn. A reframe is highlighted: cost is the mechanism, not waste — Anthropic found that token usage alone explains about 80 percent of quality on hard research, so multi-agent works mainly because it spends enough tokens, and the real question is whether the task is worth it. A latency note shows that parallel agents keep latency roughly flat while tokens multiply, trading dollars for capacity rather than time. Cards give the optimization levers: model tiering, using a capable lead model with cheaper worker models, the single highest-leverage lever at 50 to 80 percent savings; prompt caching, marking the system prompt and tool definitions as a cached prefix for 90 percent off those tokens; and context scoping, giving each worker only its slice to kill duplication. A control panel stresses budget enforcement: a hard token and step ceiling per agent that stops execution, not just an alert that notifies after the money is gone, plus loop detection and cost attribution per agent and task. The takeaway: multi-agent quality is bought with tokens, so spend deliberately — tier models, cache prefixes, scope context, cap budgets, and only pay the multiplier when the task is high-value and genuinely parallel.

The Cost Multiplier — 4× to 15× (and Beyond)

Start with the headline numbers (Anthropic's own measurements):

A single agent uses roughly 4× the tokens of a plain chat — it loops, calls tools, and re-reads context.
A multi-agent system uses about 15× the tokens of a chat — several agents, each with its own context window, each looping.

And it gets worse at scale, because the cost is nonlinear — it compounds. One analysis found an agent path costs ~3× a 5-step task, ~30× at 50 steps, and 100×+ at 200 steps: every extra step carries the whole growing context with it. A multi-agent system layers that curve across multiple agents and a coordinator. The naïve four-agent rewrite of a 10k-token job can hit 35k tokens before it does anything useful — a 3.5× tax just to set up the collaboration.

The takeaway to internalize early: in a multi-agent system, tokens don't add — they multiply, and the multiplier grows with the length and width of the work. That's not automatically bad (next section), but it means cost has to be a first-class design concern, not an afterthought.

Where the Cost Goes

If you're paying 15×, what exactly are you paying for? Five recurring drivers — and naming them is the first step to cutting them:

Context duplication. The biggest one. The same context (the task, prior findings, tool results) gets re-sent to every agent. Measured redundancy in real frameworks is staggering: 72% (MetaGPT), 86% (CAMEL), 53% (AgentVerse) — agents routinely use 1.5–7× more tokens than necessary purely from re-sharing.
Supervisor overhead. The orchestrator must route tasks, aggregate outputs, and hold workflow state — billed work even when no domain work is happening. Lightweight supervisor designs alone save ~30%.
Coordination round-trips. Every delegation and hand-back is another model call (and 100–500 ms of latency); the conversation history grows with each one.
Retries & verification. Failures, re-planning (L131), and check steps all re-run work — extra billed passes.
The tool-schema MCP tax. Every turn re-sends your tool definitions. In a multi-server MCP setup that's ~10k–60k tokens per turn, per agent, before the model does anything.

Notice these are mostly overhead, not reasoning — context you re-paid for, coordination you can't skip, schemas you re-sent. The optimization levers later target exactly these. But first, the reframe that decides whether the spend is even a problem.

Cost Is the Mechanism

Here's the counterintuitive heart of the lesson. When Anthropic analyzed what made their multi-agent system good, one factor dominated: token usage alone explained ~80% of the performance variance (with number of tool calls and model choice as the other two). Their blunt conclusion: "multi-agent systems work mainly because they help spend enough tokens to solve the problem."

Read that again: the cost is the mechanism. Splitting work across agents with separate context windows buys you more reasoning capacity — more room to think, search, and reason in parallel — and that capacity is literally paid for in tokens. The 15× isn't pure waste; a large chunk of it is the capacity that produces the better answer.

That reframes the whole problem. The goal is not to spend as little as possible — it's to spend efficiently on a task that's worth it. A naïve multi-agent system wastes tokens on duplication and overhead; a well-built one spends them on reasoning. Tune the architecture and watch the cost — and what each lever actually changes:

A cost calculator for one research task. Pick an architecture (single agent = 1× baseline, supervisor + 3, or supervisor + 6 ≈ 15×) and toggle the three big cost levers — model tiering (Opus 4.8 lead + Haiku 4.5 workers, cuts $/token), prompt caching (cache the system prompt + tool defs, 90% off), and context scoping (each worker sees only its slice, kills duplication). Watch the token multiplier, the $/run, and the latency move. The lesson: more agents multiply tokens (cost is the mechanism), the levers hit DIFFERENT dimensions (scoping cuts token COUNT; tiering + caching cut $/token), and parallelism keeps latency flat while tokens climb — you trade dollars for capacity, not time. Rough estimates.

Two things the lab makes obvious. First, the levers are not interchangeable — scoping cuts the token count, while tiering and caching cut the price per token; you want all three. Second, latency stays roughly flat as tokens multiply, because workers run in parallel — so multi-agent mostly trades dollars for capacity, not dollars for speed.

Latency vs. Cost — Two Different Budgets

It's worth separating the two budgets you're spending, because they trade against each other:

Parallelism buys speed with tokens. Running workers concurrently (L118) is how a multi-agent system stays fast despite doing more work — Anthropic's parallel subagents cut research time dramatically. But the parallel plans you run all cost money: one study measured 1.6–1.8× faster for 1.7–1.8× the cost — you bought latency with tokens.
Coordination adds latency that doesn't shrink. Each handoff adds 100–500 ms of serialize → network → deserialize → sync; aggregate coordination latency climbs from ~200 ms at 5 agents to ~2 s at 50. Layers of supervisors stack planning round-trips (a 3-deep hierarchy adds seconds before any worker runs — L144 — Supervisor / Hierarchical Architectures).

So decide which budget is tight. If latency is the constraint (interactive UX), parallelism is worth the token premium and deep hierarchies are not. If cost is the constraint (batch processing), a leaner single-agent or shallow supervisor often wins. Multi-agent's superpower is trading dollars for speed and capacity — only valuable when you actually need the speed or the capacity.

The Optimization Levers

Now the toolkit — in rough order of leverage. The first two alone routinely cut agent bills 60–80%:

Model tiering (highest leverage). Don't run every step on your most expensive model. Put a capable lead on planning and synthesis, and cheap workers on routing, extraction, and search. Anthropic's own system pairs an Opus lead with Sonnet/Haiku subagents; tiering typically saves 50–80% (one real workload: $10,500 →$ 1,382/month, same result).
Prompt caching. Your system prompt and tool definitions are stable and re-sent on every turn × every agent — exactly what caching is for. Mark them as a cached prefix and pay ~90% less on those tokens.
Context scoping. Attack duplication directly: give each worker only the slice it needs, not the whole transcript (L144/L145 — Agent Handoffs & Shared State). This cuts the token count, not just the price.

# Two highest-leverage cost levers in one config — MODEL TIERING + PROMPT CACHING.
from anthropic import Anthropic
client = Anthropic()

# 1) TIERING — a capable lead, cheap workers. Same task, ~50-80% less spend.
LEAD   = "claude-opus-4-8"     # $5 / $25 per 1M  → planning & synthesis
WORKER = "claude-haiku-4-5"    # $1 / $5  per 1M  → routing, extraction, search

# 2) CACHING — the system prompt + tool defs are re-sent on EVERY turn × EVERY agent.
#    Mark them as a cache breakpoint → 90% off those tokens (5-min TTL).
resp = client.messages.create(
    model=WORKER, max_tokens=1024,
    system=[{"type": "text", "text": BIG_SYSTEM_PROMPT,
             "cache_control": {"type": "ephemeral"}}],     # ← cached, stable prefix
    tools=TOOLS,                                            # (tool defs are cacheable too)
    messages=history,                                       # ← uncached, growing turns
)
# Caching ~40 tool defs (~12k tokens) across 1k calls/day ≈ $1k/month saved on tools alone.
# Tiering + caching + context-scoping STACK — together they routinely cut agent bills 60-80%.

Beyond these three: right-size the architecture (a supervisor beats a swarm; don't over-decompose — fewer agents, fewer round-trips), compress long histories (summaries, L133 — Short-Term vs Long-Term Memory), and cap iterations so loops can't run forever. Tiering and caching are pure wins (same output, less money); scoping and right-sizing trade a little context for a lot of savings.

Controlling Spend — Budgets as Hard Ceilings

Optimization lowers the unit cost; budgets stop the catastrophe. The number-one failure mode in production multi-agent systems is simple: no budget cap. Costs compound silently, and a single confused loop can burn your month's spend overnight. The canonical horror story: two LangChain agents — an Analyzer and a Verifier — fell into a loop, exchanging requests for 11 days before anyone noticed, because there was no per-agent ceiling and nothing to terminate the session.

The critical distinction: a budget alert is not a budget control. An alert emails you after the money is gone; enforcement stops the next call. A token (or step) budget is a hard ceiling per agent session that halts execution when hit:

# BUDGET ENFORCEMENT — a HARD ceiling, not an alert. Alerts tell you AFTER the money's
# gone; enforcement STOPS the next call. (A real loop of two agents ran 11 days with no cap.)
class Budget:
    def __init__(self, max_tokens, max_steps):
        self.max_tokens, self.max_steps = max_tokens, max_steps
        self.tokens = self.steps = 0
    def charge(self, usage):
        self.tokens += usage.input_tokens + usage.output_tokens
        self.steps  += 1
        if self.tokens > self.max_tokens or self.steps > self.max_steps:
            raise BudgetExceeded(f"halted at {self.steps} steps / {self.tokens} tokens")

budget = Budget(max_tokens=500_000, max_steps=40)     # a ceiling PER agent session
while not done:
    msg = client.messages.create(model=WORKER, messages=msgs, tools=TOOLS)
    budget.charge(msg.usage)        # ← raises BEFORE the next API call when exceeded
    ...
# Give EACH subagent its own scoped budget, add a no-progress / loop detector (L131),
# and tag every call by agent + task so you can ATTRIBUTE spend (A2A ships no cost model).

Layer the defenses: a per-subagent token/step budget (so one wanderer can't sink the run), a loop / no-progress detector (L131), soft + hard caps (a soft cap warns, a hard cap cuts off — together they catch ~95% of runaways), and cost attribution — tag every call by agent and task so you can see which part of the system is burning money. This last point matters extra for A2A (L146): when your agent delegates to someone else's paid agent, the protocol defines no way to attribute or cap that spend — you build the telemetry yourself. Observability without enforcement is just a nicer way to watch the bill grow.

When Is It Worth the Multiplier?

All of which comes back to the question from L143 (Why Multiple Agents?), now with the economics filled in: is this task worth 15×? Multi-agent earns its premium under a specific shape of work:

High value. The answer is worth a lot of tokens — Anthropic built theirs for research where the question is large and the answer is valuable. A 15× spend on a $0.02 task is absurd; on a report that informs a$ 2M decision, it's a rounding error.
Genuinely parallel & independent. The win comes from decomposing into subtasks that run concurrently without heavy interdependence. If the work is tightly sequential or small, the coordination overhead isn't worth it — you pay the 3.5× setup tax for nothing.
Quality gain that justifies the spend. The extra tokens must buy a meaningfully better result, not a marginally different one.

The discipline, one more time: start with one agent (L143), reach for multi-agent only when the task is valuable, parallel, and independent — and when you do, tier, cache, scope, and cap. A well-tuned multi-agent system spends its tokens on reasoning; a careless one spends them on duplication and loops. Same architecture, 5× different bill.

🧪 Try It Yourself

Reason these through, then check with the cost lab:

A multi-agent system uses ~15× the tokens of a chat. Is that 15× pure waste? Explain in one sentence (use Anthropic's 80% finding).
Your bill is too high. You can add model tiering or context scoping but not both today. Which cuts the token count, and which cuts the $/token?
You cache your system prompt and tool definitions. Roughly how much do you save on those tokens, and why are they the right thing to cache?
A teammate added a Slack alert at $200/day spend. Why is that not enough to prevent a runaway, and what's the fix?
When is paying the 15× multiplier not worth it? Name two task shapes.

→ (1) No — a large share is capacity: separate context windows buy more parallel reasoning, and token usage alone explains ~80% of quality; the waste is the duplication and overhead, not the spend itself. (2) Scoping cuts the token count (less duplicated context per worker); tiering cuts the $/token (cheaper worker models — same tokens, less money). (3) ~90% off those tokens — the system prompt + tool defs are stable and re-sent every turn × every agent, so a cached prefix avoids reprocessing them. (4) An alert notifies after the money is spent; it doesn't stop the next call. You need enforcement — a hard token/step ceiling per agent that halts execution (plus a loop detector). (5) When the task is low-value (the answer isn't worth many tokens) or tightly sequential / small (no independent parallelism — you pay the coordination tax for no gain).

Mental-Model Corrections

"Multi-agent tokens are wasted money." Much of the spend is capacity — separate context windows = more parallel reasoning, which is ~80% of where the quality comes from (Anthropic). The waste is duplication and overhead, which you can cut.
"Cut cost by using fewer/cheaper models everywhere." Downgrading the lead tanks quality. Tier: keep the capable model for planning/synthesis, use cheap models for the grunt work.
"Caching is a latency trick." It's also a ~90% cost cut on stable prefixes — and in agents the system prompt + tool defs are re-sent constantly, so it's one of the biggest cost levers, not just speed.
"More agents = faster." Parallelism helps latency but multiplies tokens; coordination even adds latency (100–500 ms/handoff). You trade dollars for capacity, and only sometimes for speed.
"A spend alert protects me." An alert tells you after the fact. Only an enforced budget (a hard ceiling that stops the next call) prevents a runaway — alerts ≠ enforcement.
"Optimize cost after it works." The cost is nonlinear and compounding; by the time it 'works' the architecture is baked in. Make budgets and tiering first-class from the start.

Key Takeaways

Multi-agent is expensive and nonlinear: ~4× (single) to ~15× (multi) the tokens of a chat, 100×+ at long horizons — cost compounds with the length and width of the work.
Where it goes: context duplication (53–86% redundancy!), supervisor overhead, coordination round-trips, retries/verification, and the MCP tax (10–60k tokens/turn of tool schemas).
But cost is the mechanism: token usage alone explains ~80% of multi-agent quality (Anthropic) — you're buying reasoning capacity with tokens. Spend efficiently on a worthy task, not nothing.
Latency vs cost: parallelism trades dollars for speed (1.6–1.8× faster for ~1.8× cost); coordination adds latency. Decide which budget is tight.
Levers (60–80% off): model tiering (capable lead + cheap workers — highest leverage), prompt caching (system prompt + tool defs, ~90% off), context scoping (kill duplication), right-size the architecture.
Control spend: budgets as hard ceilings per agent (enforcement ≠ alerts — a real loop ran 11 days), loop detectors, soft+hard caps, and cost attribution (A2A ships none — L146 — The A2A (Agent-to-Agent) Protocol).
Worth the multiplier only when the task is high-value, parallel, and independent (L143) — then tier, cache, scope, and cap.
Next — L148: Designing a Multi-Agent System — the finale: putting topology, coordination, protocols, and cost together into one system you'd actually ship.