LLM cost attribution

What is LLM cost attribution?

LLM cost attribution means working out who is responsible for each pound spent on AI models. It is a separate question from cutting the bill, and it has to come first. Before you can decide whether some spending is worth keeping, you need to know which team or part of the business is using it and what results it produced there.

Three questions get confused because all three involve the same invoice, and each needs a different answer from a different person.

The ordering matters more than the distinction. The second and third questions are unanswerable without the first, because reducing spend you cannot locate is guesswork, and judging whether spend was worthwhile requires knowing what it was spent on.

Why does cloud cost tagging not solve it?

Cloud tagging does not work here because there is nothing for a label to stick to. Companies sort their cloud costs by putting tags on resources, such as a server, and a server stays in one place long enough to be labelled. A call to an AI model is different. It is a brief event that lasts about two seconds and then disappears. The only clue that reaches the AI provider about who made the call is the access key used to make it, so every team sharing one key looks identical.

That difference sounds small and it removes the entire mechanism the discipline was built on.

• The provider sees a key, not an organisation. Whatever your invoice is broken down by, it is broken down by things the provider can observe, and your cost centres are not among them.
• Keys are shared because sharing them is sensible. One service credential serving many agents is good practice everywhere except here, where it destroys the only identifier you had.
• The data is not reconstructable later. A cloud resource can be tagged retrospectively. A call that has already happened cannot be, because nothing durable records what made it.
• Volume rules out sampling. Attribution is arithmetic rather than analysis. Sample it and every number is an estimate nobody will defend in a budget meeting.

Which produces the constraint that shapes every decision on this page. Attribution is captured at the moment of the call or it is not available at all, and that makes it an architecture decision rather than a reporting one. Retrofitting it means instrumenting every path that reaches a model.

Which three keys do you need?

The agent, the model and the human it acted for. Most implementations capture the first two and lose the third, which is the one finance actually needs, because a business unit is a collection of people rather than a collection of agents.

Where each comes from, and why the third goes missing.

1. 01
   Which modelAlways available, since the provider bills by it. What it answers: whether a cheaper model would have done, which is the routing question rather than the attribution one.
2. 02
   Which agentAvailable if somebody instrumented it, which is a decision made early and rarely revisited. What it answers: which capability is expensive, and whether that expense tracks its usefulness.
3. 03
   Which humanUsually absent, because the agent calls the model on a service credential and service credentials carry no person. What it answers: the only question finance asked. Without it you can report that agents cost money, which nobody disputed.

The missing third key is not an accounting oversight. It is the same structural problem described at agent identity, where an agent acts on its own credential rather than the requester's, arriving in a different department. Security sees an audit gap and finance sees an allocation gap, and both are the same missing field. Fixing it once closes both, which is the cheapest argument available for funding the work.

What breaks when the unit changes?

Chargeback, and everything resting on the idea that software costs a steady amount per head per month. Because an agent's bill follows the difficulty of each request, one colleague's daily figure can jump by an order of magnitude while their job stays exactly the same.

Four consequences, and the last is the one that catches programmes late.

• Budgets cannot be set per seat. The old model divided a licence count by a headcount. Neither number predicts anything now.
• Variance is a feature of the workload. A complex request legitimately costs more, so a spike is not necessarily waste and cannot be treated as an exception to investigate.
• Showback invites the wrong response. Present raw cost to a team and the rational reaction is to use it less, including for the work where it was paying off. Cost per useful outcome is the number worth showing.
• The cheapest user may be the least productive. Ranking teams by spend, with no denominator, rewards the team that never adopted anything.

What does a naive cost number miss?

Everything that did not finish. Counting only completed runs is the obvious implementation and it understates systematically, because failure consumes tokens at exactly the same rate as success while leaving behind no output to attribute the spend against, so the money disappears into a residual nobody owns.

Four categories of spend that a straightforward implementation quietly loses.

• Failed runs. A run that errors on its final step has paid for every step before it. Attributed to nothing, it lands in an unexplained residual.
• Retries. An automatic retry is a second full cost for one unit of work. Systems that retry silently are the ones where the residual grows fastest.
• Loops. An agent that cannot reach its stopping condition is the single most expensive thing in any estate, and it produces no output to attribute. The stopping-condition argument is at AI agent.
• Evaluation. Running a model to judge another model's output costs real money and belongs to whatever it was evaluating, not to a general engineering line. See agent evaluation.

There is a diagnostic hiding in this. The gap between your provider invoice and your attributed total is the most useful number in the system, because it is composed almost entirely of work that failed, repeated or never terminated. Most teams treat that gap as a reconciliation nuisance. It is the finding.

How do you implement it?

Carry identity through to the call, then record one row per call. Every difficulty on this page comes from the person being lost between the request arriving and the model being reached, so the implementation is mostly about not losing them.

Five steps, and the first makes the rest possible.

1. Pass the requesting user through every hop

   From the interface, through the agent, into the model call, including across any agent-to-agent delegation. If identity stops at the first service boundary, nothing downstream can be attributed to a person.

2. Write one row per call, not per session

   Agent, model, user, tokens in and out, cost, status and timestamp. Session-level aggregates cannot be decomposed afterwards, and the decomposition is the thing you needed.

3. Record failures with the same fields as successes

   A failed call is a cost. If your instrumentation only fires on success, your attributed total will diverge from your invoice by an amount nobody can explain.

4. Reconcile against the provider invoice monthly

   The residual is a metric rather than an error. Watch its trend, because a growing gap means retries, loops or an uninstrumented path somebody added.

5. Report cost per outcome, never cost alone

   Whatever a completed unit of work is in that team's language. This is the difference between a report that improves decisions and one that suppresses use.

One sequencing note. This is far cheaper to build before you have many agents than after, because retrofitting means finding every path to a model across systems built by people who have moved on. It is also the same instrumentation an audit trail needs, so the two should be funded as one piece of work rather than argued for twice.