GitHub Copilot · billing, explained with pictures

How GitHub Copilot cost centers actually work

With usage-based billing, every Copilot seat adds AI credits to one shared pool. One busy team can use up credits that other teams' seats paid for. Cost centers put a fence around each team. This guide shows what the fence does, what it does not do, and how to give a team more.

by Idan Shimon · July 2026, updated October 2026 · checked against GitHub's docs, changelog and REST API

1The problem: one pool for everyone

Copilot is metered in AI credits. One credit is one US cent. Each Copilot Business seat includes 1,900 credits a month and each Copilot Enterprise seat includes 3,900. By default, all of those credits go into one pool for the whole enterprise. The pool refills at 00:00 UTC on the 1st of each month, and unused credits do not carry over. Code completions and next edit suggestions do not use credits; chat, the CLI, cloud agent and other agent features do.

Sharing is good when a few heavy users balance out many light users. It is bad when one team uses up what other teams' seats paid for, and then those teams are blocked before the month is over.

2The fence: an AI credit pool on a cost center

A cost center is a group of users or enterprise teams, used for billing. When you turn on its AI credit pool, GitHub fences that group to the credits its own seats include. You do not type a number: GitHub adds up the seats for you.

When the team reaches its fence, you choose what happens: block the team, or let it continue as paid overage (if your enterprise allows overage).

One more consequence: the fence protects others only from the teams you fence. A team without a fence can still draw from the shared pool. If you want everyone protected, fence every heavy team, not just one.

3Four controls, two phases

Every billing month has two phases. First, users spend the included credits from the pool. When those run out, usage either stops or continues as metered overage at $0.01 per credit, if the "AI credit paid usage" policy is on. That policy is on by default; an admin has to turn it off to block all overage. Each control works in one or both phases:

Two rules that catch people:

• "Stop usage" is off by default on cost center, organization and enterprise budgets. Without it, a budget only sends alerts (at 75%, 90% and 100%).
• Per-user budgets: the most specific one wins. An individual budget beats the cost center's per-user budget, which beats the universal one. Budgets at different levels still all apply, so a strict enterprise budget can stop someone who has room in their own.
• Temporary raises can expire. An individual budget can have an end date, after which the user falls back to the cost center or universal budget.

4How to give a team more

This is the question everyone actually asks: "Can Team A get more credits without taking them from everyone else?" Yes, in one of two ways:

Option 1, more seats. Add licensed users to the cost center, or upgrade Business seats to Enterprise. The fence grows immediately, because it is calculated from seats.

Option 2, metered overage. Turn on "AI credit paid usage", set the cost center's pool to continue as overage at the fence, and put a cost center budget with "stop usage" on, so the extra spend has a ceiling. The overage is billed through your normal GitHub billing. If your enterprise is billed through Azure, you can also attach the team's own Azure subscription to that cost center, so its overage is charged to that team. That is optional.

5Setting it up

Everything below can be done in the billing UI (Enterprise → Settings → Billing and licensing → Cost centers). The REST API does the same thing and is easier once you manage more than a few teams.

1. Create the cost center with the pool turned on.

   gh api --method POST /enterprises/ENTERPRISE/settings/billing/cost-centers \
     -f name='Platform-Engineering' -F ai_credit_pool_enabled=true
   # keep the "id" from the response

2. Add the team. Use an enterprise team, not a list of names, so people joining or leaving are picked up automatically. With the pool on, only users and enterprise teams are allowed, not organizations or repositories.

   gh api --method POST \
     /enterprises/ENTERPRISE/settings/billing/cost-centers/COST_CENTER_ID/resource \
     --input - <<< '{ "enterprise_teams": ["platform-engineering"] }'

3. Check the fence. target_amount is the fence and current_amount is what the team has used, both in AI credits (78,000 credits = $780).

   gh api /enterprises/ENTERPRISE/settings/billing/cost-centers/COST_CENTER_ID \
     --jq '.ai_credit_pool_state'
   # { "target_amount": 78000, "current_amount": 12500 }

4. Optional: cap the overage with a cost center budget on AI credits, with "stop usage" on.

   gh api --method POST /enterprises/ENTERPRISE/settings/billing/budgets \
     -f budget_type='SkuPricing' -f budget_product_sku='copilot_ai_credits' \
     -f budget_scope='cost_center' -f budget_entity_name='COST_CENTER_ID' \
     -F budget_amount=5000 -F prevent_further_usage=true

You need an enterprise owner or billing manager account. Each user can be in only one cost center at a time; adding someone to a second one moves them. Limits: up to 1,000 active cost centers per enterprise, 25,000 resources per cost center, and 50 resources added or removed per call.

6"I'm locked out": four checks, in order

When a user is blocked and does not understand why, it is almost always one of these. Check them in this order:

The quick fix for a single user: a blocked user can request more budget right from the limit message. Owners and billing managers see it under "Requests from members" in billing settings and can approve, change the amount, or deny it. Approving restores access immediately. This is not available for enterprises with managed users.

7If you automate it: keep your own history

If you want to rebalance budgets automatically or predict when you need more seats, the number that matters is rate, not today's total. "Last month 20 people hit their limit in the last ten days; this month 60 hit it before the 15th" is what tells you to buy more seats before developers hit a wall.

GitHub's detailed usage reports can cover past date ranges, which is the right starting point. Live per-user views are only a picture of right now. Either way, it pays to keep your own copy:

• Take a reading on a schedule (daily, twice a day near month end) and store it by user and date.
• Store the daily change, not just the total. That is your burn rate.
• Expect missed runs. A failed day should leave a gap, not wrong numbers.
• Split it into three jobs: one collects readings, one analyzes them, one changes budgets. A broken collector then cannot push bad budgets.

8Questions readers ask

I had a second AI model play a grumpy enterprise admin and throw the hardest questions it could at this article. Here are the three that landed.

"If another team drains the shared pool first, are my team's unused credits still there?"

Not guaranteed. GitHub describes the fence as a cap on how much a team can use, not credits set aside for it. A team without a fence can still eat into the shared pool. The practical answer: fence every heavy team, not just the one that worries you today.

"Is the overage budget a hard ceiling? Can my bill go past it?"

"Stop usage" blocks new usage once the budget is reached. GitHub does not promise a to-the-cent cut-off, and requests already running can finish. Treat a $5,000 budget as "stops around $5,000", and leave yourself a little room.

"What if someone switches teams mid-month? Fresh credits, or a clean escape from their limit?"

So test it yourself. It takes ten minutes and one volunteer who doesn't mind being a lab rat:

1. Pick a test user with a small per-user budget in cost center A, and let them use some credits.
2. Move them to cost center B, which has a different per-user budget.
3. Check both: the user's remaining budget, and each cost center's current_amount. Did the usage move with them, stay behind, or vanish?
4. Tell me what you found. First reader with screenshots gets credited in the follow-up post. Bragging rights included, AI credits not.

Sources

• Budgets for usage-based billing (how the fence is calculated, budget precedence)
• Budgets and alerts
• Cost centers and the cost centers REST API
• Usage-based billing for organizations and enterprises (credits, pool reset, default policy)
• Changelog: budget expiration dates, September 1, budget increase requests, September 16
• Changelog: AI credit pools (API), July 2, per-user budgets in the UI, July 7, AI credit pools in the UI, July 20

GitHub changes billing often. Everything here was checked against GitHub's docs and changelog on October 23, 2026; confirm them in your own enterprise before relying on them.