You Pay for the Same Context Fourteen Times

A single call you pay for once. A naive multi-agent run re-sends the same context on every call, so the bill scales with how much each agent carries, not with how many agents you have.

The last chapter was about the retry that fires the side effect twice: a multi-agent run fails in the middle, a blind retry replays the steps that already ran, and the email goes out a second time. It ended on a number. The run this series has used comes to about 41,000 tokens, and a blind retry pays most of that bill again to recover from a failure in one step. This chapter is about that number when nothing fails at all. The clean pass still costs about 41,000 tokens, and almost none of that is the agents thinking. Most of it is the same context, read again and paid for again, on every call.

Here is the uncomfortable part. Teams price a multi-agent system the way they price a team: six agents must cost about six times one agent. It does not work that way. A single model call has a cost that is obvious and roughly fixed, you send a prompt and pay for the tokens once. A multi-agent run's cost is neither obvious nor linear in the number of agents, because the price is dominated by input tokens, and in a naive pipeline every agent re-ingests the accumulated context. You are not paying six agents to think. You are paying to re-read the same system prompt, the same tool definitions, and the same source documents, fourteen times over. The bill does not scale with how many agents you have. It scales with how much context each one carries, times how many calls run, and both of those grow quietly.

TL;DR

A single model call has a fixed, obvious cost: one prompt, one completion, paid once. A multi-agent run's cost is dominated by input tokens, and in a naive pipeline every agent re-ingests the accumulated context, so you pay to re-read the same system prompt, tool definitions, and source documents on every one of the roughly fourteen calls in the run. The bill scales with context-per-call times number-of-calls, not with the number of agents, so a six-agent run does not cost six times a single call, it costs closer to fifteen. Retries and loops multiply it again. Cost control is not using fewer agents. It is four structural moves. Minimize the context at every handoff: pass a distilled two-hundred-token note, not the four-thousand-token raw transcript, so the token count stops accumulating. Tier the models: run the mechanical agents, planning, retrieval, extraction, on a small model at roughly a tenth of the price, and reserve the frontier model for the one or two agents that need it. Cache the static prefix: the system prompt, tool schemas, and shared context that get re-sent on every call read from cache at roughly a tenth of the uncached price. And do not fan out at all when a single call will do the job, because the cheapest agent is the one you did not add. Stacked, these take a naive run from about 41,000 frontier-priced tokens to roughly a seventh of the cost for the same output, close to an order of magnitude, and the lever that matters most is the one that attacks the token count before it is ever priced: stop re-sending context the receiving agent does not need.

A single call you pay for once. A multi-agent run re-reads everything.

In a single model call the cost is the simplest line item in your stack. You send a prompt of some number of input tokens, the model returns some number of output tokens, and you pay for each once at a published rate. Run it again and you pay again, in full, but you always know what "again" costs, because there is one call and one prompt.

A multi-agent run has no single prompt. Take the same six-agent extraction pipeline this series has used throughout: a planner, a retriever, two extraction workers, a reconciler, and a reviewer that holds the two tools that touch the outside world, finalize to the system of record and send email. A run walks those agents in sequence, and every one is a separate model call with its own prompt. That is where the cost hides. Each of those prompts is not just the agent's own instruction. It carries the system prompt, the tool definitions, and whatever context the pipeline has accumulated so far, because a language model is stateless and the only way an agent knows anything is if you put it in the prompt. So the retriever's four thousand tokens of source documents do not get read once. They get carried into the first extractor's prompt, and the second extractor's prompt, and the reconciler's prompt, and every time they cross a call boundary you pay for all four thousand again. The agents are cheap. The re-reading is the bill.

The bill scales with context, not with agent count

Two facts drive the whole cost structure, and neither of them is the number of agents. The first is that input tokens dominate. On the run this series measures, of the roughly forty-one thousand tokens, the large majority are input, the prompts you send, not output, the text the models generate. Agents are verbose readers and terse writers. They ingest documents, instructions, and each other's notes, and they emit a few hundred tokens of decision. So the cost of a multi-agent system is mostly the cost of what you feed it, and you feed it the same things repeatedly.

The second is that context accumulates across handoffs. In the naive build, each agent's output is appended to a running context that the next agent receives in full, so the prompt grows at every step. The planner sees the brief. The reconciler, five steps later, sees the brief, the retrieved documents, both extractors' full outputs, and its own instruction. The last agent in a naive pipeline carries the entire history of the run in its prompt, and you pay for that whole history on that one call. Multiply an accumulating prompt by fourteen calls and the token count is not six times a single call. On this pipeline it is closer to fifteen. This is why "we only added a couple of agents" turns into a bill nobody forecast: the agents are additive, but the context each one drags along is not. The observability chapter gave you the instrument to see this, per-span token cost across the trace. This chapter is what to do with the numbers it showed you.

Lever 1: minimize the context at every handoff

The single highest-leverage move attacks the token count before any pricing trick applies, and it lives at the exact boundary the hand-offs chapter was about. When an agent finishes, it does not pass its entire working transcript forward. It passes a distilled, structured note that carries only what the next agent needs. The extractor does not hand the reconciler four thousand tokens of raw document plus its own reasoning. It hands a two-hundred-token structured record of the fields it pulled. The reconciler works from that, not from the transcript.

This is the same discipline the hand-offs chapter argued for on correctness grounds, a clean note travels better than a raw dump, and it turns out to be the same discipline that controls cost. A twenty-to-one reduction at a handoff does not just make the immediate prompt cheaper. It stops the accumulation, so the prompt at step six is small instead of carrying the whole run forward. Attack the token count first, because caching and model tiering discount the tokens you send, but minimization removes them, and a token you never send is free at every tier and never needs a cache. This is also the lever with a quality dividend rather than a quality risk: passing less noise forward is the thing that made the run more correct in the first place, so here the cheapest build and the most reliable build are the same build.

Lever 2: tier the models to the difficulty of the work

Not every agent needs your best model, and putting all of them on it is the most common way to overpay. Look at the six-agent cast by the difficulty of the task in front of each one. The planner routes. The retriever fetches. The two extractors pull fields from text against a schema. None of that is the frontier reasoning you pay a premium for, it is mechanical work a small, fast model does reliably. The reconciler resolving genuine conflicts between two extractions and the reviewer making the final judgment are where the hard reasoning lives, and those are the calls that earn the frontier model.

The price gap between tiers is not small. A capable small model runs at roughly a tenth to a twentieth of the price of a frontier model per token. So moving four of six agents, the mechanical two-thirds of the run, from the frontier model to a small one cuts the price of those calls by around ninety percent. You keep the frontier model exactly where its judgment is load-bearing and stop renting it to read documents. The evaluation chapter is how you make this safe rather than a guess: measure each agent's task in isolation, and where the small model holds the same accuracy on extraction or routing, the tier-down costs you nothing in quality. Where accuracy drops, you tier that one agent back up, deliberately, and you know exactly what the frontier model is buying you there. Tiering without per-agent evaluation is just hoping the cheap model is good enough, and hope is not a cost strategy.

Lever 3: cache the static prefix you re-send every call

Some of what you send on every call never changes. The system prompt is identical across all fourteen calls. The tool definitions are identical. The shared task brief and, often, the retrieved source documents are identical for every agent that touches them. In the naive build you pay full input price for that repeated prefix on every single call, which is most of why the bill is what it is. Prompt caching is the mechanism that stops it. You mark the stable prefix once, the provider stores it, and subsequent calls that reuse it read those tokens from cache at roughly a tenth of the uncached input price.

Multi-agent systems are close to the ideal case for caching, because the whole architecture is many calls that share a large, stable prefix. The condition is that the prefix has to be identical and it has to come first, before the part that varies per agent, because a cache matches on the leading tokens of the prompt. So structure every agent's prompt as stable-then-variable: system prompt, tool schemas, and shared context up top, then the one agent's specific instruction and its inbound note at the bottom. Get that ordering right and the expensive, repeated part of every prompt collapses to a fraction of its price, while the small variable tail is the only thing you pay full rate for. Caching does not reduce how many tokens you send, it reduces what the repeated ones cost, which is why it stacks cleanly on top of minimization rather than competing with it.

Lever 4: do not fan out when a single call will do

The cheapest agent is the one you never added. The first chapter of this series made the case on complexity and reliability grounds, and cost is the third leg of the same argument. A task that a single well-prompted call can handle costs one call of a few thousand tokens. The same task decomposed into a six-agent pipeline, purely because multi-agent is the fashionable shape, costs the fourteen-call, forty-one-thousand-token run this chapter has been pricing. That is not a ten or twenty percent overhead. It is on the order of thirteen times more expensive, for output a single call would have produced.

So the discipline is to fan out only where the decomposition earns its keep, where the task genuinely needs separate context windows, distinct tools, or parallel work that a single agent cannot hold at once. Every agent you add is a permanent line on every run's bill, multiplied by your run volume, forever. That is the loop and termination chapter from the cost side: an agent that loops one extra time, or a fan-out that spawns one more worker than the task needs, is not a one-time waste, it is a recurring charge on every run that follows. The most effective cost optimization is often not tuning the pipeline you built. It is noticing that two of its agents were never necessary and deleting them.

Do the math on the bill

Put the four levers on the same run and watch the multipliers stack. Start with the naive baseline: six agents plus their tool calls, about fourteen model calls, roughly forty-one thousand tokens, every one priced at the frontier model with no caching and the full accumulated context re-sent at each step. Call that cost 1.0.

Minimize the context at each handoff and the token count drops by roughly half, from about forty-one thousand to around twenty-one thousand, because you stopped carrying raw transcripts that the receiving agent never needed. That is a 0.5 on the token count alone, before any pricing trick. Now tier the models: the mechanical two-thirds of the calls move to a small model at about a tenth of the price, which cuts the priced cost of the run by roughly another half, call it 0.5 on price. Then cache the static prefix: the system prompt, tool schemas, and shared brief that still repeat across the remaining calls read from cache at about a tenth, trimming what is left by another third or so, call it 0.65. Multiply them, 0.5 times 0.5 times 0.65, and you land near 0.15, roughly a seventh of the naive cost, close to an order of magnitude, for output that is identical because none of these levers changed what the pipeline decides. They changed only what it costs to decide it.

Then the numbers meet reality, which is volume. At a thousand runs a day, a naive run that costs a dollar is a thousand dollars a day and about thirty thousand a month. The same runs at a seventh of the cost are closer to four thousand a month. That gap is not a rounding error you optimize when you get around to it. It is the difference between a per-run cost that fits under what a customer will pay for the run and a per-run cost that does not, which is to say it is the difference between a product with unit economics and a demo that quietly loses money on every request. And the largest single lever in that stack, the one worth reaching for first, is not a pricing feature at all. It is minimization, because it removes tokens instead of discounting them, and a token you never send is the only token that is free at every tier, in every cache, on every retry, on every run you will ever make.

A single call you pay for once. A naive multi-agent run pays for the same context on every call, so the bill scales with what each agent carries, not with how many agents you have. Cost control is not fewer agents. It is fewer tokens per call.

When you do not need any of this

The honest caveat, as in every chapter of this series. If your pipeline runs a handful of times a day, the whole bill is a rounding error and tuning it is a waste of the one resource more expensive than tokens, which is your engineering time. Optimization earns its keep at volume, where a per-run cost is multiplied by thousands of runs and a seventh of the cost is real money every month. Below that line, build the pipeline the clearest way, measure the actual bill with the per-span costs the observability chapter gave you, and optimize only the runs that are actually frequent enough to matter. The one lever that is always worth pulling, at any volume, is the last one: not fanning out when a single call would do, because that decision is free to make and compounds on every run forever. The rest of the apparatus, the tiering and the caching and the aggressive context trimming, earns its complexity exactly when the run count is high enough that a fraction of the cost is a number you would notice on the invoice. For the document-heavy systems this series is about, running thousands of filings and extractions a day, it is a number you notice on the first invoice.

We build production multi-agent systems for document-heavy work in legal, finance, and insurance, where a pipeline runs thousands of extractions and filings a day, so per-run token cost is not a detail, it is the unit economics that decide whether the system is worth running at all. If your agents re-read the same context on every call, and at any real volume they do, the bill is mostly re-reading, and most of it is removable without touching what the pipeline decides. Talk to an engineer or see how we work.