Guides / multi agent cost tracking
How to track cost across a multi-agent system
Multi-agent cost tracking means attributing spend across agents that delegate to each other, including the context each hand-off re-sends. Delegation multiplies input tokens rather than dividing work. Culpa, a local-first LLM cost, margin, and forecast ledger, prices every call and rolls it up to the agent, the run and the customer that caused it.
Why this happens
Multi-agent systems have a cost shape single-agent systems don't, and it comes from the hand-off rather than from the work. When a supervisor delegates to a worker, the worker needs enough context to act, so the same background is serialised into the input of every agent that touches the task. Three workers means that context is paid for four times: once by the supervisor and once by each worker. None of it counts as waste, and it buys the architecture you chose, but it multiplies rather than adds, and almost nobody models it before building. The attribution problem sits on top. When worker B spends money on behalf of a request that came through supervisor A, the cost belongs to at least three things at once: the worker that spent it, the supervisor that delegated it, and the customer whose request started it. A tool that stores one owner per call has to pick, and whichever it picks makes the other two questions unanswerable.
What this usually looks like
- Adding a specialist agent raised cost more than the work it does would suggest.
- Your input tokens grew far faster than your output tokens as the system got smarter.
- You can see which agent spent the money and not which request it was serving.
- A supervisor looks cheap and the system it coordinates never does.
- Nobody can price a single end-to-end task across the agents that handled it.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Budgeting a multi-agent system as the sum of its agents. | Delegation re-sends context, so the whole costs more than the parts priced independently. | Price a complete task end to end, including every hand-off, before scaling the pattern. |
| Attributing a sub-agent's spend to the sub-agent alone. | It answers which agent is expensive and loses which request and which customer caused it. | Carry the run and customer identifiers through every delegation and roll up all three ways. |
| Passing the full context to every worker by default. | Each worker pays input rate on background it may not need, once per hop. | Pass the minimum each worker needs, and measure the difference rather than assuming it. |
| Adding an agent because the architecture is elegant. | Every additional hop adds a context copy, so elegance has a per-request price. | Price the hop before adding it, and compare against doing the work in an existing agent. |
Run this check tonight
- Count the hops in your most common multi-agent task.
- Measure the context tokens each hop carries, then multiply by the hop count.
- Price one complete task end to end and compare it to what you assumed.
- Try to attribute one sub-agent call to the customer whose request started it.
One task, four copies of the same context
Illustrative example
A modelled supervisor delegating to three specialist workers. Shared context is 8,000 tokens and each agent adds 1,500 tokens of its own instructions plus 600 tokens of output. Priced on Claude Haiku 4.5 at real rates of $1.00 and $5.00 per million from the price book effective 2026-07-02. Token counts and the hop count are modelled.
64% of the task went on sending the same background four times. Doing the identical work in one agent would carry that context once, so the architecture choice, not the workload, set most of the bill.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $0.0500 | modelled cost of one four-agent task, of which $0.0320 is the same context sent four times | calculated | Arithmetic shown in full on this page. 8,000 shared context tokens x 4 agents plus 1,500 own instructions x 4 = 38,000 input tokens, and 600 output x 4 = 2,400 output tokens, priced on Claude Haiku 4.5 at real rates of $1.00 and $5.00 per million from the price book effective 2026-07-02. Every token count and the hop count are modelled. |
| 64% | share of that modelled task spent re-sending context across hops | calculated | $0.0320 of a $0.0500 task total = 64.0%, from the same modelled shape and the same real rates. Reported as a share because the share is the transferable finding: the architecture rather than the workload sets most of the bill. |
What a generic answer can’t know
The cost of a multi-agent system lives in the relationships between calls, and a platform storing one owner per call has nowhere to put a relationship. That's why agent-level dashboards can rank agents and can't price a task: the supervisor's call and the three worker calls are four unrelated rows to them. Culpa carries the run identifier through every delegation and the customer identifier with it, so the same four calls roll up three ways at read time, by agent for engineering, by task for product, and by customer for the finance question. Set that against the revenue the customer pays and a delegation pattern becomes a margin decision rather than a design preference.
Questions founders ask next
Why do multi-agent systems cost more than expected?
Because delegation re-sends context. Each agent needs enough background to act, so the same tokens are paid for once per hop. In a modelled four-agent task with 8,000 tokens of shared context, 64% of the cost is that context being sent four times rather than once.
Which agent should a sub-agent's cost be attributed to?
All of them, at read time. The cost belongs to the worker that spent it, the supervisor that delegated it, and the customer whose request started it. Storing one owner per call forces a choice that makes the other two questions unanswerable later.
How do I reduce multi-agent cost without removing agents?
Cut what each hop carries rather than the number of hops. Passing the minimum context a worker needs, instead of the full background by default, reduces the multiplied portion directly. Measure it per hop rather than reasoning about it.
Is a multi-agent design always more expensive?
Per task, usually yes on input tokens, because context is duplicated. Whether that's worth it depends on what the specialisation buys in quality or latency, which is a judgement the arithmetic informs rather than settles. The point is pricing the hop before adding it.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
How Culpa works
Find the culprit. Not just the total.
Your dashboard shows what you spent. It stops short of who spent it. Culpa shows the conversation, the user and the feature behind it.
Your prompts stay local.
Culpa runs on your own infrastructure. What you send to a model reaches us at no point.
Every dollar has a name.
Follow any charge to the conversation, the user, the feature and the customer behind it.
See the bill before it lands.
Cost your next feature before you ship it. You get the likely bill and the worst case, at best, median, p90 and p99.
Three steps to your first answer.
Change one base URL.
Or drop in the Python or TypeScript library.
Find your most expensive conversation.
In the first session, not the first week.
Cost your next feature before you ship it.
Why the bill went up
Example dashboardCalls traced
418,209
across 3 projects
Spend this week
$378.41
+ $182 vs last week
Failed calls
312
74% retried, and you paid for all of them
+ $182 this week traced to one culprit
Spend over 14 days
Most expensive users
Next week forecast
Graded against reality. Accuracy shown as results land.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-03, rates effective 2026-07-02. Plain text version.