Stop Asking People to Tag Their AI Spend
When tagging is optional, a large share of AI spend ends up on API keys with no team tag, no workload tag, and no owner. We treat that as a product problem, and the fix is attribution at key issuance.
Paul Merrison 
You will, sooner or later, be asked to break down your team’s AI spend by team. The CFO will want it for chargeback. Your VP will want it for the budget review. Your own engineering managers will want it for 1:1s. And when you go to your AI cost dashboard to produce the breakdown, you will discover that it can’t, at least not for a large share of the spend.
The gap shows up as soon as more than one team shares the AI bill. Engineers create keys to ship a feature. The tag fields that would tie each key to a team, an agent, and a workload stay empty. The fields are right there in the dashboard, and people skip them.
Tetrate Agent Router Enterprise provides continuous runtime governance for GenAI systems. Enforce policies, control costs, and maintain compliance at the infrastructure layer — without touching application code.
Key takeaways
- AI cost attribution fails the same way cloud cost attribution failed: optional tagging never gets done. Untagged keys are where unattributed spend collects.
- The fix is to make attribution a property of key issuance, so every request inherits it automatically. Every key inherits an owner, team, agent, and workload at the moment it’s created.
- Every AI request needs four labels: owner, team, agent, and workload, because each one answers a different manager’s question.
- The routing layer is the right place to enforce this, because it’s the only point in the stack with the full picture at request time.
- Attribution comes before showback and chargeback. Start with showback, and move teams to chargeback once a quarter of stable numbers exists.
This is the universal experience of AI cost attribution right now, and it is not going to fix itself. FinOps teams meet it from the finance side, and platform teams meet it from the key-issuance side. Here are the four mistakes managers make about it, and the one product decision that resolves all of them.
Mistake 1: Relying on people to tag their own AI spend
Cloud cost management taught the industry this lesson over a decade ago. If tagging is optional, it doesn’t happen. Engineers spinning up resources to ship features don’t pause to fill in metadata fields whose value accrues to someone in finance, six months from now. AWS spent ten years learning this. AI cost tooling is currently rediscovering it.
We call untagged spend a product failure. When the product makes tagging optional, optional tagging loses. A dashboard can offer a tag column, and the people creating API keys still won’t see why filling it in is their problem. They are right.
Reminder Slack channels, Friday tagging reviews, and Confluence pages about tagging standards all leave the choice in place. The fix is to remove the choice.
Mistake 2: Reconstructing AI cost attribution from the bill
The next temptation is to push the problem to month-end. Take the invoice, run it through allocation logic: by user, by project, by team. Then produce a chargeback report. This works for cloud spend because cloud resources have stable identifiers that map back to projects.
AI spend doesn’t. An API key called code-agent-key could belong to anyone. The user field tells you who created the key. It leaves out which agent the key serves, which workflow runs through it, and which team owns the workflow. Reconstructing those mappings after the fact requires institutional memory you don’t have: by the time the bill arrives, the engineer who created the key is on a different team, the agent has been renamed twice, and the workload has migrated to a different repo.
The right time to capture attribution is at the moment the key is issued. Anything later is reconstruction from records that no longer exist.
Mistake 3: Tagging the wrong dimension
Even teams that do tag often tag the wrong dimension. They tag a key with one label, “team-platform” or “agent-cost”, which sounds right and is useless. What you actually need on every request is at least four facts:
- Owner. The individual person responsible for the key.
- Team. The team that pays for the spend.
- Agent. The specific agent or application using the key.
- Workload. The use case: coding assistance, security questionnaires, CI automation, research, customer support.
You need all four because each one answers a different manager’s question. Finance wants spend by team. Platform engineering wants spend by agent. A team lead wants spend by user. Product wants spend by workload. The same dollar of spend has to be sliceable four ways, which means each request has to carry all four labels at the moment it is made.
Mistake 4: Treating “untagged” as a valid state
If your cost dashboard lets a request through without attribution, you will have untagged spend forever. Untagged spend is exactly what accumulates when the system tolerates the gap. The only way to drive it to zero is to make the gap impossible.
That means: no key issued without the four labels above. No UI path that skips them. No defaults that paper over missing information. If you can’t say who owns this key and what it’s for, the system doesn’t give you a key.
This sounds bureaucratic, but the friction lasts thirty seconds at key issuance and permanently solves a problem that otherwise gets worse every month.
The fix: attribution at provisioning
The single architectural choice that makes AI cost attribution work is this: attribution is a property of key issuance. Every key, at the moment it’s created, inherits an owner, a team, an agent, and a workload. Those values flow with every request the key authenticates. They appear on every line of the cost ledger automatically. Nobody types anything into a tag field. Nobody forgets.
In Tetrate Agent Router Enterprise, every token is attributed to a person, team, agent, or project. The showback and chargeback dashboards group spend by any of those. The CFO’s chargeback report and the engineering manager’s 1:1 spend report come out of the same data, sliced differently. There is no “tagging review” anywhere in the process.
The consequence is that the cost dashboard stops being a separate concern from the routing platform. They become the same product. The routing layer is the only point in the stack that has the full picture: who issued the credential, who’s using it, which agent it belongs to, and what workload it serves. So that’s where attribution belongs.
Showback or chargeback: pick the model after attribution works
Attribution answers who spent what. Showback and chargeback, which teams regularly conflate, are two ways to act on that answer. Showback reports each team’s AI spend to that team, its leadership, and the FinOps team without moving money. It is the right starting model because it builds trust in the numbers before anything is billed. Chargeback bills the spend to each team’s actual budget. It is the right mature model because a cost that lands on a budget changes how a team spends.
| Model | What happens | When to use it |
|---|---|---|
| Showback | Per-team spend is reported, no money moves | First quarters of attribution, while teams validate the numbers |
| Chargeback | Spend is billed to each team’s budget | Once a quarter of stable, undisputed numbers exists |
| Hybrid | Charge by team, show by agent, workload, and model | Teams that want budget accountability by team and detail on every other slice |
The four labels, plus the model each request records, make every slice available: allocation per team for finance, per application or agent for platform engineering, and per model for the routing decision. Per-model allocation is the slice teams forget to plan for, and it is the one that settles arguments about whether the expensive frontier model is worth its rate.
Implementing attribution and chargeback at the gateway: five steps
- Require the four labels at key issuance. Owner, team, agent, and workload, with no UI path that skips them.
- Route all provider traffic through the gateway. A label only covers the spend that passes the point where the label is enforced, so direct-to-provider keys have to be retired or re-issued.
- Price each request as it happens. Token counts are multiplied by the serving model’s rate, or by an amortized GPU-hour cost for models you host, and booked to the key’s labels. The rates and the formula are covered in cost per token.
- Publish showback views per team, agent, workload, and model. The per-team walkthrough is in AI cost visibility by team, user, and customer.
- Move to chargeback once the numbers stay stable for a quarter. Pair chargeback with budgets enforced in the request path, so the bill and the cap come from the same data. Where chargeback sits in the wider framework is covered in AI cost governance.
What you get when AI cost attribution works
When attribution is provisioned, four reports become trivial:
- Top keys by spend. Concentration is real and worth knowing about. That’s where your attention pays off.
- Spend by team. Chargeback, capacity planning, renewal conversations.
- Spend by agent. Which internal tools are worth their cost. Which ones have grown faster than anyone realized.
- Spend by workload. Which use cases the company is spending its AI budget on, which can differ from the ones that get talked about in standup.
None of those reports require a manual tag pass. They are byproducts of issuing keys correctly in the first place.
Tetrate believes the routing layer is the right place to capture AI cost attribution, because it’s the only place in the stack that has the full picture at request time: who issued the key, who’s using it, which agent it belongs to, what workload it serves. Agent Router Enterprise provides cross-team cost attribution, showback, and chargeback. Built on the Agent Router project (formerly Envoy AI Gateway) at the Agentic AI Foundation (AAIF), it gives engineering leaders a cost breakdown by person, team, agent, or project. If you’re trying to answer “where is our AI spend actually going?” for your own team, start a fast-track evaluation: first routed request under five minutes, nothing to install.
Frequently asked questions
What is AI cost attribution?
AI cost attribution is the practice of tying each unit of AI spend, typically each API request or each token consumed, back to the team, person, agent, and workload it belongs to. Without it, AI costs show up as a single line on the bill, with no basis for AI cost allocation across the parts of the business that incurred them. It’s the foundation for chargeback, capacity planning, and ROI analysis on AI investments.
What is the difference between showback and chargeback for AI spend?
Showback reports each team’s AI spend without billing it, and chargeback bills the spend to the team’s actual budget. Showback comes first, because teams need a quarter of stable numbers before money moves. Both depend on the same attribution: every request labeled with owner, team, agent, and workload.
Can AI spend be charged back by model?
Yes. Each request carries the model that served it and its cost, priced per token for API providers or as amortized GPU-hours for models you host, so chargeback can be sliced per model as well as per team. The per-model view settles whether a frontier model’s rate is worth paying on a given workload.
Why doesn’t manual tagging work for AI spend?
Manual tagging is optional friction that benefits someone other than the person filling it in. Engineers creating API keys to ship features don’t pause for metadata fields whose value accrues to finance teams. Cloud cost management spent a decade learning this, and AI cost tooling is rediscovering it now. The fix is to make attribution mandatory at key issuance.
How is AI cost attribution different from cloud cost attribution?
Cloud resources have stable identifiers, such as account IDs, project IDs, and resource tags, that map cleanly to organizational structure. AI spend flows through API keys, which are issued ad hoc, often named arbitrarily, and sometimes shared across workloads. Without a structured issuance process, there is no reliable way to map an AI charge back to the team or workload that incurred it. The fix is to capture attribution at the moment the API key is created.
What labels should every AI request carry?
At minimum, four: an owner (the individual responsible), a team (who pays), an agent (which application is making the call), and a workload (the specific use case: coding, security, CI, research, etc.). Each label answers a different manager’s question, so all four need to be present on every request.
How do you allocate AI spend by team without per-user API keys?
Per-key attribution at issuance is the cleanest model. If multiple users share a key, for example, a service account used by a CI pipeline, the team and workload are still well-defined at the key level, even if no individual user is. Issue separate keys for separate teams or agents, and the breakdown takes care of itself.
What happens to existing untagged API keys?
You have to do a one-time backfill. For high-spend keys it’s worth the effort: identify each key’s owner, team, agent, and workload, then label the key. For the long tail of low-spend test keys, the simpler option is to rotate them: issue replacements through the new attribution-required flow and let the old ones expire. Either way, the goal is to eliminate “untagged” as a state the system permits.
Paul Merrison 
