Copilot spend analytics
Four questions. Everything else is a chart.
Short answer
Useful GitHub Copilot spend analytics answers four questions: what did we spend, who spent it, is that trending in a direction we chose, and does it reconcile to the invoice. Most Copilot dashboards answer the first and third, guess at the second, and skip the fourth entirely — which is the one finance cares about.
The four questions
What did we spend? Seats plus metered consumption, for a period that matches your budget cycle rather than a rolling window imposed by an API.
Who spent it? By team first, by user only as a diagnostic. This is the question most tooling answers worst, because the underlying data has no team dimension and the mapping has to be built.
Is the trend one we chose? Month over month, with the driver separated from the noise — a rise because headcount grew is a different fact from a rise because one team started running agents.
Does it reconcile? Metered usage against billed dollars, with the gap shown rather than smoothed away. If a dashboard never disagrees with the invoice, it is not reading the invoice.
Metrics worth a dashboard
- Active ÷ assigned seats
- The waste ratio, trended. One line that tells you whether seat hygiene is happening or was a one-off cleanup last quarter.
- Credit burn rate vs allowance
- Plotted against elapsed days in the cycle, so overage is a forecast rather than a postmortem.
- Cost per active developer
- The comparable unit. Immune to headcount growth, which is what makes it usable in a budget conversation.
- Surface mix
- Chat versus review versus agent. This is the leading indicator of a consumption jump — surface mix shifts weeks before the invoice does.
- Model mix
- Share of metered requests by serving model. The most actionable chart on the page, because the fix is a default, not a behaviour change.
- Modeled vs billed
- Both series on one axis, gap visible. Not a vanity metric — it is the credibility of everything above it.
Metrics that mislead
Acceptance rate measures whether developers like the suggestions. Completions are unmetered, so it is unrelated to cost, and using it as a cost proxy points you at the highest-value teams as though they were the problem.
Total suggestions has the same defect at larger scale. Seats assigned on its own tells you what you committed to, not what you got. And cumulative spend to date flatters early in the month and panics late in it; burn rate against elapsed days says the same thing without the drama.
History is the hard part
The analytical problem with Copilot is not computing the metrics, it is having anything to compute them over. GitHub's usage data does not remain available indefinitely, and the rolling windows the APIs expose are shorter than the annual cycle you are being asked to explain. By the time a budget conversation happens, the evidence for what drove Q1 can already be gone.
FinOpsAid snapshots that usage nightly into a versioned warehouse where history is never overwritten, so a year-over-year comparison is a query rather than an archaeology project — and every modeled figure carries the timestamp it was computed at.
FAQ
Frequently asked questions
What Copilot metrics should we track for cost?
Active seats divided by assigned seats, credit burn rate against elapsed days in the cycle, cost per active developer, surface mix, model mix, and modeled versus billed. The first finds waste, the middle three explain movement, and the last is what makes the other five credible to finance.
Is Copilot acceptance rate a cost metric?
No. Acceptance rate measures whether developers find suggestions useful, and code completions consume no AI credits at any volume. Treating it as a cost proxy actively misleads: it flags your highest-adoption teams as expensive when their usage may be entirely unmetered. Keep it as an adoption metric, not a cost one.
How far back does GitHub Copilot usage data go?
Not as far as a budget cycle. GitHub's usage endpoints expose rolling windows and the data does not remain available indefinitely, so evidence for what drove spend earlier in the year can be gone before anyone asks. Retaining your own nightly snapshots is the only way to make year-over-year comparison possible.
Why does our Copilot dashboard disagree with the invoice?
It should, slightly. Usage signals are near-real-time; billed amounts come from the billing API and lag by a few days by design. A visible, explained gap is correct behaviour. A dashboard that always matches the invoice exactly has merged the two sources, which means you can no longer tell a measurement from a charge.
Try it
See these numbers for your own org
Connect your organization read-only and FinOpsAid meters it nightly — seats, credits, minutes, Codespaces and storage, attributed to teams and reconciled against your billing API. Every modeled figure is labelled an estimate, with the date it was computed.