On December 2, 2025, GitHub began removing legacy $0 budgets that many enterprise and team accounts used to block paid usage of GitHub Copilot premium requests. Practically, that shifts control to your premium request paid usage policy: if it’s enabled, users can incur overage; if it’s disabled, requests beyond your allowance are blocked. Individuals on Copilot Pro and Pro+ are not affected by this removal and continue with a $0 default.
If you administer Copilot Business or Enterprise, this change isn’t theoretical—it’s live. The path to safe adoption is setting the right policy state, picking sensible caps, and communicating with your teams so productivity doesn’t dip when allowances reset on the first of the month.
What exactly changed on December 2?
For enterprise and org accounts created before August 22, 2025, account-level $0 Copilot premium request budgets are being removed in phases starting December 2. When the $0 budget disappears, paid usage is no longer blocked by that cap; it’s governed by your premium request paid usage policy (Enabled/Disabled) and any budgets you’ve set above $0. Admins typically also receive an email about the change when it hits their account.
This is part of a longer shift to predictable, policy-based billing. The monthly allowance model for premium requests across paid plans was enforced on June 18, 2025. On August 22, 2025, GitHub’s premium request overage policy for Business and Enterprise reached general availability, introducing the Enabled/Disabled control. In July 2025, the Copilot coding agent moved to a simple “one premium request per session” accounting model, while GitHub Actions minutes still vary by task length. And in November, GitHub introduced dedicated SKUs per AI tool (for example, coding agent and Spark) to make per-feature tracking easier.
Who’s affected—and who isn’t?
Affected now: enterprise and organization accounts that previously relied on a $0 budget to block overages. If that describes you, your protection is no longer the legacy cap; it’s the policy toggle and whatever spending limits you intentionally set.
Not affected by the removal: individual Copilot Pro and Pro+ users, who keep a $0 default budget. Also not changed: your included monthly premium request allowances per seat, your seat pricing, and your rate-limit reality for core chat and completions.
What are premium requests in Copilot?
Copilot runs on a mix of models and features. Most day-to-day completions and chat remain unlimited across paid plans, subject to rate limits. Premium requests kick in for higher-cost features and models. The most visible example today is the coding agent: each agent session consumes one premium request, regardless of how long the task takes. That makes usage predictable even if Actions minutes vary while the agent does the work.
Premium requests also cover certain advanced model selections and features beyond the base set. Allowances reset on the 1st of each month. If your team hits their allowance, what happens next depends entirely on your policy toggle and any budgets you configure.
Why did GitHub remove $0 budgets for orgs?
Here’s the stated rationale: per-tool SKUs mean more granular control for admins without you having to juggle multiple separate $0 budgets as new AI tools roll out. Instead of managing a forest of tiny caps, you set one clear policy, optionally add budgets above $0 for guardrails, and then watch usage per SKU in reports. It’s simpler to reason about, but it does require deliberate configuration—and that’s why Dec 2 matters.
30‑minute checklist: lock down Copilot spend without blocking productivity
Use this practical sequence. You can do it over coffee and still have time to brief your leads.
1) Pull the latest usage reports
Start with data. In your billing settings, download the premium request usage report for the last two months. Identify heavy users, teams that regularly exhaust allowances, and any spikes. You’re looking for patterns: agent sessions per week, models in use, and whether certain repos trigger outsized agent runs.
2) Choose a default policy state
Organization-wide setting first, exceptions later. If your risk posture is conservative or you have no show-stopper tasks running on agent today, set the premium request paid usage policy to Disabled so overages are blocked when allowances run out. If your developer workflow already depends on agent or premium features (for example, nightly doc generation or refactors), choose Enabled and continue to step 3 to add budget caps and alerts.
3) Set intentional budgets and caps
If you enable overages, add an explicit monthly budget above $0 with headroom that matches business value. A simple starting point: set a budget equal to 10–20% of your expected included allowance usage for the first month, then adjust. Use cost centers: create budgets per enterprise account or per organization if you manage multiple orgs under one enterprise.
4) Pilot with a boundary team
Pick one product team that uses the coding agent heavily. Turn on overages for them with a modest budget and keep others blocked. Watch throughput improvements and budget burn for two weeks. If you see agent sessions converting gnarly chores into pull requests reliably, increase their cap. If sessions stall on unclear tasks or lack repo context, tighten the prompts and refine task sizes rather than cutting budget.
5) Codify model and tool usage
Document when to use the agent versus chat versus straight completions. For example: “Use agent for repo-spanning refactors or script generation longer than 10 minutes; use chat for one-file changes; rely on completions for routine edits.” Clarity reduces wasteful premium requests.
6) Wire alerts and guardrails
Turn on email or webhook notifications at 50%, 80%, and 100% of budget burn. Post them to your #dev-experience channel. If your SOC needs visibility, mirror alerts in the SIEM. At month-end, reset expectations: allowances refresh on the 1st, so announce the window to your teams to avoid a flood of “why did the agent stop?” tickets.
7) Teach developers to self-serve
Show engineers the Copilot status icon in their IDE that surfaces usage and limits. Give them a one-pager that answers: “Can I run the agent now? How many premium requests are left for my team? What should I do if I’m blocked?” The most expensive premium request is the one that gets fired blindly, multiple times, for a task the agent can’t complete as-is.
People also ask: quick answers
Does enabling the policy mean unlimited charges?
No. It means usage beyond included allowances is permitted. To keep it predictable, set a budget above $0 as a hard cap and wire alerts. If you truly need zero risk of overage, keep the policy disabled.
Will Copilot Pro or Pro+ users start getting charged?
No. Individuals on Pro and Pro+ retain a default $0 budget and aren’t affected by the org-level removal of legacy $0 budgets. Your company’s org settings do not override personal Pro defaults.
How many premium requests do we get per seat?
Allowances are per plan and sometimes vary by model usage. The safe way to answer this internally is to check your billing portal and usage report so you’re reading your actual numbers, not a generic table. Then document those numbers in your engineering wiki.
What does the coding agent consume?
One premium request per agent session. Minutes for GitHub Actions may vary depending on how long the agent works, but the premium request accounting itself is one-per-session.
Is this a price hike in disguise?
It’s more of a control shift. If you leave the policy enabled with no cap, you can overspend. If you set a cap and coach teams on where/when to use premium features, the ROI can be excellent—especially on cross-repo chores that routinely soak senior engineer time.
A pragmatic adoption pattern that works
Here’s a model I’ve used to keep finance and engineering aligned without choking the new tooling.
Stage 1: lock it down. Set policy to disabled across the org. Identify two squads with a clear backlog of agent-suitable tasks (think doc regeneration, codebase-wide config updates, or test scaffolding). Give them a small overage budget for a two-week sprint.
Stage 2: instrument everything. Push usage to a shared dashboard. Track agent success rate: completed PRs versus abandoned sessions. Track average session duration and number of follow-up sessions needed per task. Record qualitative wins (e.g., “agent migrated 40 configs in 15 minutes”).
Stage 3: document patterns. When the agent shines, it’s because the task is scoped, the repository perms are correct, and artifacts (tests, scripts, build) are in predictable places. When it fails, it’s usually lack of context or sprawling tasks. Turn those observations into your internal “agent request rubric.”
Stage 4: expand with guardrails. Move the org policy to enabled, keep budgets per team, and add a simple approval step for temporary cap increases. This is the point where you’ll see organization-wide productivity lift without letting spend drift.
Common gotchas and how to avoid them
Hidden service accounts producing spend: sometimes build or automation accounts trigger premium features unexpectedly. Make them visible in your reports, assign them to a cost center, and cap them tightly.
Multi-org sprawl: large companies often have multiple GitHub orgs. If one org flips to enabled and others remain blocked, developers will find the path of least resistance. Align policy across orgs or you’ll be chasing shadow usage.
Agent time versus premium requests: the agent itself is one premium request per session, but long-running tasks still consume Actions minutes. Budget both. If Actions minutes are tight, consider splitting tasks into smaller sessions or scheduling them during low-traffic windows.
Model drift: if a team switches to a premium model in chat and treats it like a default, your allowance can evaporate quickly. Document when premium models are justified—and when the base chat is fine.
Zooming out: why this matters
Copilot has crossed from novelty to operational tooling. The timeline in 2025—allowance enforcement in June, overage policy GA in August, agent sessions simplified in July, and the December budget removal—signals a steady march toward enterprise-ready billing. That’s good news for CFOs, but it puts the onus on engineering leaders to be explicit about when and how premium features are used.
If you get the governance right, you’ll trade sporadic heroics for reliable throughput: fewer long-tail chores, faster PRs, and happier teams. Get it wrong and you’ll either overpay for meandering sessions or frustrate developers when their tools stop on the 10th of the month.
What to do next (this week)
Here’s a tight action list you can run between now and Friday.
- Confirm your org’s premium request paid usage policy state. Decide Enabled or Disabled and document why.
- Set a starting monthly budget above $0 for one pilot team; keep others blocked until you see results.
- Publish a one-page “when to use the agent” guide and share it in your engineering channels.
- Turn on budget burn alerts at 50/80/100% and route them to a shared Slack channel.
- Book a 30-minute brown-bag to show devs where to check their remaining premium requests in the IDE.
Need a deeper runbook or an external review? Our team can help you design the policy, instrument the dashboards, and train your engineers. Start with our overview of AI and platform services, browse a few relevant projects in our portfolio, or reach out directly via contacts.
Related deep dives from our team
If you want specifics, we’ve been tracking this change closely. See our practical rulebook in GitHub Copilot Premium Requests: The Dec 2 Rulebook and our field notes in Dec 2 Is Live. For broader AI platform moves, our blog covers the other big shift we’re advising on: build-your-own models on Nova Forge and multicloud interconnect on AWS.
Final take
The removal of legacy $0 budgets pushed Copilot into the world of explicit policy. That’s a good thing. Your job this week is straightforward: pick a default stance, cap exposure with clear budgets, and teach your teams when a premium request is worth it. Do that, and you’ll keep the focus on outcomes—fewer chores, cleaner code, faster releases—without getting surprised on your next invoice.
