The bill arrives and it is larger than last month. Somebody asks why. The honest answer, in most organisations running agents, is that nobody knows — there is a total, there is maybe a per-model breakdown, and beyond that the spend is an undifferentiated mass. Which feature drove it? Which customers? Was it more usage or more expensive usage? The data to answer that was available at request time and nobody captured it.
Attribution is the unglamorous discipline of tagging spend as it happens so that these questions have answers. It is not hard. It is just easy to postpone until the month you urgently need it, at which point the history you want does not exist.
What changed in 2026
- Agent workloads made per-request accounting insufficient. One user action now fans out into many model calls across subagents, retries, and tool loops. Attribution had to move from "cost per API call" to "cost per unit of work someone asked for".
- Unit economics became a product question. Teams shipping AI features started needing gross margin per feature, which is a different artefact from a cloud bill and cannot be derived from one.
- Caching complicated the arithmetic. Cached input costs a fraction of fresh input, so two features with identical token counts can differ substantially in real cost. Attribution that does not split the two misranks them.
- Multi-tenant cost allocation stopped being optional. Once one customer can trigger materially more spend than another on the same plan, per-tenant visibility becomes a pricing input rather than a nice-to-have.
What to tag, and where
The core practice is small: attach identifiers to every model call at the moment you make it, and carry them through nested calls.
| Tag |
Answers |
Notes |
| Feature / surface |
Which product area costs what |
The single most useful tag |
| Task type |
Which kinds of work are expensive |
Enables routing decisions |
| Tenant / customer |
Who drives spend |
Needed for pricing and abuse detection |
| Trace ID |
What one user action really cost |
Ties fan-out back to a single request |
| Model and effort |
Whether config changes moved the needle |
Makes tuning measurable |
| Outcome |
Cost of success vs cost of failure |
Usually the biggest surprise |
The trace ID is the one people skip and later wish they had. Without it you can see that a hundred calls happened; you cannot see that eight of them were one user pressing one button. In a fan-out architecture that distinction is the whole picture — subagent architecture makes the aggregate look alarming until you learn how many calls constitute one task.
The line items people miss
Retries. A call that failed and was retried cost money twice and produced value once. Most reporting counts it as ordinary usage. If your retry rate moves, your cost per successful task moves with it, and nothing in a token-total dashboard will show that.
Abandoned work. An agent that ran for forty steps before the user navigated away consumed real budget. Whether you count that as feature cost or waste is a decision worth making deliberately, because leaving it uncounted flatters your unit economics.
Input you did not write. Agents that read files, fetch pages, or receive large tool results pay for those tokens. Teams modelling cost purely on generated output routinely under-forecast by a wide margin, particularly on research-style workloads.
Cache reads versus cache writes. Writing to cache costs more than ordinary input; reading from it costs much less. A feature with a stable prompt prefix and high traffic can be dramatically cheaper per call than its raw token count implies. Prompt caching explains the mechanism; the point for attribution is that you must record the split, not just the total.
Evaluation traffic. Judge models scoring production samples are real spend, and they scale with the traffic they measure. Tag them separately or they will quietly inflate whichever feature they happen to be evaluating.
Turning numbers into decisions
Attribution that does not change a decision is telemetry theatre. Three questions justify the effort.
Which feature is worth its cost? Cost per task next to the value of that task is the only comparison that matters. A feature costing more per use than it returns is a product decision, and it stays invisible under an aggregate bill.
Where would routing help? If one task type dominates spend and is not the hardest work you do, it is a candidate for a cheaper model or a lower effort setting. Attribution is what identifies the candidate; reasoning effort controls is what you do about it.
Is anyone unprofitable? In per-seat pricing, per-tenant attribution reveals the distribution behind the average. There is usually a tail, and finding it before it grows is considerably easier than after.
Common mistakes
- Reconstructing attribution from logs after the fact. Always incomplete, always disputed, always more work than tagging would have been.
- Tagging only the top-level call. Nested subagent calls inherit nothing and become an unattributed remainder that grows over time.
- Reporting tokens instead of money. Token counts are not comparable across models. Convert to cost at ingest.
- Ignoring the cache split. Two identical token counts can differ several-fold in real cost.
- Too much granularity. Per-request dashboards are impressive and unused. Attribute at the level you would act on.
- No baseline before an optimisation. Without a before, the after is a number with no meaning.
FAQ
Is this not just what my provider's dashboard shows?
Provider dashboards report by API key, model, and time. They do not know what a feature is, which customer triggered a call, or that six calls were one task. Those are application-level facts only your code can supply.
How much overhead does tagging add?
Effectively none at request time — it is metadata on a call you are already making. The real cost is the discipline of threading identifiers through nested calls, which is a small amount of plumbing that gets much harder to retrofit later.
What granularity should I start with?
Feature and trace ID. Those two answer most questions and are the hardest to add retroactively. Tenant next if you are multi-tenant. Everything else can wait.
How does this relate to observability?
It is the same instrumentation viewed through a different lens — the traces from AI agent observability already carry most of the structure. Attribution is largely a matter of attaching cost to spans you are probably already emitting.
Where to go next
For bounding spend once you can see it, read agent token budgets. For benchmarking your figures against typical workloads, AI agent cost per task, and for the broader set of levers, AI inference cost optimization.