GitHub Copilot budget controls: working with per-user caps

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 seat¹. 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: how each one works, how far its reach goes, and the question they leave open.

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 default¹.

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 limit¹, 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 continues².

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 together². 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 capacity². When it is reached, that user’s access to Copilot is halted¹.

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 month⁴. 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 activity³.

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 excluded³. 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.

The administrator’s dilemma

Every one of those controls is a ceiling. The dilemma is that no height is correct.

The exposure figures are derived, not quoted. An Enterprise pool fell from 7,000 credits per seat during the promotion⁶ to 3,900¹, 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.

What a cap actually moves

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 that moves the allowance

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.

Before you choose any setting, look at your own pool’s figures. Where the caps should sit depends on how consumption is distributed across your developers this month.