Finance has been asking the same question for months: which team owns that AI API spend? The IT team's answer, until recently, was a spreadsheet reconstruction based on which teams told them they were using which tools. That answer is not good enough for a budget line that has reached five figures per month and is still growing.
Why Token Cost Attribution Is Hard Without Infrastructure
The underlying problem is that LLM API billing is account-level, not team-level. When a developer signs up for an OpenAI API account, all usage charges accumulate to that account. If multiple teams are using a shared organizational account, the bill shows total tokens consumed, total cost, and a breakdown by model. It does not show which team triggered which requests.
Organizations that try to solve this without dedicated infrastructure end up with one of two approaches, neither of which scales. The first approach is one account per team: each team gets its own API credentials and its own billing relationship. This solves the attribution question by making it structural, but it creates new problems: no central visibility, no policy enforcement across teams, and no ability to route traffic based on cost or availability.
The second approach is manual allocation: IT collects usage estimates from team leads each month and allocates costs based on reported agent activity. This works at small scale. It falls apart when teams are running multiple agents with variable usage, when agents run continuously rather than in discrete batches, and when the people responsible for the cost are not the same people who built the agents and are therefore unable to give accurate usage estimates.
How Token Attribution Works at the Routing Layer
The clean solution to token cost attribution is to instrument the request level, not the account level. When every AI API request passes through a routing layer, each request carries a team namespace in its header. The routing layer reads that namespace, records the token count and cost for that request, and accumulates metrics by team in real time.
At the end of any time window, cost by team is a query against the accumulated request log, not a manual reconstruction. The data exists because the routing layer recorded it, not because a team lead reported it.
The practical mechanics work as follows. Each team is assigned a namespace identifier, for example eng-product, ops-support, or data-ml. That namespace is included in the API request header, either set by the team in their agent code or injected by the routing layer based on the API key used to authenticate the request. The routing layer records the namespace alongside the request metadata: timestamp, model, input token count, output token count, computed cost, and response latency.
Cost computation uses the standard token pricing for the model that handled the request. For routing layers that support multiple vendors, costs are normalized to a common currency unit. A request that went to GPT-4o is costed using OpenAI's pricing for that model at that time. A fallback request that went to Azure OpenAI uses Azure's pricing for the equivalent model.
What Finance Actually Needs From the Report
The finance team's question is not "how many tokens did the operations team consume in January." Their question is "how much did AI cost by department and is it within budget." That requires the token count to be translated to a dollar figure, and it requires that figure to be presented with enough context to evaluate whether it is justified.
A useful monthly AI cost report for finance includes:
- Total AI API spend for the period, by team
- Month-over-month change per team
- Model breakdown (which models are being used and their cost per team)
- Request volume (so finance can see whether cost changes are driven by volume or by model choice)
- Budget variance for teams that have defined budgets
Notice that this report does not require IT to manually collect anything. Every field in that report is derivable from the routing layer's request log. The IT team's role changes from monthly reconciliation exercise to occasional configuration update when new teams or agents come online.
A Concrete Illustration
Consider an IT team managing AI infrastructure for a growing healthcare software company. They have four teams running AI agents: a clinical documentation team, a billing and coding team, a patient communications team, and an internal IT automation team.
Before routing-layer attribution, the IT team received one bill from OpenAI each month covering all four teams' usage. Allocating that bill to the four departments required asking each team lead how much they had used that month. The estimates were inconsistent and always summed to less than the actual bill. The remainder was allocated as overhead, which finance was never satisfied with.
After routing all agent traffic through Airia's control plane with team namespaces, the breakdown became precise. The clinical documentation team's GPT-4o usage for note summarization turned out to be the largest cost center at roughly 58% of total spend, which matched intuition given the document length involved. The billing and coding team was using a mix of GPT-4o and GPT-4o-mini, with the mini model handling initial classification and the full model handling edge cases. The patient communications team had the highest request volume but low cost because their prompts were short and they were using a cost-optimized model.
That breakdown gave finance what they needed to make a budget allocation decision. It also gave the clinical documentation team visibility into their cost drivers, which led them to evaluate whether their context window size was appropriate for the summarization quality they were getting.
Budget Alerts and Cost Controls
Attribution is the measurement side. Budget controls are the enforcement side. Once cost is attributed per team in real time, the routing layer can evaluate current-period spend against configured budgets and trigger alerts when teams approach their limits.
A practical configuration looks like this: each team namespace has a monthly budget set by IT in coordination with department heads. At 75% of the monthly budget, the routing layer sends an alert to the team lead and to IT. At 90%, a second alert goes to IT only. At 100%, requests from that namespace either continue with IT notified or are rate-limited, depending on how the policy is configured.
This is not a policy decision that every organization will make the same way. Some IT teams will want hard rate limits at budget cap. Others will prefer soft limits with alerts and post-cycle reconciliation. The routing layer should support both. The point is that the mechanism to enforce any budget policy depends on having attribution data in real time, which requires the routing layer to be in place.
Where Reporting Ends and Cost Optimization Begins
One byproduct of per-team token attribution is that it surfaces optimization opportunities that would not be visible from account-level billing. When you can see that a specific team is consistently using GPT-4 for requests that result in short, factual responses, it raises the question of whether a smaller, cheaper model would produce equivalent output. That is not a governance question. It is an infrastructure cost question that the attribution data makes it possible to ask.
We are not suggesting that IT should be in the business of auditing every team's model selection. Teams own their agent quality decisions. But when the cost breakdown makes it clear that one team is spending three times as much per request as a comparable team doing similar work, that is a conversation IT can facilitate with data rather than intuition.
The routing layer's cost attribution capability and its prompt routing capability compound here. If a team is consistently sending requests that would qualify for a lower-cost model based on prompt complexity, intelligent routing can optionally redirect those requests automatically. That is a configuration option the team enables, not something IT imposes. But it requires the same infrastructure layer that provides attribution to begin with.