As of December 2, 2025, GitHub Copilot premium requests now run under a new default: overages are allowed unless you explicitly disable them or cap them with a budget. For organizations created before August 22, 2025, the old account‑level $0 budget that silently blocked paid usage has been removed. If you administer Copilot for a team or an enterprise, this change can either quietly rack up surprise charges or, if misconfigured, stop AI features cold for your developers. Let’s unpack what changed, what it costs, and how to set guardrails that won’t slow delivery.
What exactly changed on December 2?
Three things matter for most teams:
First, the legacy $0 budgets on older Enterprise and Team accounts were removed. Those acted like a circuit breaker at the account level. They’re gone, and the default policy is now to allow paid usage after a user burns through the included allowance.
Second, the overage policy is on by default for organizations and enterprises. You must explicitly switch it off if you intend to hard‑stop paid usage past the included pool.
Third, premium requests are metered at $0.04 USD per request on Business and Enterprise plans when you enable paid usage or set a positive budget. Your normal seat pricing still applies; overages are layered on top.
GitHub Copilot premium requests: the numbers leaders need
Seat pricing hasn’t changed: Copilot Business is $19 per user/month; Copilot Enterprise is $39 per user/month. What’s new is how the “premium request” pool interacts with your spend controls:
• Monthly included premium requests: Business: 300 per user. Enterprise: 1,000 per user.
• The counter resets at 00:00 UTC on the first day of each month.
• Additional premium requests (beyond the allowance) are billed at $0.04 each when paid usage is permitted.
• Some models cost more in “request units” via multipliers. For instance, an advanced model might count as 10 requests per prompt, while included models on paid plans can count as 0.
Translation: your real exposure depends on two dials—how many prompts your devs send and which models or features they pick. An engineering org that stays on included models most of the time can keep overages near zero, while teams leaning on heavy reasoning models can multiply consumption quickly.
Where teams get tripped up
Here’s the thing: many orgs assumed the $0 budget “wall” would stay in place. Now that the wall is gone, default‑allow means leaders discover the change on the next statement. On the flip side, teams that rush to set policy to block paid usage inadvertently cut developers off from premium models mid‑sprint. You need a middle path: let the work continue, but bound the burn.
The 10‑minute Dec 2 hardening checklist
Use this to land in a safe, predictable posture today. You can refine later.
1) Choose a stance: allow, cap, or block
In your enterprise or org Copilot settings, find the Premium request paid usage policy. Pick one:
• Enabled: allow overages. Best for uninterrupted work with budget caps.
• Disabled: block overages. Best for strict budgets or pilots.
If you’re unsure, enable paid usage but add a conservative budget in step 2. That preserves velocity while containing risk.
2) Set a budget that matches your appetite
Create a monthly budget on the Premium Requests SKU. Start with a cap equal to 3–5% of your monthly Copilot seat spend. Example: 200 seats on Enterprise ($39) → $7,800/month seat cost. A 5% cap is $390, which buys 9,750 premium request units at $0.04. Adjust after you see week‑one consumption.
3) Point devs at included models when possible
Paid plans include several models that consume zero premium requests. Set those as the default in your editor policies and onboarding docs. Developers can escalate to heavier models when the problem demands it.
4) Turn on auto model selection in VS Code
Auto selection gently steers prompts to efficient models and, on paid plans, applies a small multiplier discount for certain requests. It’s the rare toggle that improves both latency and cost without training every user.
5) Download a usage report and tag your spend
Pull the Copilot premium request usage CSV (last 45 days) and segment by org, team, and feature (Chat, agents, code review). Create a simple dashboard: top 10 users by overage, top 5 models by multiplier, and requests by day. Share it weekly with eng managers.
6) Communicate the new norms
Post a short note in your #eng‑announcements channel: which models are approved by default, what to do if you see a “limit reached” message, and where to request exceptions. The fastest way to cut waste is clarity.
7) Add two escape hatches
• A small “emergency overage” budget for each critical team that resets weekly.
• A documented path to temporarily raise the cap during incidents or time‑boxed delivery.
Policy playbook: three templates you can copy
Strict Cap: Policy disabled. No paid overages. Rely on included models only. Good for compliance‑sensitive shops or early rollouts. Risk: developer frustration on tough tasks.
Soft Cap: Policy enabled. Budget at 3–5% of seat cost with a daily alert. Default to included models; heavier models by exception. This is the sweet spot for most teams because it preserves momentum and gives finance a ceiling.
Always‑On: Policy enabled. Generous budget (10–15% of seat cost) plus aggressive observability and monthly reviews. Good for AI‑heavy orgs tackling research or migrations. Risk: silent creep if you don’t audit model choices.
People also ask: what counts as a premium request?
Any Copilot action that uses a premium model or certain advanced features draws from the premium request pool. That generally includes Chat, Agent Mode, the coding agent on GitHub.com, code review with advanced reasoning, and the Copilot CLI when it routes to premium models.
How much does a premium request cost in practice?
The meter is $0.04 per request unit. The catch is multipliers: a standard premium model may be 1×, while a top‑tier reasoning model can be 10×. So one chat exchange on that model could count as 10 units ($0.40). This is why model defaults and education matter more than any other knob.
GitHub Copilot premium requests: a quick cost example
Imagine 120 developers on Copilot Enterprise (1,000 included units each). If 25% of them use a heavier model 15 times per day at 1×, that’s 0.25 × 120 × 15 × 20 workdays = 9,000 units/month—fully covered by the included pool. But if 10% of users try a 10× model 5 times a day for a week, that’s 0.10 × 120 × 5 × 5 × 10 = 3,000 units; if you’re already near the line, those 3,000 units cost $120. Repeat that pattern across teams and months and you’ll want budgets and dashboards.
Model guardrails that actually work
• Default to included models globally; allow premium models by short‑term exception.
• Enable auto model selection in VS Code. It balances latency and quality and can shave request costs on paid plans.
• Publish a “when to upgrade” guide: e.g., “Trace this null deref? Included model. Draft a refactoring plan across services? Use Sonnet. Spending >500 requests/week? Ask for a review.”
• Set per‑org model access: product teams may need advanced models; infra tooling teams often don’t.
Operational gotchas and edge cases
Multi‑license users: A developer who belongs to multiple orgs or an enterprise plus a standalone org must pick a billing entity for premium requests. Make sure your admins guide users so overages accrue where you expect.
Per‑tool SKUs: GitHub is splitting usage into dedicated SKUs for certain AI tools (for example, the coding agent and Spark). Budgets and reports will show more granularity over time. The upside is clearer accountability; the downside is more knobs to set.
Free vs. paid behavior: On paid plans, some core models consume 0 units; on Copilot Free, nearly everything counts as 1. If you run mixed fleets, expect different user experiences at the edge of limits.
Rate limits still exist: Included models at 0 units can be rate‑limited during peaks. Teach teams to backoff or retry instead of spam‑clicking “Run again,” which only adds frustration.
Framework: the Copilot Cost Triangle
To keep costs predictable without neutering capability, drive decisions on three sides:
• Policy: On/off with a budget. Pick Strict, Soft Cap, or Always‑On.
• Models: Default to included; restrict heavy multipliers to approved teams and time windows.
• Visibility: Weekly reports, per‑team dashboards, and a Slack alert when any org hits 70% of its budget.
Each sprint, adjust only one side. If you raise the budget, keep models and visibility steady so you can attribute effects cleanly.
Step‑by‑step: how I configure a sane setup for a 200‑seat org
1) In enterprise settings, set Premium request paid usage to Enabled.
2) Add a $500 monthly budget on the Premium Requests SKU and a $200 emergency sub‑budget for the platform team.
3) Restrict high‑multiplier models to the platform and architecture orgs for 30 days.
4) In VS Code settings sync for the org, enable auto model selection and set the included model as default.
5) Push a one‑page “When to use what” guide and pin it in team channels.
6) Schedule a weekly usage report to finance + engineering managers; chart top users, top models, and exceptions granted.
7) After two weeks, review: did we blow the cap? If yes, was it justified? Tune budgets and model access by team, not globally.
How this interacts with your broader platform plans
Budgets and policies are nice, but strategy matters. If you’re actively rolling out agents and reasoning‑heavy workflows, plan for overages rather than pretending they won’t happen. That might mean shifting some dollars from cloud line items to AI tooling. If you’re chasing straight‑line ROI, default to included models and evaluate premium usage only where you can point to time saved on high‑leverage work.
Related playbooks and deeper dives
If you’re the person who gets paged for unexpected platform spend, bookmark these:
• Avoid Dec 2 bill shock with Copilot premium requests — practical flags to flip before your statement closes.
• The Dec 2 shift — why GitHub changed budgets and how orgs should adapt.
• Your Dec 2 playbook — hands‑on configuration paths for admins.
• npm token changes on December 9 — security cutover guidance you’ll likely handle the same week.
FAQ for busy admins
Will my developers be blocked when we hit the limit?
If your policy is Disabled or your budget cap is reached, premium models and features are blocked for the rest of the period (or until you raise the cap). Developers can still use included models on paid plans.
Do individual plans change?
No change today for Pro and Pro+. Individuals can still set their own budget for overages at $0.04 per unit, but mobile‑purchased subscriptions can’t buy overages. This article focuses on organizations and enterprises.
When do counters reset?
At 00:00 UTC on the first day of each month. That’s helpful for forecasting: you can snapshot near month‑end and predict next month’s burn.
Which features eat the most?
Agent‑style tasks and long chats on high‑multiplier models are the usual culprits. Put those behind an exception path. For everyday refactors, tests, and docstrings, the included models are fine.
A simple forecasting template you can take to finance
Start with seats × included allowance. Estimate the share of users on premium models (p), their average prompts per workday (d), days per month (m), and the average multiplier (k). Overage Units ≈ seats × max(0, p × d × m × k − included). Multiply units by $0.04. Vary p and k to create low/likely/high scenarios and set your budget to the “likely” case plus 20% headroom.
What to do next
• Today: Set policy (Enabled with a budget, or Disabled), flip on auto model selection, and publish your model defaults.
• This week: Ship the usage dashboard, review top models and users, and tune access by team.
• This month: Run the finance model, right‑size the budget, and paper an exception process to avoid ping‑pong approvals.
Zooming out
AI assistants are moving from novelty to muscle memory. The Dec 2 shift doesn’t change whether Copilot is valuable—it changes how you control it. Set a clear policy, guide model choices, and give managers line of sight. You’ll keep developers moving and bills boring—the right combination going into year‑end planning.
