Guides / multi agent system cost calculator
Pricing a multi-agent system run by its step count
A multi-agent system run costs its per-step bundle times the number of steps it takes, and that count is decided by the model at runtime rather than by your configuration. Culpa, a local-first LLM cost, margin, and forecast ledger, prices every call and groups them by run, so a run reports its own total and its own depth.
Computed in your browser, in exact decimal
The per-step figure is the one to watch. A total that rises tells you nothing on its own, because it moves when the unit gets dearer and when there are simply more of them, and those need different responses.
Rates come from Culpa's price book, effective 2026-07-02. Every figure is computed in exact decimal rather than floating point, which is why totals here match an invoice to the cent. Cost is calculated, not provider-reported: it prices the tokens you enter at a published rate.
Why this happens
Pricing a single agent call is easy and pricing a run is the thing anyone actually needs, because a run is what a user experiences and what a customer is charged for. The difficulty is that the multiplier isn't yours to set. How many steps a task takes gets decided during the run, by the model, based on what it finds, so two runs of the same feature can differ several times over with nothing in your configuration changing. That makes the average run a poor planning unit and the distribution the thing to look at. A second effect the simple multiplication misses, and this calculator deliberately leaves it out: each step re-sends the conversation before it, so input grows with step number and a long run costs more than its step count suggests. Treat the figure here as a floor. It's the right floor, and it's the number most teams lack entirely.
What this usually looks like
- You know cost per call and not cost per run.
- Two runs of the same feature differ several times in cost.
- Nobody records how many steps a run took.
- Your pricing assumes an average run depth nobody measured.
- A run occasionally costs many times the typical one and nothing flagged 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 |
|---|---|---|
| Pricing a run from cost per call. | A run is an unknown number of calls, so per-call cost says nothing about what a task costs. | Group calls by run, and report cost per run with its step count beside it. |
| Planning from the average run. | Run depth is decided at runtime and is usually skewed, so the average hides the expensive tail. | Look at the distribution, and price the top decile of runs separately. |
| Treating this multiplication as the whole cost. | Each step re-sends the history, so input grows with depth and the simple product is a floor. | Use it as a floor, then measure real runs to see how far above it you land. |
| Capping output per request and calling it a budget. | That bounds one step, and nothing bounds the number of steps a run may take. | Cap the step count too, which is the only limit that bounds a run. |
Run this check tonight
- Find the step count of your longest run last week and price it above.
- Compare that against your median run, priced the same way.
- Check whether anything limits how many steps a run may take.
- Measure a real run's total against this calculator's floor and note the gap.
The same step, at three depths
Illustrative example
A modelled agent step of 8,000 input and 800 output tokens, priced on Claude Sonnet 5 at its real introductory rates of $2.00 and $10.00 per million from the price book effective 2026-07-02. The same step is multiplied by three run depths. Rates are published, the step shape and the depths are modelled, and the figures exclude the context growth described above.
Nothing about the step changed across those three rows. The only variable is a number the model chose during the run, which is why a per-call cost tells you so little here and why the step count belongs beside every run total you report.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $0.0240 a step | modelled cost of one agent step at 8,000 input and 800 output tokens on Claude Sonnet 5 | calculated | 8,000 input at $2.00 per million is $0.0160 and 800 output at $10.00 per million is $0.0080, giving $0.0240, using the price book's real Claude Sonnet 5 introductory rates effective 2026-07-02. Multiplied by modelled depths that gives $0.0720 at 3 steps, $0.1680 at 7 and $0.4800 at 20, a ratio of 6.67 between the deepest and shallowest. Rates are published, the step shape and depths are modelled, and the figures exclude context growth across steps. |
What a generic answer can’t know
Run depth is decided at runtime and exists only in your own records. A provider sees a sequence of requests with nothing marking where one task ended and the next began, so no invoice and no external dashboard can group them into runs. Culpa carries whatever identifiers you attach, including the run, prices every call from a versioned price book in exact decimal, and keeps the ledger on infrastructure you control. That makes cost per run a sum with its depth beside it, and the distribution visible rather than the average: which task types produce forty-step runs, whether those runs are worth serving, and where a step limit would actually bind.
Questions founders ask next
How do I calculate the cost of a multi-agent run?
Price one step's token bundle, then multiply by the step count. In the modelled example a step of 8,000 input and 800 output tokens costs $0.0240 on Claude Sonnet 5, so a 3-step run is $0.0720 and a 20-step run is $0.4800.
Why do two runs of the same feature cost differently?
Step count. How many times the loop goes round is decided during the run by the model, based on what it finds, so identical requests can take three steps or twenty. In the modelled example that alone is a 6.67 times difference.
Is this calculator the full cost of a run?
It's a floor, deliberately. Each step re-sends the conversation before it, so input grows with depth and a real run costs more than the simple product. The floor is still worth having, because most teams have no per-run figure at all.
How do I stop a run from getting expensive?
Limit the number of steps. A per-request output cap bounds one step and nothing bounds the loop, so a ten-step run costs ten times whatever anyone thought the ceiling was. The step limit is the only one that binds a run.
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-05, rates effective 2026-07-02. Plain text version.