Cost-Optimising Multi-Agent Systems: Where Tokens Actually Go

What actually drives multi-agent token spend

• The multiplication is structural, not incidental. Every subagent call typically re-sends the system prompt, tool schemas and relevant context from scratch — the same instructions get billed N times, not once, before the model has done any new work.
• Aggregate spend hides the problem. A monthly API bill tells you the total went up; it doesn't tell you which agent, which tool-call retry loop, or which redundant file read caused it. You need per-agent accounting to fix anything.
• The fix is rarely "use a cheaper model everywhere." The highest-leverage changes are structural — caching shared prefixes, capping fan-out, deduplicating tool calls — before you touch model choice at all.
• Anthropic's own published account of building a multi-agent research feature found individual agents use roughly 4x the tokens of a single chat call, and full multi-agent systems use roughly 15x, according to Anthropic's engineering blog — a real, sourced number, not a rule of thumb to apply blindly to every architecture.

Multi-agent architectures — an orchestrator that plans and delegates, and subagents that execute narrower pieces of a task in parallel or in sequence — have become the default shape for anything beyond a single tool-calling loop, in coding agents, research assistants and customer-support pipelines alike. They're also, reliably, the place where a team that budgeted for a single-agent workload gets a bill three, five or fifteen times larger than expected. This guide is about why that happens mechanically, how to measure it before you guess at a fix, and which mitigation patterns actually move the number.

Where the multiplication actually happens

Five mechanisms account for nearly all of the gap between what a multi-agent task "should" cost on paper and what it actually costs in production.

1. Each sub-agent re-sends context and system prompt. Unless you're actively caching, a fresh sub-agent call pays full input-token price for the system prompt, the tool definitions, and any shared reference material — every single time. Spawn six subagents with a 3,000-token system prompt and you've billed 18,000 tokens of pure repetition before any of them has read a single line of the actual task.

2. Tool-call retries compound silently. A subagent that calls a flaky tool, gets a malformed response, and retries with a slightly reworded call pays for the full round-trip each time — the failed attempt's input and output tokens don't disappear from the bill just because the call didn't succeed. In a fan-out of several agents each hitting the same unreliable API, retry cost can quietly become the largest line item.

3. Orchestrator-to-subagent handoff has real overhead. The orchestrator has to describe the subtask clearly enough for an agent with no shared memory to pick it up cold — which means restating context the orchestrator already has. Then the subagent's result has to be summarised and folded back into the orchestrator's context, which costs output tokens on the way out and input tokens on the way back in.

4. Redundant re-reading of the same files or data. If three subagents each independently need to understand the same 8,000-token config file or database schema, and each reads it fresh rather than working from a shared, cached representation, you've paid for that file three times over — a pattern that gets worse, not better, as fan-out width increases.

5. Context reconstruction after isolation. Isolated-context subagents are cheap individually but expensive in aggregate if the orchestrator has to reconstruct a coherent picture from several independently-summarised results, especially when a follow-up question forces the orchestrator to re-query a subagent for detail it discarded in its own summary.

Measuring it: per-agent token accounting, not aggregate spend

The single most common mistake in this guide's Watch out box above is treating a multi-agent system's cost like a single-agent system's cost — one number, tracked monthly. Before you optimise anything, instrument every call so you know, per agent role and per task, exactly how many tokens went in, how many came out, and whether the call hit a cache. A thin wrapper around your API client does most of the work.

from dataclasses import dataclass, field
from collections import defaultdict
import time

@dataclass
class TokenLedger:
    """Per-agent-role token accounting for a multi-agent run."""
    by_role: dict = field(default_factory=lambda: defaultdict(lambda: {
        "calls": 0, "input_tokens": 0, "output_tokens": 0,
        "cache_read_tokens": 0, "cache_write_tokens": 0, "cost_usd": 0.0,
    }))

    def record(self, role: str, usage, rates: dict):
        """usage: provider response.usage object.
        rates: {'input': $/Mtok, 'output': $/Mtok, 'cache_read': $/Mtok, 'cache_write': $/Mtok}
        """
        row = self.by_role[role]
        row["calls"] += 1
        row["input_tokens"]  += usage.input_tokens
        row["output_tokens"] += usage.output_tokens
        row["cache_read_tokens"]  += getattr(usage, "cache_read_input_tokens", 0)
        row["cache_write_tokens"] += getattr(usage, "cache_creation_input_tokens", 0)

        cost = (
            usage.input_tokens / 1_000_000 * rates["input"]
            + usage.output_tokens / 1_000_000 * rates["output"]
            + getattr(usage, "cache_read_input_tokens", 0) / 1_000_000 * rates["cache_read"]
            + getattr(usage, "cache_creation_input_tokens", 0) / 1_000_000 * rates["cache_write"]
        )
        row["cost_usd"] += cost
        return cost

    def report(self):
        total = sum(r["cost_usd"] for r in self.by_role.values())
        for role, r in sorted(self.by_role.items(), key=lambda kv: -kv[1]["cost_usd"]):
            share = (r["cost_usd"] / total * 100) if total else 0
            print(f"{role:<20} {r['calls']:>4} calls  "
                  f"${r['cost_usd']:.4f}  ({share:.1f}% of run)")
        print(f"{'TOTAL':<20} {'':>4}        ${total:.4f}")

# Usage inside an orchestrator loop:
# ledger = TokenLedger()
# response = client.messages.create(...)
# ledger.record("orchestrator", response.usage, RATES["frontier"])
# ledger.record(f"subagent:{subagent.role}", sub_response.usage, RATES["mid"])
# ledger.report()

Tag every call with a role (orchestrator, researcher-subagent, coder-subagent, critic-subagent) and a task ID, and route the ledger into whatever observability stack you already run. The point isn't the specific code above — it's the discipline of never letting "multi-agent run" be a single opaque cost figure. Once you have per-role numbers for a handful of representative runs, the next four sections tell you what to do about the biggest offenders.

For the wider discipline of turning this kind of per-call data into dashboards, alerts and cost-per-tenant attribution, see our guide to instrumenting agents with OpenTelemetry — the token ledger above is the minimum viable version of what that article covers in full.

Mitigation 1: prompt caching across sub-agent calls

If every subagent shares an identical system prompt, tool schema block, or reference document, that shared prefix is exactly what prompt caching exists to make cheap. As of July 2026, the three major providers implement it differently but land in a similar place: Anthropic prices a cache hit at roughly 10% of standard input cost, with a write premium of 1.25x input for a 5-minute time-to-live or 2.0x for a 1-hour TTL — meaning the write pays for itself after one or two hits and every hit after that is close to pure saving. OpenAI applies prompt caching automatically on prompts over roughly 1,024 tokens, with no code change required, at a 50% discount on the cached portion; caches typically clear after 5-10 minutes of inactivity. Google's Gemini models apply implicit caching automatically at no separate switch, plus an optional explicit-caching mode with storage pricing, both discounting cached tokens by roughly 90% on Gemini 2.5 and later models.

The practical implication for a fan-out architecture: if your orchestrator spawns six subagents within the same few minutes, each carrying the same 4,000-token system prompt and tool definitions, put that shared block first in the prompt and mark it cacheable. The first subagent call pays the write premium; the next five read from cache at a fraction of the price. This only works if the prefix is byte-exact — inserting even a timestamp or a subagent-specific instruction before the cacheable block breaks the match for every provider.

Treat these figures as a shape, not a permanent contract — providers revise caching pricing and TTLs regularly, so confirm current numbers on each provider's own documentation before you design a cost model around them. For a deeper walk-through of the caching mechanics and provider-by-provider gotchas, see our dedicated prompt-caching guide.

Mitigation 2: shared context windows vs isolated contexts

The choice between giving every subagent its own isolated context window or having them share one running context is the single biggest architectural lever on both cost and quality — and teams often default to whichever one is easier to implement rather than reasoning about the trade-off.

Isolated contexts win when subtasks are genuinely independent. If subagent A is summarising a support ticket and subagent B is checking a different ticket against a policy document, there's no reason for A's context to carry B's data. Isolation keeps each context window small — which is both cheaper per call and reduces the chance of the model getting distracted by irrelevant material from a different subtask.

Shared context wins when subtasks depend on each other's output. A code-review pipeline where a "find the bug" subagent's output feeds directly into a "write the fix" subagent loses fidelity every time that hand-off goes through a summarised return value instead of staying in a continuous context. The summary is lossy by construction — it drops exactly the detail a general-purpose subagent didn't think mattered, which is sometimes the detail the next agent actually needed.

UK teams weighing this trade-off often have a second constraint layered on top: where the caching and context actually live matters for data-residency obligations under UK GDPR, particularly if subagent context includes customer data and the caching provider's infrastructure sits outside the UK or EEA. That's frequently the deciding factor in favour of isolated, narrowly-scoped contexts per subagent — smaller blast radius if a cache or context needs to be provider-region-pinned — over a single sprawling shared context that's harder to reason about for a data-processing agreement.

Mitigation 3: capping fan-out depth and breadth

Fan-out — an orchestrator spawning several subagents to work a problem in parallel — is where multi-agent systems earn their keep, and also where they most easily run away on cost. Two dimensions matter separately: breadth (how many subagents run in parallel for one orchestrator call) and depth (whether subagents themselves spawn further subagents).

Breadth without a cap tends to grow to match whatever the task superficially looks like it needs — "review this 40-file pull request" becomes "spawn 40 subagents, one per file" unless something stops it. Most production systems that have thought seriously about cost cap breadth somewhere in the 3-8 range per orchestrator call, batching related work within each subagent rather than spawning one agent per atomic unit. Depth is a sharper cliff: an orchestrator spawning subagents that each spawn further subagents multiplies the handoff overhead from mitigation pattern four above at every additional level, and in practice one or two levels — orchestrator to subagent, rarely subagent to sub-subagent — covers almost every legitimate use case.

This isn't only a cost argument. Google Research's controlled study of 180 agent configurations found that on tasks requiring strict sequential reasoning, every multi-agent variant tested degraded performance by 39-70% against a single well-scoped agent — the overhead of inter-agent communication fragmented the reasoning process and left too little of the model's effective attention for the actual task. The same study found the opposite result on genuinely parallelisable work, where centralised multi-agent coordination improved performance by over 80%. Fan-out applied to a task that needed coherent, cumulative state actively makes results worse, not just more expensive — uncapped fan-out is a cost problem and a correctness problem at the same time.

For cost-sensitive Indian startups running lean on tight infrastructure budgets, this is often the highest-leverage single change available: a hard-coded fan-out cap in the orchestrator's spawning logic, enforced in code rather than left to the model's judgement about how many subagents a task "deserves." It costs nothing to implement and directly bounds the worst-case bill for any single request.

Mitigation 4: routing cheaper models to sub-agents

Not every call in a multi-agent pipeline needs the same model. The orchestrator — which plans, delegates and synthesises across the whole task — usually benefits most from a frontier-tier model's reasoning quality. Many subagents, by contrast, are executing a narrow, well-specified piece of work: extract these fields, check this document against this rule, summarise this file. That's frequently within reach of a cheaper mid-tier or budget model, at a fraction of the per-token cost.

The evidence for this pattern comes from cascade and routing research rather than from a single universal multiplier. A paper on calibrated-uncertainty cascade routing, UCCI (arXiv 2605.18796), reported cutting cost by roughly 31% on a production named-entity-recognition workload of 75,000 queries while holding quality at 0.91 micro-F1, by routing only the queries the router was uncertain about to the larger model. The mechanism generalises directly to a multi-agent fan-out: don't route by role alone ("subagents always get the cheap model") — route by the router's confidence that the cheap model can handle this specific instance, escalating to the frontier model only when it can't.

Treat the price band above as illustrative and provider-agnostic — actual rates move often and vary by vendor, and you should confirm current pricing before budgeting against it. The discipline that matters is separate from the exact numbers: measure subagent task accuracy against a smaller model on your own eval set before routing production traffic to it, and keep the router's escalation threshold tunable rather than hard-coded, because task difficulty distribution shifts as your product changes.

Mitigation 5: deduplicating redundant tool calls

The fastest token spend to eliminate is the spend that produces nothing new. Two patterns account for most of it in multi-agent pipelines: multiple subagents independently fetching the same data, and a single subagent retrying an identical or near-identical tool call after a transient failure.

For the first pattern, a shared, request-scoped cache keyed on the tool call's normalised arguments solves most of the problem cheaply: before a subagent executes a tool call, check whether an identical call has already run within this orchestrator run, and return the cached result instead of re-executing it. This is distinct from prompt caching — it's caching the tool's return value, not the LLM's response — and it needs no vendor support at all, just a dictionary keyed on a hash of the tool name and arguments, scoped to the lifetime of the task.

import hashlib, json

class ToolCallCache:
    def __init__(self):
        self._cache = {}

    def _key(self, tool_name: str, args: dict) -> str:
        payload = json.dumps({"tool": tool_name, "args": args}, sort_keys=True)
        return hashlib.sha256(payload.encode()).hexdigest()

    def get_or_call(self, tool_name: str, args: dict, fn):
        key = self._key(tool_name, args)
        if key in self._cache:
            return self._cache[key]          # no tool round-trip, no LLM re-summarisation
        result = fn(**args)
        self._cache[key] = result
        return result

# tool_cache = ToolCallCache()
# result = tool_cache.get_or_call("read_file", {"path": "config.yaml"}, read_file_impl)
# any subagent that requests the same path gets the cached result

For the second pattern — retry storms — cap retries per tool call explicitly (two or three attempts, not unbounded), and log every retry with its full token cost so a flaky downstream API shows up clearly in the per-agent ledger from earlier in this guide rather than hiding inside "tool subagent: input tokens." A tool that fails intermittently and gets silently retried by five parallel subagents can be a larger cost driver than any model-choice decision you'll make.

A worked example: naive vs optimised pipeline

The following is an illustrative worked example, not a published benchmark — it's built to show the mechanics of where the multiplier comes from, using round numbers rather than any specific vendor's live pricing. Take the shape of the comparison, not the exact dollar figures, and re-run it with your own task's token counts and current provider rates.

The task: produce a competitive-landscape summary by researching four competitors and synthesising the findings into one report. A naive implementation spawns one subagent per competitor, each of which independently re-reads a shared 6,000-token brief (market definition, output format, evaluation criteria) before doing its own research and returning a full write-up to the orchestrator, which then synthesises all four.

The output-token gap between the two pipelines is deliberately narrow in this example — caching and model routing mostly attack input-token cost and don't change how much the model needs to write to answer the question, which is why deduplicating tool calls and capping fan-out (both of which reduce genuinely wasted work) matter alongside caching rather than instead of it. The input-token reduction is where the bulk of the saving in this illustrative scenario comes from: a shared prefix billed once instead of four times, plus a cheaper per-token rate for the bulk of the research work.

Putting it together: the token-spend checklist

None of the five mitigation patterns above requires a model swap or a rewrite of your orchestration logic — they're additive, and most teams see the largest single jump from whichever one they haven't done yet, not from stacking all five simultaneously. A reasonable order to tackle them: instrument per-agent accounting first, because you can't prioritise the rest without it; turn on prompt caching for any genuinely shared prefix, because it's usually the cheapest change to ship; add a hard fan-out cap in code; add a request-scoped tool-call cache; and only then start experimenting with routing cheaper models to specific subagent roles, validated against your own eval set rather than assumed.

The throughline across all of it is the same one that opened this guide: a multi-agent system's cost is the sum of many small, structural repetitions, not one number that moves for mysterious reasons. Measure it per agent, and every mitigation pattern above becomes a targeted fix instead of a guess.