Copilot cost management

Copilot is two bills. Most orgs only watch one.

Short answer

GitHub Copilot cost management means tracking three numbers that move independently: assigned seats, metered AI-credit consumption, and the billed invoice. Seats are a fixed monthly commitment you control by assignment. Credits are variable and driven by which Copilot surfaces and models your developers use. The invoice is the only one finance sees — and it lags both.

The seat bill and the consumption bill behave nothing alike

A Copilot seat is a subscription. You decide who has one, the price is known in advance, and the only way it grows is if someone assigns more. It is the easiest cost in your stack to forecast and the easiest to waste, because nothing about an unused seat looks different from a used one on the invoice.

AI-credit consumption is the opposite. Nobody approves it, it varies with what people are doing that week, and a single team adopting agents can move it more than a headcount change. Managing Copilot cost as one number means you will always be explaining last month's total after the fact.

The practical split: govern seats by policy, govern credits by observation. Seats respond to a monthly review. Credits respond to knowing which teams, surfaces and models are consuming them, which is information GitHub's own reporting makes you assemble yourself.

The three numbers worth putting on a wall

Everything else is diagnostic. These three tell you whether Copilot cost is under control:

Active seats ÷ assigned seats
The waste ratio. Every point below 100% is money leaving for a licence nobody opened. It is also the only Copilot lever that pays back immediately and permanently.
Credit burn against allowance
Tracked as a run rate, not a total. Half the allowance gone on the tenth of the month is an overage you can still prevent; the same number on the twenty-eighth is fine.
Cost per active developer
Seats plus consumption divided by the people actually using it. This is the number that survives contact with a CFO, because it normalises for headcount growth.

Where the money actually leaks

In practice the losses cluster in four places, and they are not the ones people expect. Idle seats — leavers, role changes, the pilot cohort nobody unwound. Model defaults — a frontier model set once by preference and never revisited, multiplying the rate on every metered request. Unbounded agent runs on large repositories, which consume in one task what chat consumes in a month. And no team attribution at all, which is less a leak than the reason the other three go unnoticed.

None of these are visible on the invoice. The invoice shows a total that went up.

An operating rhythm that survives a busy month

Cost management fails when it is a project. Make it three recurring, boring commitments instead.

Weekly: review seats with no activity in the last 30 days and reclaim them. Monthly: reconcile the usage you metered against the billed amount and explain the gap — the gap is the point, not an error. Quarterly: revisit plan tier, model defaults and which teams have agent access, using a full quarter of history rather than the last four weeks.

What GitHub gives you, and what it leaves to you

GitHub's own reporting is real but narrow. Metrics are aggregated at the organization level over a rolling window and suppressed below a minimum active-user threshold, so small teams see nothing. Seat data tells you last activity but not what that activity cost. And usage history does not stay available indefinitely — the window you can look back over is shorter than the budget cycle you are being asked to explain.

FinOpsAid keeps that history in a versioned warehouse, attributes it to teams and repositories, and reconciles it against the billing API. GitHub gives you two different kinds of number and they are not interchangeable. Usage signals — a seat's last-activity timestamp, minutes consumed, a daily per-user credit hint — arrive fast and describe behaviour. Billed amounts arrive from the billing API, lag the signals by a few days by design, and are what finance will actually be invoiced. Merge the two and you get a dashboard that is confidently wrong. Keep them apart, anchor the signal to the billed total, and show the gap.

FinOpsAid connects through a GitHub App with read-only scopes. It changes no seats, edits no permissions, pushes no code, and never stores your source. Because only Read is granted, writing back to GitHub is not a policy we promise — it is technically impossible.

FAQ

Frequently asked questions

How do I find unused GitHub Copilot seats?

Copilot's seat data exposes a last-activity timestamp per assigned user. Any seat with no activity for 30 days is a reclaim candidate; 60 days with no activity is almost always a leaver or a role change nobody unwound. Review it on a schedule rather than ad hoc, because seats accumulate quietly between reviews.

Does removing a Copilot seat refund the month?

No. Seat changes take effect on your billing cycle, and a seat you unassign typically keeps working until the end of the current cycle rather than stopping immediately. Reclaiming a seat saves next month's charge, not this month's — which is exactly why a weekly review beats an annual audit.

Why doesn't my Copilot usage match my invoice?

Because they are different measurements taken at different times. Usage signals are near-real-time behavioural data; billed amounts come from the billing API and lag by a few days by design. A gap between them is normal and expected. A tool that shows no gap has quietly merged the two, which means you cannot tell which number you are looking at.

Can GitHub attribute Copilot cost to a team or repository?

Not natively. Copilot is billed per assigned user, and GitHub does not map that spend to repositories or teams. Any per-team or per-repo Copilot figure is a model built on top of observed activity — useful for allocation, but it is an estimate and should always be labelled as one.

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.