Guides / track llm cost by agent step
How to track LLM cost by agent step
To track LLM cost by agent step you carry a trace identifier through every call the run makes, then sum the priced calls back to that identifier. Culpa, a local-first LLM cost, margin, and forecast ledger, prices each call from a versioned price book and attributes it to the step and the run that produced it, so a run total exists rather than a pile of calls.
Why this happens
Providers bill per call. Agents fail per run. That mismatch is the whole problem and it isn't solved by better dashboards. A single user request can become a planning call, four tool-selection calls, a retrieval summarisation and a final answer, each arriving at the provider as an unrelated request with its own usage block. Sum them by model and you learn what the month cost. Sum them by run and you learn which runs are worth having. The join between the two is an identifier you generate at the start of the run and pass down every hop, including the ones inside libraries you didn't write. Where that identifier gets dropped is where attribution stops, and it usually gets dropped at exactly the boundary you most want to measure: the tool call, the retry, the sub-agent.
What this usually looks like
- You know last month's total and can't say what one agent run costs on average.
- A run that failed halfway still cost money and nothing records that it failed.
- Costs look fine per call and the per-run figure nobody computes is the alarming one.
- Retries are invisible, because a retried call looks like a first attempt.
- Two runs of the same workflow cost very differently and nobody can say which step diverged.
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 |
|---|---|---|
| Attributing by model instead of by run. | Model totals tell you about your rate card. Run totals tell you about your product. | Generate a run identifier at the entry point and carry it to every call underneath. |
| Letting the identifier stop at a library boundary. | Framework-issued calls are usually the expensive ones, and they're the ones that lose the tag. | Check a real trace and confirm every call carries the run id, including framework-issued ones. |
| Counting a failed run as free because it produced no answer. | It burned tokens up to the point it broke, and those tokens bought nothing at all. | Record the run outcome beside its cost, so failed spend is a number rather than a feeling. |
| Measuring step count and calling it cost. | Steps aren't equal. One retrieval summarisation can outweigh six routing calls. | Price each step from a rate book and rank steps by money rather than by frequency. |
Run this check tonight
- Pick one agent run and try to state its total cost without adding anything up by hand.
- Follow a trace and count how many calls carry your run identifier against how many exist.
- Find your most expensive single run last week, and say what made it expensive.
- Compare the cost of runs that succeeded against runs that failed partway.
Where the money sits in one agent run
A modelled seven-call run on Claude Haiku 4.5 at real rates of $1.00 and $5.00 per million from the price book, effective 2026-07-02. The point is the spread across steps, not the total, because the spread is what per-call reporting hides. Token counts per step are modelled.
One call out of seven carries 63% of the run. Ranked by call count that step looks ordinary, and ranked by money it's the entire optimisation. That inversion is why step-level attribution earns its implementation cost.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $0.0516 | modelled cost of one seven-call agent run on Claude Haiku 4.5 | calculated | Arithmetic shown in full on this page, using real rates of $1.00 and $5.00 per million from the price book effective 2026-07-02. The seven-step shape and every token count are modelled, not measured. The figure is on the page to show the spread across steps rather than to claim a typical run cost. |
| 63% | share of that modelled run carried by a single retrieval summarisation step | calculated | $0.0325 of a $0.0516 run total = 63.0%, from the same modelled step shape and the same real rates. Reported as a share because the share is the transferable finding: one call in seven can dominate a run while looking ordinary in a call count. |
What a generic answer can’t know
A provider dashboard sees requests, and it sees them per key and per model because that's all it was given. It has no idea which of your requests belonged to the same user action, so the concept of a run doesn't exist there and can't be added later from the invoice. Culpa builds the run because it records the identifier at capture time, prices every call from a versioned price book in exact decimal, and keeps the ledger on your own infrastructure so the trace and the money live in the same place. What that buys past a total: the most expensive run last week rather than the most expensive model, the cost of runs that failed, and margin per customer once you set those runs against what the customer pays you.
Questions founders ask next
How do I track LLM cost per agent step?
Generate an identifier when the run starts, pass it to every call the run makes, and record it alongside the token counts. Price each call from a rate book, then group by the identifier for a run total and by step name for the breakdown within it. The hard part is coverage, not arithmetic.
Why can't I get this from my provider's dashboard?
Because the provider never sees the relationship between your calls. Each request arrives independently, so a dashboard can group by key, model and time and nothing else. A run is a concept that only exists in your application, so the identifier has to come from there.
What usually breaks step attribution?
A library boundary. Calls your own code makes carry the tag because you wrote the call. Calls a framework makes on your behalf, during tool selection, retries or sub-agents, are the ones that lose it, and those are usually the expensive ones.
Do failed runs need to be measured separately?
Yes, and they rarely are. A run that broke halfway still burned every token it spent getting there, and those tokens bought nothing. Recording the outcome beside the cost turns wasted spend into a number you can act on.
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.