GitHub Copilot credits calculator: pool, expiry, and overrun

GitHub Copilot’s included AI credits pool at the billing entity, and the pool resets every month: credits left unused are forfeited, and usage past the pool keeps billing¹. This page computes both sides for your organization from GitHub’s published figures and one assumption you supply. The result is a hypothesis, stated with its arithmetic. The measured answer comes at the end.

What the calculator works from

Three published facts carry every figure on this page:

• Copilot Business includes 1,900 AI credits per user per month and Copilot Enterprise includes 3,900, at 1 AI credit = $0.01 USD¹.
• Credits are pooled at the billing entity, and unused credits are forfeited at the end of every month when the pool resets¹.
• There is no flat overage rate. Once the pool is spent, additional usage is billed in AI credits at each model’s published per-token rates, at the same $0.01 per credit².

The fourth input is not published anywhere, because it is yours: the draw rate, the share of its monthly pool your organization actually consumes.

Size your own pool

Choose a plan, enter your seat count, and set the draw rate you believe holds. The worked examples below the controls state the same arithmetic for three organization sizes on both plans, so the figures are readable even with scripts unavailable.

How each number is made

The pool is a multiplication: seats, times the plan’s published credits per user per month¹. Its dollar value is the same number at the published credit value of $0.01 USD¹.

The expiry is a subtraction. Below a 100 percent draw rate, the credits your organization does not consume are the pool minus the draw, and they are forfeited at the monthly reset¹. Their dollar equivalent uses the same $0.01 per credit.

The overrun is the same subtraction on the other side. Above a 100 percent draw rate, the credits beyond the pool are billed at each model’s published per-token rates in AI credits, at $0.01 per credit².

Every figure prices whole credits only. Which models turn tokens into credits, and at what multipliers, is outside this page’s model: that depends on the mix of models your developers choose, and GitHub prices each model separately².

The assumption, and which way it moves

The draw rate is the one number on this page that is yours rather than GitHub’s. If your organization draws more than you assumed, the expiry shrinks toward zero and the overrun grows. If it draws less, the expiry grows and the overrun disappears. A month lands on one side of the line, and which side varies, because consumption concentrates: 10–20% of engineers typically draw 70–80% of the credits³, and shared pools have run out as early as day 11 of a month⁴.

Concentration is also why a pool can hold both outcomes at once. With per-user budgets capping individuals inside a pooled allowance, developers can be halted at their caps while credits they cannot reach expire around them. The budget-controls page walks that mechanism control by control.

From assumption to measurement

Every figure above is a hypothesis about one number. The decisions that follow from it, caps, budgets, or doing nothing, depend on who is drawing the credits and how fast, and a single assumed rate cannot say. A cap cannot fix a distribution problem, and until you can see the distribution you cannot tell expiry from exhaustion. We are building Spillway Ops to route what would be forfeited to the developers who run out. Replace the assumed draw rate with your organization’s measured figures before you act on anything this page computed.