Every model provider can tell you exactly what you spent. Tokens in, tokens out, by deployment, by day. The number is precise, correct, and almost useless for the conversation you are about to have.
Because the question a finance partner asks is not what did the endpoint consume. It is: what did our customer support capability cost last quarter, is that going up, and why?
Two vocabularies
Infrastructure platforms understand the objects they operate: subscriptions, projects, resource groups, deployments, endpoints, clusters, service identities, API keys. Precise and necessary.
Enterprises make decisions in a different vocabulary: customers, departments, applications, agents, owners, cost centres, approval workflows, business outcomes. Neither vocabulary is better. They operate at different layers, and the translation between them is where a surprising amount of overlooked work lives.
Cost is where the gap is most visible, because it is the one place where somebody outside engineering is guaranteed to ask.
The four questions a token report cannot answer
Which capability was that?
A deployment serves many things. Without attribution at the application and agent level, spend is a single number for a shared resource, and every team's answer to "is that us?" is a guess.
How much of it was error recovery?
This one reliably surprises people. Retries, fallbacks after a provider timeout, and re-runs after a validation failure all consume real tokens. If recovery cost is not separated from first-attempt cost, a reliability problem looks identical to a usage increase -- and gets managed as a budget problem instead of a bug.
Which stage of the workflow?
A multi-step agent might spend most of its budget in one step nobody suspected. Without per-stage attribution, optimisation is guesswork, and the usual outcome is switching to a cheaper model everywhere rather than fixing the one step that was doing something expensive.
Whose budget is it?
Eventually somebody owns the number. If the platform has no model of business units, cost centres, or accountable owners, that mapping lives in a spreadsheet maintained by one person.
What attribution requires
Usefully attributed cost is not a reporting feature bolted on at the end. It requires that the platform already knows things:
- That an application is a real object, not a set of endpoints by convention
- That an agent is identifiable within it
- That a workflow stage is distinguishable, so per-step cost is available
- That a request's retries and fallbacks are recorded as such rather than as more requests
- That there is an owner the total can be assigned to
Each of those is a modelling decision made long before anyone runs a report. Which is why cost attribution is a good diagnostic when evaluating a platform: it is downstream of almost everything else, so a platform that can answer cost questions in business terms has usually got the underlying model right.
The same shape, everywhere
This pattern is not unique to cost. A cloud identity system controls who administers a resource; an enterprise needs to know which employees may use a particular agent. A database secures connections and executes queries; an enterprise needs access that reflects user identity and business purpose without making every end user a database principal. Infrastructure monitoring shows latency and errors; an enterprise wants a browser request connected to the agents, model calls, searches, tools, and retries that fulfilled it, then assigned to an accountable owner.
In each case the underlying service is not deficient. It is answering the question it was built for. Somebody still has to translate, and the only real choice is whether that somebody is your platform or your team.