GitHub Copilot budget controls: what per-user caps can and cannot do
What the AI credits paid usage policy, organization and per-user budgets, and the usage dashboard each do for a Copilot bill, where each one stops, and why no cap setting is the right one.
Since June 2026, GitHub Copilot bills organizations and enterprises on a pooled monthly allowance of AI credits, and on September 1, 2026 that pool fell to 1,900 credits per Business seat and 3,900 per Enterprise seat1 . If you own the bill, you have one policy, three kinds of budget, and a dashboard to manage it with. We covered what changed in a separate explainer . This page is about the controls themselves: what each one does, the point at which each one stops helping, and the question none of them answers.
The controls, one at a time
The AI credits paid usage policy
What it does. This is the overage switch. When it is on, consumption past the included pool continues at each model’s published per-credit rate and bills to the organization or enterprise. When it is off, consumption stops at the pool. It is on by default1 .
Where it stops. It is one switch for the whole billing entity. Off means that when the pool is gone, every developer stops, including the ones who barely touched it. On means there is no ceiling at all unless a budget supplies one. There is no automatic fallback to a cheaper model at the limit1 , so the switch decides between an open invoice and a hard stop, and nothing in between.
Enterprise, organization and cost center budgets
What it does. A budget caps metered charges for a scope, the whole enterprise, one organization, or one cost center, once the included pool is exhausted. Alerts fire by email and banner at 75%, 90% and 100% of the budget. A budget can be set to stop usage at its limit, but that option has to be chosen. Left unchosen, the budget notifies and usage continues2 .
Where it stops. A scoped budget governs what happens after the pool is gone. It has no view of who emptied the pool or how fast. It limits spend for the group, so when a budget that stops usage is reached, the whole scope stops together2 . The default behavior, alert without stopping, means the first three alerts are information and the fourth is the invoice.
Per-user budgets
What it does. A user-level budget caps one person’s metered consumption per cycle. It always enforces a hard stop. A user-level budget of $0 blocks the user immediately, and a user can be blocked by their own budget while the enterprise budget still has capacity2 . When it is reached, that user’s access to Copilot is halted1 .
Where it stops. This is the control most administrators reach for, and it is a ceiling on one person. A ceiling changes when a developer stops. It does not change how much of the pool that developer had a claim on, and it does not give a blocked developer any route to the allowance sitting unused on the desk next to them. Per-user caps set low enough to protect the pool block productive engineers in the last week of the month4 . Set high enough not to, they protect nothing.
The usage dashboard and the metrics API
What it does. The dashboard in Copilot settings shows 28-day usage trends across the enterprise and its organizations. The usage metrics API adds exportable data at the enterprise, organization, repository and user level, with breakdowns by feature, IDE, language, model and user. Both are updated within two full days of the activity3 .
Where it stops. The dashboard shows aggregates, so the per-user view that matters for a shared pool comes from the API, two days late. Both depend on telemetry being enabled in each developer’s IDE, and activity from Copilot Chat on GitHub.com and GitHub Mobile is excluded3 . More to the point, a dashboard shows. It does not act. Look at the distribution rather than the average, because the top decile is what sets the date the pool runs out. If you would rather work from the billing usage CSV, the Copilot billing report we publish reads it in your browser and draws that distribution. Nothing is uploaded, and it needs no token or account.
The administrator’s dilemma
Every one of those controls is a ceiling. The dilemma is that no height is correct.
| You set | What happens |
|---|---|
| Per-user caps low | Productive engineers hit the wall in the last week of the month and stop4 . |
| Caps high, or the paid usage policy left on | Overage is enabled by default1 . On an Enterprise seat, 3,100 credits a month that were included through August now bill instead1 6 . That is a modeled $6,200 a month at 200 seats and $155,000 at 5,000. |
| Nothing | Unused credits are forfeited at the end of every month and the pool resets on the first1 , while roughly 20% of users, the ones on agent workflows, draw 70–80% of the pool5 . |
The exposure figures are derived, not quoted. An Enterprise pool fell from 7,000 credits per seat during the promotion6 to 3,9001 , a difference of 3,100 credits at $0.01 each, or $31 per seat per month. Multiply by seats. The figure assumes an organization that drew its full promotional pool and keeps consuming at that level. An organization that drew less is exposed proportionally less, and one whose consumption grows is exposed more.
Why no ceiling is the right height
Each control acts on one axis: how much one entity, whether the enterprise, an organization, a cost center or a person, is allowed to spend. The problem the pool creates lives on a different axis: who has headroom on the fifteenth of the month.
Forfeiture and blocking are not opposite failures that a well-chosen cap sits between. They happen in the same pool, in the same month, to different people. A fifth of the developers reach their limit while the allowance of the other four fifths expires unused. Lowering the cap moves the blocked date earlier. Raising it moves the cost onto the invoice. Turning the policy off makes the blocked date everyone’s. None of those settings moves a single credit from a developer who will not use it to one who will, because a limit cannot do that. It is a distribution problem being addressed with a ceiling.
Nor is this particular to GitHub. Each vendor’s coding tool ships a ceiling of its own, and none of them ships the route.
The route the controls do not have
What the pool needs is the thing missing from the figure above: a way for allowance that would otherwise be forfeited to reach the developers who ran out, before the month ends. Then the cap can stay where it protects the budget, because a developer who reaches it has somewhere to go.
We are building Spillway Ops for that route. It reads usage metadata and sets per-user limits through the vendor’s own admin API, with no repository access, no prompt contents and no code. Unused allocation flows to the developers who need it, so spend falls without anyone losing a tool. If you are choosing a cap height this month, we would like to hear which one and why.
Drop your email for early access notice and product updates in between.
Sources
- GitHub Docs Usage-based billing for organizations and enterprises
- GitHub Docs Using budgets to control spending
- GitHub Docs Copilot metrics and the usage dashboard
- Scott Armbruster GitHub Copilot’s New Bill Will Shock Your Dev Team
- Allan de Castro AI Credits Pool: a survival guide
- GitHub Blog GitHub Copilot is moving to usage-based billing
Last updated September 13, 2026.