# What is Cost Attribution?

Also called cost allocation, spend attribution.

Cost attribution is the practice of assigning machine costs, such as model tokens, tool calls, and compute, to the entity that caused them: a tenant, a feature, an agent, or an individual run. It turns a single aggregate provider bill into a breakdown that can be acted upon, priced against, or optimized.

The mechanism is metadata carried through every metered call. A request tags itself with tenant, feature, agent, and run identifiers; the response's reported usage is recorded against those tags in a durable ledger. Without tagging at call time, attribution after the fact requires reconstructing causality from logs, which is unreliable and usually impossible once a billing period closes.

Costs are not only the model call. A single agent run may involve retrieval over a vector store, several third-party API invocations with their own metered pricing, storage of intermediate artifacts, and orchestration compute that stays occupied while the model generates. Attributing only tokens systematically understates the true cost of tool-heavy agents relative to conversational ones.

Shared and fixed costs complicate the picture. Cached prompt prefixes, warm capacity held for latency reasons, and baseline infrastructure are consumed jointly, and any split between tenants is a convention rather than a fact. Teams generally choose a defensible allocation rule, document it, and keep unallocated costs visible as a separate line rather than distributing them silently.

The output is used for three distinct purposes that pull in different directions. Engineering wants per-feature detail to find waste. Finance wants stable periodic totals reconciled to the provider invoice. Product wants per-customer figures to inform packaging. A ledger granular enough to roll up in all three directions serves everyone; separate pipelines per audience tend to diverge and lose credibility.

## Key points

- Requires tagging tenant, feature, and run at call time
- Tool calls, storage, and orchestration count, not only tokens
- Shared costs need a documented allocation convention
- One granular ledger serves engineering, finance, and product
- Reconstructing attribution after the fact is unreliable

## In practice

Every model call in a platform carries tenant, employee, thread, and run identifiers. Reported input and output token counts, plus per-tool invocation records, are written to a usage ledger row per call. A weekly rollup shows one automated research workflow consuming a disproportionate share of total spend because it re-fetched the same sources on every run, which caching then eliminated.

## Related terms

- [Cost per action](/en/glossary/cost-per-action)
- [Token usage](/en/glossary/token-usage)
- [Quota](/en/glossary/quota)
- [Multi-Tenancy](/en/glossary/multi-tenancy)
- [Observability](/en/glossary/observability)

[Back to the AI Glossary](/en/glossary)