Skip to content

How to Attribute AI Coding Spend per Developer Across Claude Code, Codex and Cursor (2026)

Each coding-agent vendor reports spend its own way: Anthropic by API key or Claude Code user, OpenAI by project, user or ChatGPT workspace, Cursor by team member. This post covers what each one exposes, the five gaps they share, and a six-step method for per-developer, per-repo AI spend attribution.

Paarth Jamdagneya
ai spend attributionai cost per developerclaude code cost per developercodex usage analyticscursor admin apiai coding costengineering ai budgettokenops

TL;DR

To attribute AI coding spend per developer you need three things the vendor dashboards don't give you on their own: an identity map from credentials to people, one unit across tools (API-equivalent dollars), and a repo and workflow dimension. Anthropic, OpenAI and Cursor each expose real per-user data now, but each covers only its own tool, prices it differently, and stops at "who". This post walks through what each vendor exposes as of October 2026, the five gaps they share, and a six-step method that holds up.

Attribution is the first stage of TokenOps (attribute, surface waste, optimize, operate). For the short definition, see AI spend attribution.

Why "per developer" is the question that matters

Finance gets one total per vendor. Engineering leadership needs the split: which team, which repo, which workflow, which person to coach. Without that split you can't tell a re-read loop on one monorepo from a productive week, and every cost conversation turns into a blunt budget cut.

The vendors have noticed. In the past year all three major coding-agent vendors have shipped per-user reporting. It helps, but it doesn't add up to attribution.

What each vendor exposes today

Anthropic (Claude Code)

  • Usage and Cost Admin API. Token usage you can filter and group by API key, workspace, model, service tier and a few other dimensions. The cost endpoint groups by workspace or description. Usage from the Console playground carries a null API key, and the default workspace shows as a null workspace. It reconciles to the invoice; it does not know who a person is.
  • Claude Code Analytics API. One record per actor per day: sessions, lines added and removed, commits, PRs, tool accept/reject counts, and tokens plus estimated cost per model. The actor is either a user email (OAuth sign-in) or an API key name. A customer_type field separates pay-as-you-go API usage from subscription usage. Two limits matter: it only covers Claude Code on the Claude API (not Bedrock, Vertex or Foundry), and Claude Enterprise organizations get Claude Code activity through a separate Enterprise Analytics API with its own key type.

OpenAI (Codex)

  • Usage and Costs API. For Platform API usage you can filter and group by project, user, API key and model. That covers Codex CLI runs authenticated with a Platform API key.
  • Codex analytics for ChatGPT workspaces. Engineers who sign into Codex with ChatGPT are billed through the workspace, not the Platform. Admins get a Codex analytics dashboard and an Analytics API with a per-user ranking by credits, threads and turns. The Global Admin Console breaks credit spend down by user, product and model. OpenAI itself warns not to build a durable reporting contract on dashboard labels, which can change.

So one engineer's Codex usage can land in two different billing systems, depending on how they signed in that day.

Cursor

  • Admin API for team accounts (some endpoints are Enterprise-only; individual plans have no Admin API). daily-usage-data gives per-member activity counts, not cost. filtered-usage-events gives per-member events with model, token counts, chargedCents and a billing kind such as included or usage-based. spend reports per-member on-demand spend for the cycle, which excludes included usage.

The five gaps they share

1. Seats hide consumption. On seat plans the invoice shows the flat fee plus overage. A developer who used a lot of tokens inside their plan looks free on the bill. To compare people and tools you have to price the tokens at API rates. That gives API-equivalent spend: real consumption, even when the plan already covers it.

2. Credentials aren't people. A shared key, a team gateway or a service account folds several humans into one row. The reverse happens too: one engineer with a personal and a work Cursor login, or Codex signed in two ways, shows up as two people. An email address is an identity hint, not an identity.

3. Agents run under somebody else's name. A subagent spawned by an interactive session bills to the developer who launched it. A nightly agent or CI job bills to whatever key it runs under. Neither shows up as a separate line, so the vendor view can't tell "this engineer worked a lot" from "this engineer's scheduled agent ran all weekend."

4. No repo, no workflow. None of these APIs know which repository or task the tokens served. Claude Code's analytics record carries a terminal type, not a repo. Waste is concentrated in specific workflows and repos, and the vendor view can't see that axis.

5. Three units that don't add up. Anthropic gives an estimated cost, Cursor gives charged cents, and ChatGPT workspaces count credits. Adding them gives a number that looks precise and isn't.

A six-step method that holds up

1. Build the identity map first. List every credential that can generate spend: Anthropic user emails and API key names, OpenAI user and project IDs, ChatGPT workspace users, Cursor member emails, plus every service account and CI key. Map each one to a person, or explicitly to a machine owner. Expect several credentials per person.

2. Pick API-equivalent dollars as the unit. Recompute every source as tokens × public per-token price, with cache reads and writes priced separately. Keep the vendor's own figure alongside it for reconciliation, but compare people and teams in one unit.

3. Split lanes before you rank anything. Report at least three lanes: human interactive sessions, agents launched from those sessions, and headless or scheduled runs (CI, cron, cloud agents). Book headless runs to the repo and team that own the workflow, not to whoever owns the key.

4. Add the repo and workflow dimension. This is the dimension the vendor data can't supply. The cheap version is a convention: one key or project per repo, set in the agent's config. The durable version reads it from the session itself, which knows the working directory and the task.

5. Check coverage against the invoice every month, without expecting it to tie out. The invoice is what you paid: seat fees, discounts, minimums. Attributed spend is the API-equivalent value of the tokens used. They measure different things and won't match. Use the invoice as a coverage check instead: a vendor or login that bills you but shows no captured usage is a blind spot. Track the unattributed share of captured usage as the attribution program's own KPI.

6. Report coverage alongside the totals. Say how many sessions you captured, how many you priced and how many had no usage data. A zero on someone's row can mean "unused", "not captured yet" or "a login you aren't reading". Treat it as an open question until coverage says otherwise.

Pitfalls we see most often

  • Treating the vendor's per-user view as complete. It covers one tool. Most teams run two or three.
  • Double-counting dual rails. The same session can appear in a local transcript and a vendor usage feed. Dedupe on the session, not on the event.
  • Reading a missing row as zero. A new tool, an unread second login or a retention window all look like "no spend".
  • Ranking individuals by spend. High spend on the right workflow is leverage. A public leaderboard punishes it and teaches people to route around the measurement.
  • Comparing an estimate with a charge. Note which unit every number is in before it lands in a deck.

Where Promptster Teams fits

Promptster Teams does steps 1–4 and 6 as a product. One CLI reads Claude Code, Codex and Cursor sessions on the engineer's machine, redacts locally, and attributes API-equivalent spend by repo and workflow, with human, agent and headless lanes kept apart. Each engineer sees their own figures; managers see team and squad totals. It shows how much of the total it could attribute, instead of presenting a partial number as the whole. Code and diffs are redacted on the engineer's machine before upload, and it is not developer monitoring.

Attribution is the first stage of TokenOps, not the goal. Once spend is attributed, the next step is finding the recoverable waste inside it.

See how Promptster Teams attributes AI coding spend →


Related: What is TokenOps? · AI spend attribution · Promptster vs the Anthropic Console · Promptster vs a DIY OpenTelemetry dashboard · 6 AI spend management tools · How much does Claude Code cost a team? · TokenOps metrics

Frequently asked questions

  • Can I get per-developer AI coding spend from the vendors directly?
    Partly. Anthropic's Claude Code Analytics API returns one record per user per day with estimated cost by model. OpenAI's Usage API can group by user, project, API key and model, and ChatGPT Enterprise workspaces get a Codex analytics dashboard and Analytics API with per-user credit usage. Cursor's Admin API returns per-member usage events with charged cents. Each covers only its own tool, in its own unit, and none of them carries a repo or workflow dimension. Per-developer spend across all three still takes an identity map and a common unit on top.
  • Why doesn't per-API-key reporting equal per-developer reporting?
    An API key is a credential, not a person. It maps to one human only if every developer has their own key and nobody routes through a shared gateway, CI runner or service account. Most teams share at least one of those, and per-key spend then collapses several people, or a machine, into one bucket.
  • How do I compare a seat plan with API-billed usage?
    Price everything at API-equivalent rates: the tokens each session used multiplied by the public per-token price. Seat plans bill a flat fee and then report only the overage, so the invoice understates what subscription users consumed. API-equivalent dollars put a Claude Max seat, a Cursor Business seat and a pay-as-you-go API key on one axis. It is still spend, even when the plan includes it.
  • How should headless and CI agents be attributed?
    As their own lane, not as a person. A nightly agent or a CI job usually runs under an API key or service account, and vendor reports show it as that key. Attribute it to the repo and workflow that scheduled it and to the team that owns that workflow. Mixing it into the human lane makes whoever owns the key look like the team's heaviest user.
  • Is per-developer attribution the same as monitoring developers?
    It shouldn't be. Attribution exists to answer which workflows and repos the money goes to, and to find recoverable waste. A ranked leaderboard of individual spend turns it into surveillance and teaches people to hide usage. Report spend by repo, workflow and team, keep the per-person view for the person and their manager's coaching conversation, and never capture keystrokes, screens or code.
Attribute · optimize · operate

See where your tokens go,
not just what they cost.

Your team's AI-coding spend went from zero to a real line item in eighteen months — unattributed, unbudgeted, invisible behind one vendor invoice. Promptster Teams is the TokenOps platform: it attributes spend per developer, separates recoverable waste from real leverage, and puts the whole loop on a budget.