AI Spend Attribution — definition, why per-API-key isn't per-developer, and how to attribute LLM token cost

Definition

AI spend attribution is the practice of tracing LLM token cost back to the developer, team, repo, and workflow that generated it. It's the move from "we spent $14,200 on Anthropic last month" to "this developer, on this repo, running this workflow, burned this much — and here's the split across the team." It is the first and load-bearing stage of TokenOps: without attribution there is no accountability, and every optimization downstream is guesswork.

Attribution is the same discipline FinOps brought to cloud a decade ago. A cloud bill used to be one opaque monthly number until tags, accounts, and allocation made "who spun up this instance" answerable. AI spend attribution is that move for the token economy — one layer up the stack, for the spend that AI coding agents created almost overnight.

Why per-API-key attribution isn't per-developer

The natural first attempt is to lean on the provider's own dashboard. Anthropic's Usage and Cost API, for example, groups spend by API key and workspace. That looks like attribution, and it's genuinely useful — but a key is a credential, not a person. It maps to a human only under conditions most teams don't hold:

• Every developer must have a distinct key. Share one key across a team — or route through a common CLI proxy or gateway, which is the operationally simpler setup — and per-key spend collapses into a single undifferentiated bucket.
• No shared infrastructure. A gateway that fans many developers through one credential erases the per-person signal by design.
• No unkeyed usage. Usage from a provider's web console or workbench often carries no API key at all, so it never attributes to anyone.

Provider-side, the workaround for the human question is usually a separate, product-specific endpoint — Anthropic ships a Claude Code Analytics API with per-user estimated costs, for instance. It's real, but it's scoped to one agent and one provider, and it's an estimate layered on top of the same key-based plumbing.

Why multi-provider makes it harder

Attribution gets worse, not better, as a team matures. Most engineering teams run more than one agent: Claude Code, Codex, Cursor, Copilot. Each bills through a different provider, each defines "usage" differently, and none agrees on what a developer or a workflow is. Stitching three or four provider dashboards into one per-developer view by hand is brittle and never quite reconciles. Attribution that only works inside a single provider's dashboard isn't attribution for a real team — it's attribution for a slice of one.

Session-level attribution

The way to attribute that survives shared keys and spans providers is to read the coding session rather than the billing meter. In a session, the developer identity and the workflow are already present — who ran it, against which repo, doing what — independent of which API key carried the request or which provider billed it. That's the model Promptster uses: it attributes token spend per developer, repo, and workflow from the session itself, across all four agents, so a shared gateway doesn't collapse the picture and a second provider doesn't fragment it.

One honest boundary: session-derived spend is an insight number, not a finance-close number. It won't reconcile to the provider invoice to the cent — that's what the provider's own Cost API is for. Attribution answers "who and which workflow"; the invoice answers "what do we owe." A mature setup runs both.

AI spend attribution and Promptster Teams

Promptster Teams treats attribution as stage one of the TokenOps loop. It reads Claude Code, Codex, Cursor, and Copilot sessions, attributes each dollar to the developer and workflow that produced it, and then does the thing attribution exists to enable: separating recoverable waste from real leverage so you know which spend to cut. Attribution without that next step is just a nicer invoice; the point is what it unlocks.

See how Promptster Teams attributes AI spend →

Related reading

• What is TokenOps? — the discipline attribution is the first stage of.
• Recoverable token waste — what attribution lets you find and cut.
• Promptster vs the Anthropic Console — why the provider dashboard's per-key grouping isn't per-developer.