Your provider invoice says you spent a large amount on inference last month. It does not say which team, which product, which customer, or which agent. That gap is where AI cost programs stall: without attribution, cost reduction is a blunt instrument applied to the whole platform, and the teams generating the spend never see the consequence of their choices.

The important property of attribution is that it cannot be recovered retroactively. If the call did not record who it was for, that information is gone. Provider-side reporting can be sliced by API key at best, which is far too coarse.

The Dimensions That Matter

Agent. Which agent made the call. The baseline dimension and the easiest to capture.

Connection. Which agent-to-resource link the call went through. More useful than it sounds: an agent typically has several connections with different cost profiles, and connection-level data localizes cost to a specific integration.

Principal. The human or system on whose behalf the agent acted. This is the dimension most often missing and the one that answers "which user is generating this cost" — essential for shared agents, and doubly so when the cost is passed to customers.

Team or cost center. The organizational owner. Usually derived from the agent's ownership rather than recorded per call, which is fine as long as ownership is recorded and versioned — an agent that changes owners should not retroactively reassign historical cost.

Tenant or customer. For multi-tenant products, which customer the work was for. This is what makes per-customer margin computable, and it is what a pricing decision depends on.

Task or trace. The unit of work. Turns "we spent this much on inference" into "this workflow costs $0.34 per execution," which is the number a product decision actually needs.

Alongside these, record the cost inputs: model and version, input and output token counts, cached token counts, tool calls made, and the pricing rate applied. Storing the rate matters — provider prices change, and a stored rate keeps historical figures reproducible instead of shifting when you update your price table.

Attribution Must Come From the Session

The most consequential implementation detail: identifiers must be taken from the authenticated context, not from parameters the caller supplies.

A tenant identifier passed in a request body is forgeable. In a chargeback system, that means a team can attribute its spend to another team, and the incentive to do so is direct. In a customer-billing system, it means a customer could attribute their usage elsewhere.

The correct flow: the agent authenticates, the session resolves to an agent identity and an asserted principal, and those values are attached to the metering record by the enforcement point. The agent does not get to state who it is acting for in a way that affects billing — it proves it, through the token it presents. This is the same requirement that makes insider-threat attribution work, and the same one that token exchange exists to satisfy.

Where a call is genuinely autonomous with no human principal, record that explicitly rather than defaulting to a service identity that also appears on human-directed work. Conflating the two makes both attributions useless.

Showback Before Chargeback

Two models, different costs to introduce.

Showback gives each team visibility into its own consumption without moving money. No finance integration, no budget negotiation, no disputes about allocation rules. It is a dashboard and a weekly digest.

Chargeback actually bills the cost to the team's budget. Stronger incentive, considerably more organizational work: allocation rules must be agreed, disputes need a process, and finance has to be involved.

Start with showback. In practice, most of the behavior change comes from visibility alone — a team that sees it spent $8,000 on a feature nobody uses will act on that without being billed. Chargeback becomes worth the overhead when spend is large enough that budget ownership genuinely needs to move, and it is much easier to introduce after teams have had showback data for a quarter and trust the numbers.

Either way, make the reporting available to the people who can act on it, at a cadence short enough to matter. Monthly reporting on a metered service is too slow; weekly is usually the right cadence, with daily available on demand. See visualizing AI usage and cost.

Allocating Shared Costs

Not everything attributes cleanly, and this is where showback programs get argued into paralysis.

Platform overhead — the gateway, the audit store, the observability pipeline, the control plane itself. No single team caused it.

Shared agents used by many teams. Per-call attribution handles the marginal cost; the fixed cost of building and maintaining the agent does not attribute per call.

Cached and batched savings. When prompt caching makes one team's call cheap because another team warmed the cache, who benefits? See prompt caching to cut inference cost.

Reserved capacity. Committed spend that is cheaper per unit but must be paid regardless of use.

Practical approach: allocate what attributes directly, then distribute the remainder by a published rule — proportional to attributed spend is the most defensible default because it is simple and roughly tracks benefit. Alternatives (per seat, per team, flat) all have cases where they are fairer and cases where they are absurd.

The thing that matters is publishing the rule and keeping it stable. Every allocation rule is arguable; an unpublished or frequently-changed rule is worse, because it makes the numbers untrustworthy and gives teams grounds to dismiss them. See FinOps for AI agents and measuring the ROI of AI agents.

Cost Per Unit of Value

Attribution's real payoff is not knowing what things cost. It is knowing what things cost per unit of value, which is the only form in which cost data supports a decision.

Useful denominators: cost per resolved support ticket, per completed workflow, per document processed, per active user, per transaction. Cost per successful task specifically — not per call — because a cheap model that fails and retries can cost more than an expensive one that succeeds first time.

That number is what makes trade-offs legible. If a workflow costs $0.34 and saves twenty minutes of human work, the decision is easy. If it costs $4.20 and saves two minutes, it is a different conversation. Neither conversation is possible from an invoice total.

Tracking it over time also catches silent regressions: a provider model update that increases verbosity raises cost per task without changing any code, and cost per task is where that shows up first. See agent evaluations: catching quality regressions.

Common questions

Can I attribute spend from provider-side reporting alone?

Only to the granularity of the API key, which is far too coarse — and issuing a key per team to work around that multiplies your credential exposure while still missing principal, tenant, and task. The workable answer is metering at your own gateway with attribution captured at call time, then reconciling the total against the provider invoice as a correctness check. See securing LLM provider API keys.

How accurate does cost estimation need to be?

Accurate enough to drive decisions, which is usually within a few percent. Token counts are exact, so the main sources of error are pricing table staleness and unaccounted-for features like cached tokens or batch discounts. Reconciling your metered total against the invoice monthly tells you your error rate; if it is under a few percent, the attribution is good enough for showback and for most chargeback purposes.

What about the cost of tool calls and infrastructure, not just inference?

Include them, because inference is often not the dominant cost. Tool calls to paid APIs, vector store operations, sandbox execution time, and egress all attribute the same way if the call passes through a metered path. Agents that do heavy retrieval or code execution can have infrastructure costs exceeding their inference costs, and a program that meters only tokens will optimize the wrong thing.

How do I handle attribution for long-running or multi-agent tasks?

Propagate the task identifier and the originating principal across every hop — model calls, tool calls, sub-agent dispatch — so all downstream spend rolls up to the originating task. Without propagation, an orchestrator's spend attributes to the orchestrator and the sub-agents' spend attributes to themselves, and nothing tells you what the workflow cost. This is the same identifier propagation that makes forensic reconstruction possible.

How Praesidia approaches attribution

Praesidia meters every governed call and attributes it across the dimensions showback actually needs, from the acting agent up to the owning team and down to the individual task — with identifiers taken from the authenticated session rather than from request content, so attribution cannot be reassigned by a caller. Cost inputs are stored alongside the applied rate, which keeps historical figures reproducible when provider prices change.

Because the same records carry latency, guardrail outcomes, and task identifiers, cost can be reported per unit of work rather than only per call, and task identifiers propagate across sub-agent dispatch so multi-agent workflows roll up. Aggregates are exposed per connection, agent, team, and organization for showback without custom queries. See per-connection usage and cost tracking and the Praesidia documentation.