You can get AI cost per team. You cannot get it clean.
Finance wants one number: AI spend per team. You can build it. Five vendor grains normalized, attribution with receipts, estimates that admit they're estimates. What you cannot do is let the number rate a person. The moment it does, the data dies.
The per-engineer version is sitting right there. An afternoon of work. "AI dollars per engineer," a row per name, a bar per row, sortable.
I built everything around it. Then I chained it shut.
You can get cost per team. You can't get it clean. Hold both of those and the build is worth doing. Drop either one and don't build it.
I measured my own AI usage, learned what I needed, and tore the tool down. That was one person measuring himself. The next question arrives with a VP attached: what's this stuff costing us, per team? And under it, the dangerous one: is it worth it?
The first question has an answer. The second is a trap dressed as a spreadsheet.
The FinOps Foundation's State of FinOps 2026 survey (693 practitioners) has 98% of them managing AI spend. It was 63% in 2025. 31% in 2024. Two years, and AI cost went from a corner of the FinOps remit to all of it. Your finance team is part of the 98%.
The same survey concedes the value problem in one line: "Is your AI providing value? No one can answer that question yet." The industry's own scorekeeper, on the record. Refusing to fake the ROI number is the defensible position.
Here is what happens when you build the honest number.
Five vendors, five shapes
Spend lands from Anthropic, OpenAI, Cursor, Copilot through GitHub, and Vertex. None of them agree on what a record is.
- Cursor is the dream grain. Per-member spend in cents (the field is literally
spendCents), per-user daily usage, individual request events with token counts if you ask. - Copilot through GitHub keys every row of its AI usage report to date, model, and username. Gross, discount, and net, three separate columns.
- Anthropic is two vendors in one. Claude Code spend comes back per user, per day, per model. Raw API spend resolves to a workspace and stops. Workbench usage can land with a null API key.
- OpenAI knows which user burned the tokens and refuses to say which user spent the dollars. The usage endpoint groups by user. The cost endpoint groups by project, line item, and API key. OpenAI's own cookbook warns the two don't perfectly reconcile.
- Vertex is the far extreme. The BigQuery billing export resolves to project, service, and SKU. No human appears in it, ever. Per-job attribution is a labeling discipline you impose yourself, and labels only count from the day you applied them.
Before you attribute a single shekel, you're normalizing all five into one record. That sounds like plumbing. It is, and the plumbing is where the lie gets in.
Every normalization step is a small editorial decision about whose spend this was. Nobody audits plumbing.
The shapes refuse to hold still. GitHub has the next change already scheduled: on June 1, Copilot's premium requests become token-metered AI Credits. Eleven days from now, my pipeline eats a brand-new grain for the same product.
Attribution is the whole game
Granular AI-spend monitoring is the number one most-requested tooling capability in that same FinOps survey. Practitioners rank allocating AI cost to business units as harder than allocating traditional infrastructure.
The grain everyone wants doesn't ship from any vendor. You assemble it yourself or you don't have it.
There are two ways to assign a cost that hold up.
Spend attribution maps a workspace or project to a team through a mapping table you maintain by hand. Clean, but only as good as your discipline in keeping the map current. Useless for vendors that never tell you who spent the money.
Roster scope counts a cost against a person's home team. Good for the per-user vendors. It also forces you to define "home team" precisely, so nobody gets counted twice.
For the user-blind vendors, you're stuck estimating. The estimate that works is token share: if a user generated, say, 12% of the workspace's tokens this month, assign them 12% of the workspace's cost.
This is the exact bridge OpenAI forces on you anyway. Tokens by user on one endpoint. Dollars by project on another.
usage: group_by = user_id, model # tokens, per human
costs: group_by = project_id, line_item, api_key_id # dollars, no human
You do the division in between.
The word estimate is load-bearing there. Even the vendors concede it: Anthropic's Claude Code analytics endpoint labels its per-user number an estimated cost.
I made my code say it out loud too. The field is literally null when it's unestimated. Not zero. Zero is a lie and null is the truth.
Run all of that and most of the spend sorts cleanly into team buckets. Some of it doesn't sort, and never will. That gets its own bucket, labeled exactly what it is: we don't know.
Then the number gets seductive
Once you have per-person spend, the obvious move is cost per Jira ticket.
I built it. Split a person's weekly spend across the tickets they committed to that week, weighted by commits. Out comes a clean dollar figure per ticket.
Call the thing what it is: a footprint proxy. It traces where a person's activity landed. It says nothing about effort.
Commits can't tell an 800-line AI-generated diff from an 800-line file someone hand-typed. They say nothing about the day spent reading code, debugging a red herring, reviewing other people's PRs, or chasing an approach that got thrown away.
The number is real arithmetic over fuzzy inputs. That's the most dangerous kind of number, because it looks precise.
METR ran the controlled version of this doubt. A randomized trial: 16 experienced open-source developers, 246 real tasks, early-2025 tools. Measured result: 19% slower with AI. Self-estimate: 20% faster. Call it a 40-point gap between what they felt and what the clock said.
METR has since marked the result historical, the tools moved on, but the perception lesson didn't move anywhere. If a developer's own read of their productivity can miss by 40 points, a commit-weighted dollar figure has no business rating a person.
Lock the scoreboard
So I gated it. Aggregate team and manager views only.
The number is structurally barred from anything individual-facing or evaluative. Not by a policy page. By code paths that don't exist. No per-engineer page, no per-name export, no query that puts a name next to a dollar.
Because the per-engineer version is sitting right there. An afternoon of work. "AI dollars per engineer," a row per name, a bar per row, sortable.
Easy to build, satisfying to stare at, and the fastest way to poison the dataset.
The moment a dollar figure rates people, people game it. Spend learns to look busy. Or to look frugal. Whichever the scoreboard rewards. From then on the number measures the gaming, not the usage.
Wire the caveats in
Three mechanisms.
Show gross and net side by side. Net is vendor-defined and it moves. In January, Google rewired its spend-based CUDs from list-price-plus-offsetting-credit to directly discounted rates: 28% off one-year, 46% off three-year. Same commitment, same usage, a differently painted bill. GitHub ships gross, discount, and net as three columns per row. Show both and let the gap be visible.
Give unattributable spend its own bucket. Don't smear it across people to make the totals tie out. That bucket is the most honest number on the whole dashboard. Its size is a metric. Its trend tells you whether attribution is improving or rotting.
Track the linkage rate. The share of spend you could actually tie to tickets. It's an accounting check, not a confidence score. Conflate the two and a 90% linkage rate starts reading as 90% confidence in the attribution. It isn't.
Stop there
This is not a per-engineer scorecard, and not an input to a performance review. It also can't answer the ROI question, because nobody can yet, including the people whose full-time job is to try.
If your version points a dollar figure at an individual's name in a context that can hurt them, you didn't build observability. You built a weapon aimed by commit counts.
Build the number, label the estimates as estimates, then stop. The leak you're hunting is real and worth finding. But a fuzzy number is allowed to inform a sharp question, never to answer one about a person.
Get that boundary wrong and the data doesn't just become useless. It becomes corrosive.
Exactly one name should ever get a dollar figure pinned to it: your own. Everyone else gets a team.