You can't track token consumption across Copilot, Cursor, and Claude Code in one native view, because the three tools don't report in the same unit. Claude Code exports tokens and cost through OpenTelemetry. Cursor exposes usage events and spending through an Admin API on Enterprise plans. GitHub Copilot reports adoption and activity through its usage metrics API and shows AI-credit cost in a dashboard. The workable approach is to pull each source, convert everything to dollars per user per day, tag it by team, and join it to merged pull requests from Git.
Most leaders discover this the hard way. Finance asks for total AI coding spend by team, and three admin consoles return three different answers in three different units.
Why is token tracking hard now that AI tools bill by usage?
Not long ago you paid a flat price per seat. Today, part of the bill moves with use. Cursor's pricing page says every plan includes a set amount of model usage and that on-demand usage beyond it is billed in arrears. GitHub's plans page prices Copilot with AI credits, where one credit is $0.01, and lets paid plans set a dollar budget for usage beyond the included allowance. Claude Code is billed by API token consumption, and Anthropic says per-developer costs vary widely with model choice, codebase size, and usage patterns.
Variable cost needs a variable view. A budget set once a year can't tell you that one team's agent run cost more than its seats did.
Where does each tool keep its usage data?
Two lessons follow. First, if your leadership asks for tokens across all three, say that only some sources provide them. Second, API access differs by plan, so a team on a lower tier may need the dashboard export instead.
What about DIY and open-source trackers?
Developers built their own answers to the visibility gap. Two examples are worth knowing. ccusage, an MIT-licensed command-line tool, analyzes token usage and cost from local data for Claude Code and a long list of other coding agent CLIs (ccusage on GitHub). Tokscale, also MIT-licensed, covers more than 60 clients and estimates cost from LiteLLM pricing data (Tokscale on GitHub).
They suit one developer checking a personal bill. They read data on that developer's machine, and the cost is an estimate. They give you no org-wide view, no identity mapping to your directory, and no link to pull requests. If you try to run them across 300 laptops, you'll spend your time on collection.
How do you track token consumption across all three tools?
Step 1: How do you normalize the data?
Create one table with the same columns for every source: date, tool, user ID from your identity provider, team, model, unit, quantity and USD. Convert each tool's native unit to dollars using the vendor's own cost field where one exists, and a price table you maintain where it doesn't. Keep the native quantity alongside the dollars so you can audit the conversion.
If you route API traffic through a gateway, a proxy such as LiteLLM tracks spend by virtual key, user and team, with budgets and rate limits per key (LiteLLM docs). Gateways only see the traffic you send through them, so seat-based tools used through their own apps stay outside it.
Step 2: How do you connect spend to engineering output?
Join the spend table to merged PRs from your Git provider by user and by week. Then compute two numbers per team: cost per merged PR, and the share of merged PRs that were AI-assisted. Telemetry counts creation, not merge. Claude Code's pull request metric counts PRs created, so merged outcomes, review time and rework have to come from Git and CI.
This is what we mean by token efficiency. It is the engineering value you get from the tokens you pay for, measured on code that merged. High efficiency means AI output merges and holds up. Low efficiency means code gets thrown away or expensive models do simple work. Our guide to AI metrics that prove ROI to your board and the post on why acceptance rate misleads explain why we avoid suggestion counts here.
Here is a hypothetical. A team spends $6,000 in a month across three tools and merges 150 AI-assisted PRs, so cost per merged PR is $40. Next month spend rises to $9,000 and merged AI-assisted PRs rise to 160. The cost per merged PR is now $56.25. Something changed and it's worth a conversation, even though the team 'used more AI'.
Step 3: How do you spot zombie agents and runaway CI?
Hivel uses the phrase zombie agent for an autonomous process that keeps consuming tokens after its task is done or its user has moved on. The causes are usually ordinary. Anthropic's cost docs name scheduled tasks that fire on their interval even while a session is idle, agent teammates that keep spending until they exit, and very long sessions that resend the full conversation with each request. Anthropic also says agent teams use roughly 7x more tokens than standard sessions when teammates run in plan mode (Anthropic docs, 2026).
Use a simple rule to catch them. For each user or service account, compare daily spend with that account's commits and PRs for the same days. Sustained spend with no matching output is the flag. Start with alerts for any account above your own 95th percentile of daily spend, and tune from 60 days of data.
Step 4: How do you check whether you're using the right model?
Anthropic's guidance is to use Sonnet for most coding tasks, reserve Opus for complex architectural decisions or multi-step reasoning, and set a default model deliberately. Check which model each team runs by default, then compare cost per merged PR by model for similar work. Models change quickly, so review the choice quarterly rather than hard-coding a rule.
How do you make renewal decisions with this data?
Run side-by-side trials with a purpose. Many teams compare Copilot and Cursor over a few weeks. Measure merged AI-assisted PRs, rework, and cost per merged PR for each tool and each cohort. As an illustration, if 95% of merged AI-assisted code in a pilot came from one tool, you'd have a strong case to consolidate seats on the next renewal. Use your own data, and look at rework before you decide. Our post AI Value Is a Measurement Problem, explains why boards need this evidence.
