← FinOpsAid blog

What does GitHub now attribute for you? Cost centers and AI credit pools
GitHub shipped cost centers with pooled AI credits and per-user budgets in July 2026. What that natively attributes, what it still doesn't, and how it changes your allocation model.
For years the honest answer to "which team does this GitHub spend belong to?" was that you had to work it out yourself. GitHub billed the organization, and everything below that was a mapping you built and maintained. That's changed — partially, and in one specific area — and it's worth knowing exactly where the line now sits before you rebuild anything.
In July 2026 GitHub shipped cost centers that support pooled AI credits, along with budgets that can be set at enterprise, cost-center and per-user level. For the fastest-moving part of the bill, there's now a native grouping where there wasn't one.
What a cost center gives you
A cost center is a grouping GitHub itself understands. Assign users to it, pool AI credits against it, set a budget on it, and consumption rolls up natively — no allocation rule, no mapping table you have to keep current, no argument about whether the split is fair.
That matters most because of what it groups. Since Copilot moved to usage-based billing, AI credit consumption is the variable half of the bill — the part that moves without anyone assigning a seat. Having it land in a bucket with an owner and a cap, enforced at the source, is a genuine improvement over reconstructing it after the fact.
There's a control dimension too. A budget you compute is a warning; a budget GitHub enforces is a limit. Per-user budgets within a cost center mean you can cap an individual's overage without capping the team, which is a finer instrument than most cost tooling offers.
What it doesn't cover
The scope is narrower than the name suggests. Cost centers pool AI credits. They do not tell you what a team's Actions minutes, Codespaces core-hours, storage, packages or self-hosted runner capacity came to.
Which means the attribution problem hasn't gone away — it's been partitioned. One part of the bill now has a native answer. The rest still needs the model you were already maintaining, with the same rules and the same honesty about which figures are billed and which are allocated.
A second boundary is worth naming. Repository-level Copilot usage metrics also went generally available in July 2026, and they're genuinely useful — coding-agent and code-review activity per repository, via the REST API. But they are activity, not dollars. There is still no per-repository Copilot cost, and anyone offering you one built it from an allocation rule.
The line between native and modeled is not fixed. It moved in your favour this quarter, and it will move again — which is the practical argument for keeping allocation rules documented rather than embedded in a spreadsheet formula.
How this changes your allocation model
Use the native grouping where it exists. Anything GitHub attributes for you is a figure nobody can dispute, and it should displace the equivalent allocated figure in your model rather than sit alongside it.
Keep the rules for everything else, and keep them written down. Attribution is still a chain of mappings you own for most of the bill. What changed is that one link in the chain got shorter.
Don't let cost centers imply more precision than they carry. A cost center gives you an exact figure for pooled AI credits. It doesn't make your storage allocation any more accurate, and presenting a team total that mixes the two without labels is how a defensible number becomes an argument.
Align cost centers to something that already exists. The temptation is to invent a new hierarchy. Map them to the teams or departments your budgets already use, or you'll spend the next year reconciling two org charts.
Re-check the boundary each quarter. This shifted materially in a single month. A model built on last quarter's assumption of what GitHub does and doesn't attribute will quietly drift out of date.
The direction of travel is good: the platform is slowly absorbing work that cost teams used to do by hand. The discipline that doesn't change is labelling — knowing which of your numbers came from GitHub and which came from a rule you chose is what makes the whole thing survive scrutiny.
FinOpsAid tracks both sides of that line explicitly. Cost Explorer and Teams show attributed spend with each figure marked billed or modeled, so when GitHub starts attributing something natively it moves from one column to the other — visibly, rather than silently improving a number nobody was told was an estimate.
Frequently asked questions
What do GitHub cost centers actually attribute?
Pooled AI credits. Assign users to a cost center and their credit consumption rolls up natively, with budgets settable at enterprise, cost-center and per-user level. That is a genuine improvement because AI credits are the variable half of the bill since Copilot moved to usage-based billing.
Do GitHub cost centers solve team cost attribution?
Only partly. They pool AI credits; they do not tell you what a team's Actions minutes, Codespaces core-hours, storage, packages or self-hosted runner capacity came to. The attribution problem has been partitioned rather than removed — one part now has a native answer and the rest still needs your own model.
Is there per-repository Copilot cost now?
No. Repository-level Copilot usage metrics went generally available in July 2026 and cover coding-agent and code-review activity per repository, but that is activity, not dollars. There is still no per-repository Copilot cost, and anyone offering one has built it from an allocation rule.
Want to see which half of your team costs are native and which are modeled? Connect your GitHub org — read-only and free during beta — or explore the demo dashboard first.