GitHub Copilot premium requests and AI credits, explained

What premium requests are, how AI credits replaced them, what changed on 1 September 2026, and what an engineering org should check before the October invoice.

GitHub Copilot credit capacity pool shrank on 1 September 2026 — by 37% on Business and 44% on Enterprise — while your seat price stayed the same. The first invoice on the new pool lands in early October.

fig. 2a — included credits/user/mo, promo → standard ■ standard pool
PlanSeat pricePromotional poolStandard poolCapacity
Copilot Business$19/user/mo3,000 credits/user/mo1,900−36.7%
Copilot Enterprise$39/user/mo7,000 credits/user/mo3,900−44.3%

Seat prices did not change. Overage beyond the included pool is metered at roughly $0.01 per credit.

Premium requests and AI credits

One billing story, before and after 1 June 2026:

  • A premium request was the unit until then: one call to a premium model or agent — chat with a premium model, an agent task, a multi-step edit — weighted by a per-model multiplier. GitHub’s own announcement retired the term: “premium request units (PRUs) will be replaced by GitHub AI Credits.”
  • An AI credit is the unit since: consumption metered on actual tokens — input, output and cached — at each model’s published API rates. A credit corresponds to a cent of that usage, which is how GitHub’s dollar allotments ($19 and $39 per user per month for Business and Enterprise, raised to $30 and $70 during the promotion) become the 1,900 / 3,900 and 3,000 / 7,000 credit pools in the table above.

Under either unit, ordinary code completions and Next Edit suggestions stay included on every plan and consume nothing. What changed with consequences is where the meter sits: credits are pooled at the billing entity, not metered per seat.

How the credit system is evolving

fig. 2b — per-seat era: one meter per seat ■ a heavy month, contained

Under per-seat metering, one developer’s heavy month was one developer’s problem.

fig. 2c — June 2026: one pooled meter, every seat draws

June 2026 — GitHub replaced premium requests with AI credits and moved organizations and enterprises to usage-based billing (announced 27 April 2026): one pooled monthly credit allowance, metered overage, and a three-month promotional period with much larger pools. Monthly plans migrated automatically; annual plans keep premium-request pricing until renewal. A heavy month became everyone’s problem, and the pool became the thing finance has to forecast.

September 2026 — the promotional period ended and pools fell to the standard amounts in the table above. Three important details:

  1. Additional usage is enabled by default. Preventing spend beyond the pool requires an administrator to disable the AI credits paid usage policy in AI Controls. Doing nothing is a decision to allow overage.
  2. There is no automatic fallback to cheaper models. At the limit, work stops; it does not degrade gracefully.
  3. Unused credits are forfeited. No carry-over — the pool resets at 00:00:00 UTC on the first of each month.

Why October’s invoice will look different

A forecast built on June–August usage was built against the promotional pool. The same consumption now draws against a pool 37–44% smaller, and everything above the line is billed. Model choice multiplies the effect: credit cost spans roughly 6× between the cheapest and most expensive models, so a quietly-set default model is a budget decision.

$6,200/mo

modelled overage at 200 Enterprise seats, consumption unchanged

$155,000/mo

modelled overage at 5,000 Enterprise seats, consumption unchanged

6×

credit-cost spread across model choices

Modelled numbers, not invoices.

What actually drains a pool

fig. 2d — one billing cycle, one pool ■ blocked ■ forfeited

Consumption follows a power law: roughly 20% of users — the ones who adopted agent workflows — draw 70–80% of the credits, and in a shared pool they set the date everyone else runs out. Because nothing carries over, consumption front-loads and the last week of the month is where caps bite.

“Exhausted by day 11 despite lighter usage than previous month.” — GitHub Community, after the transition

Five things to check this week

  1. Confirm whether overage is enabled. It is on by default. Turn this off to avoid a surprise budget overage.
  2. Re-forecast against the standard pool, not the promotional one. Take August’s actual consumption and divide by the new pool size.
  3. Check your default model. Popular, more powerful frontier models can be up to a 6× multiplier to every request. Choose a less powerful default model to help keep budgets in check.
  4. Look at the distribution, not the average. The usage dashboard in Copilot settings and the usage metrics API will show what the top decile consumes. The mean will tell you almost nothing.
  5. Decide what happens when someone hits the wall on the 24th. There is no graceful degradation. Either you have a process, or your engineers have a workaround.

The part nobody has solved

Every native control, the AI credits paid usage policy, additional usage budgets, per-user budgets is a ceiling. Ceilings stop spending and none of them moves unused allocation to the developers who ran out. Both results are true in the same pool, in the same month: forfeiture on one side, blocked engineers on the other.

fig. 2e — the missing route (cf. fig. 1, front page)

We are building Spillway Ops for that missing route: allocation that would otherwise be forfeited flows to the developers who ran out, so spend falls without anyone losing a tool. It reads usage metadata and sets per-user limits through vendor admin APIs — no repository access, no prompt contents, no code. If the October invoice is about to be a conversation at your company, we would genuinely like to hear how it goes.

Drop your email for early access notice and product updates in between.

Sources

Last updated 3 September 2026.