AI cost allocation: getting token spend onto the right team

Why this is harder than cloud allocation

Cloud cost allocation is a solved shape: resources carry tags, tags roll up to accounts, accounts roll up to teams, and the whole discipline is about tag hygiene. AI spend has no equivalent. A token is consumed by a request that carries an API key and nothing else you chose.

So instead of tagging, you get whatever dimensions the provider decided to expose, plus one dimension only you can see.

The four keys, and how to actually use them

1. The API key

The most reliable dimension because every provider records it, and the cheapest to improve because keys are free. One key per project, minted at project start, is the closest thing to a tag that exists in this ecosystem. The failure is the opposite: one shared organization key, which converts your entire metered bill into a single unattributable number that no downstream tool can rescue.

2. The workspace or project

A provider-side container that groups keys. Useful when you have more keys than you want to enumerate, and the natural place to hang a per-team budget. Anthropic uses workspaces, OpenAI uses projects. Note that Anthropic attributes default-workspace usage with a null workspace id, so a naive group-by silently drops it into an unlabelled bucket.

3. The user

Available where a seat exists. Anthropic exposes per-user Claude Code cost through a separate analytics endpoint that returns each user by email with estimated cost per model, plus sessions, lines of code, commits and pull requests. Cursor returns per-member spend directly. This is the dimension finance asks for and the one most likely to be misread, because per-user spend is not per-user value.

4. The repository

The dimension engineers actually want and no provider can supply, because the provider never learns what directory you were working in. It only exists in the transcript the agent CLI writes locally, which records the working directory alongside each event.

Getting per-repo attribution right

The mechanics are simple and the edge cases are where every home-grown script fails. Each event carries a working directory; you canonicalize that directory back to a repository and roll up. The canonicalization is the hard part.

• Worktrees. A git worktree contains a pointer file rather than a .git directory. Resolve it back to the main checkout or every branch becomes its own project.
• Nested checkouts. A repo one level inside another directory the agent was launched from must resolve to the repo, not the parent.
• Parallel workspace tools. Layouts like ~/conductor/workspaces/<repo>/<branch> need introspection to find the underlying repository.
• Non-repo paths. A temp directory, a home directory, or a bare UUID resolves to nothing and belongs in an "Other" bucket. Forcing it into a real project inflates that project.
• Privacy. If you send this anywhere, send the basename rather than the full path. Colliding basenames merging into one row is a better outcome than shipping the parent directory structure of everyone's laptop.

Showback, then chargeback

The FinOps Foundation draws the line cleanly: chargeback sends the expense to a product or department P&L, while showback shows the same charges but keeps them on a central budget. Both are legitimate; the sequencing is what people get wrong.

The prerequisite row is the whole decision. Charging a team for AI spend they cannot influence, because the model choice is set centrally or their seat cost is fixed, produces a quarter of arguments and no behaviour change. Mature FinOps programs typically run both in parallel for different workloads rather than migrating wholesale from one to the other.

A worked allocation

Twenty developers, $2,352 a month of measured token value at Sonnet 5 rates, using the medium profile from the pillar page. Two views of the same money, both illustrative.

Now the same money by person, which is where the per-seat blind spot shows up. Suppose the top three developers account for 55% of token value, about $431 each per month, the median developer sits near $95, and six developers are under $15.

flat seats        20 x $100 / mo                = $2,000 / mo

top 3 users       ~$431 each of token value    = $1,294   (paying $300)
middle 11         ~$95 each                    =   $968   (paying $1,100)
bottom 6          <$15 each                    =    $90   (paying $600)
                                                 -------
measured token value                             $2,352

readings:
  the top 3 are the best value in the org, not the problem
  the bottom 6 seats cost $600/mo and return $90 of use
  a flat seat price is a cross-subsidy, which is fine
  once you have decided it deliberately

The traps

• A shared key is unattributable and stays that way. No tool can retroactively split spend that arrived under one credential. Mint per-project keys before you need the data, not after.
• Per-seat plans hide usage skew by design. That is what a seat price is for. Just do not then claim you have cost allocation, because you have cost distribution.
• Prepaid and metered do not add up. Allocating $2,000 of subscription capacity and $340 of metered spend into one "$2,340 of AI cost" produces a number that is true and useless. Keep the two columns apart all the way to the report.
• Estimated cost is estimated. Per-user figures from vendor analytics endpoints are labelled estimates for a reason. Do not reconcile them against an invoice to the cent and then distrust the whole pipeline when it does not tie out.
• Attribution lag is real. Anthropic's usage data typically appears within five minutes; the Claude Code analytics endpoint deliberately withholds anything less than an hour old for pagination stability. Both are fine for monthly allocation and useless for real-time control.

Questions people ask

Keep reading

Continue through AI spend and governance with AI seat management: provisioning, idle seats, and the offboarding gap.