Guides / granular llm cost attribution
Granular LLM cost attribution, and where every tool stops
Granular LLM cost attribution means pricing each individual call and rolling it up to the conversation, customer or feature that caused it. Every tool has a floor below which it aggregates, and nothing recovers detail once it has gone. Culpa, a local-first LLM cost, margin, and forecast ledger, prices every call and keeps that floor at the call.
Why this happens
Ask any cost tool what a single conversation cost and you learn where it stops. Grafana's AI observability publishes per-agent cost breakdown in USD, so its floor is an agent. Datadog's LLM Observability reports cost across AI agents, and its Cloud Cost Management forecasts an ingested vendor invoice, so it has two floors and the lower one is still an agent. Langfuse filters by user and session. Respan sets budgets per key, per customer or org-wide. Dynatrace assesses token cost per model. Every one of those is genuinely useful and every one is a ceiling. The part that matters is what happens underneath it: aggregation is a one-way operation. A total is a sum, and the information needed to divide it back up was discarded at write time rather than stored and hidden. So a tool whose floor is the agent can never answer a question about a conversation, no matter how long you wait or how much history accumulates. The floor is decided the day you instrument, and it's the only cost decision that can't be revisited later.
What this usually looks like
- Your cost view stops at a level above the question you keep being asked.
- A total is correct and nobody can break it into the parts that caused it.
- One expensive conversation sits somewhere inside a monthly figure and can't be pulled out.
- You added a dimension to reporting and it only applies from that day forward.
- Two teams share an agent, and the agent-level cost helps neither of them.
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 |
|---|---|---|
| Assuming detail can be recovered from a total later. | Aggregation discards the split rather than hiding it. Nothing remains to query afterwards. | Record attribution at write time, at the finest level you might ever need. |
| Choosing a floor from today's questions. | The floor outlives the question. A per-agent floor answers nothing about a customer who shares that agent. | Set the floor at the call, then aggregate upward at read time where the answer is cheap. |
| Reading per-user filtering as per-call attribution. | Filtering picks rows from what was stored. If calls were never stored individually, the filter has nothing finer to pick. | Ask what the smallest stored row is, not what the interface can filter on. |
| Sampling traces and keeping cost reporting. | A sampled floor makes every total an estimate, and usually an unlabelled one. | Sample traces if you must and meter cost completely. They're different jobs on the same call. |
Run this check tonight
- Ask your cost tool what your single most expensive conversation last week cost.
- If it can't answer, find the level it does answer at, and write that down as your floor.
- Name a question your business will ask within a year that sits below that floor.
- Check whether cost rows are stored per call or already summed on the way in.
What an agent-level floor hides inside one agent
One shared support agent serving three customers in a month, 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. A tool whose floor is the agent reports one number for all of it. Customer volumes are modelled.
If those three pay the same subscription then one is funding another, and the agent-level number can't show it. The 9.2x spread wasn't lost in analysis. It was never written down.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $178.00 | modelled monthly cost of one shared agent, hiding a 9.2x spread between the three customers behind it | calculated | Three modelled customers 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: $120.00 + $45.00 + $13.00 = $178.00. Customer token volumes are modelled. The point of the figure is that the total is correct and the three components exist nowhere in an agent-level record. |
What a generic answer can’t know
This is the difference that survives every comparison, and it isn't privacy. Culpa's floor is the individual call. Each one is priced from a versioned price book in exact decimal and tagged with the conversation, the customer, the feature, the prompt version and the run that produced it, so every higher level is a roll-up computed at read time rather than a number fixed at write time. That means a question nobody anticipated is still answerable next quarter from data already captured, which is the one property no aggregate can offer at any price. Deployment is a separate decision and it belongs to you: Culpa runs locally by default, and where a backend can't reach your machine it sends through a relay that can append and never read, with your own instance pulling the records down.
Questions founders ask next
What is granular LLM cost attribution?
Pricing each individual call and tagging it with everything that caused it, so cost per conversation, per customer, per feature and per prompt version are all roll-ups of the same stored rows. The opposite is summing at write time, which fixes the level of detail forever on the day you instrument.
Can I add more granularity later?
Only going forward. Aggregation discards the split rather than hiding it, so nothing remains to query retroactively. This is the one cost decision that can't be revisited, which is why the floor is worth setting deliberately rather than inheriting from a tool.
Where do other tools stop?
At different levels, each published on their own pages and read 2026-08-03. Grafana breaks cost down per agent, Datadog reports cost across agents and forecasts an ingested vendor invoice, Langfuse filters by user and session, Respan budgets per key or per customer, and Dynatrace assesses token cost per model. All useful. All above a call.
Doesn't storing every call get expensive?
That's the real trade and it's worth stating plainly. A priced call row is small, far smaller than the trace payload most platforms bill you to ingest, and Culpa keeps it on your own storage rather than charging per gigabyte. The floor costs you disk. Skipping it costs you a question you can never answer.
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, Grafana Cloud AI observability. Last reviewed 2026-08-03, rates effective 2026-07-02. Plain text version.