How to Set Up Cost Attribution for AI Usage

Understand what the invoice cannot tell you

A model provider bills against an account or a key, in tokens. It has no idea which feature made the call, which customer benefited, which version of your prompt was in use, or whether the request was a retry. That means the most important cost questions — which feature is expensive, which tenant is unprofitable, what did last week's change cost — cannot be answered from billing data at all.

Everything below therefore happens inside your application. Provider-side controls such as separate keys per environment help a little, but they stop at the account boundary and quickly become unmanageable as a way of splitting spend.

Record the fields at the moment of the call

Wrap model access in one place and have that layer emit a record for every call: input and output token counts, the model and its exact version, latency, the feature, the tenant or account, the user where relevant, the workflow step, a conversation or trace identifier, and whether this was a retry.

Two of those deserve emphasis. The conversation identifier is what lets you roll several calls up into the cost of one user interaction, which is the unit that actually matters. The configuration version is what lets you attribute a cost change to the release that caused it, rather than arguing about it later.

Convert tokens to money in one place

Keep a small price table mapping model and version to input and output rates, and apply it when the record is written so cost is stored as a number rather than recomputed by every dashboard. Version the table, because rates change and historical records should keep the price that applied at the time.

Add the non-model costs the same way where they are material: vector search, reranking, embedding generation, document parsing and any third-party enrichment. A picture that includes only the language model will systematically understate retrieval-heavy features.

Roll up to the units people decide with

Aggregate the records into cost per conversation, per document processed, per ticket resolved, per active seat and per account. These are the numbers that connect to commercial decisions, because they can be compared with a price, with a human process, or with the revenue the interaction supports.

Watch a high percentile as well as the mean. Cost distributions in AI systems are heavily skewed, and averages hide the long agent loops, oversized contexts and pathological sessions where both the money and the quality problems tend to live.

Make it visible where the work happens

Put cost on the same dashboard as latency and error rate, broken down by feature and tenant, and give each feature an owner who sees it. Cost data that lives only in a finance report reaches the people who can approve a budget rather than the people who can change a prompt.

Alert on the ratio, not the total

Total spend rises with adoption, so alerting on it produces noise and late warnings. Alert instead on cost per unit of work, which moves when something regresses: a prompt that grew, retrieval that started returning more, a router sending more traffic to an expensive model. Pair those alerts with hard limits — spend caps, per-tenant ceilings, agent step limits — because an alert is a message and only a limit is a control.

Use it to answer real questions

Once attribution works, a set of questions becomes routine: which features cost more than they earn, which accounts are unprofitable at their current plan, what a prompt change cost, whether a smaller model would be adequate for a given workflow, and what a proposed pricing change would do to margin.

That last one is the point. Attribution is not an accounting exercise; it is what lets pricing, product and engineering argue from the same numbers instead of from three different guesses.