If you search for "GitHub Copilot budget policy", most posts point you to cost centers: assign a budget to a cost center, map the cost center to a team or business unit, done. Clean story, except for one detail nobody mentions upfront — cost centers require a GitHub Enterprise Cloud account.
That's not the same thing as being on the Copilot Enterprise plan; user-level budgets already work fine on Copilot Business. It's about the account type; a standalone Organization account doesn't have cost centers, and neither does GitHub Enterprise Server if you're self-hosted. If you're not on Enterprise Cloud, cost centers are off the table.
We ran into exactly this. No Enterprise Cloud account, no cost centers, but still a real need to keep Copilot spend under control across a growing user base.
Remark: if you do have GitHub Enterprise Cloud, cost centers are probably still the better fit. This post is for the rest of us.
The starting point
We have two distinct groups of Copilot users:
- A large group of daily users: they use Copilot as part of their normal workflow, fairly predictable usage.
- A smaller group of power users: heavier usage, more experimentation, agent-style workloads that burn through budget faster.
A single flat budget per user doesn't work here: set it low enough to control the power users and the daily users are needlessly constrained; set it high enough for the daily users and the power users blow through any real cost control.
The approach: layered per-user budgets
Without cost centers, the building block you're left with is the per-user budget. So instead of trying to simulate teams or business units, we built the policy around the two groups we actually have:
- A universal budget that applies to every Copilot user in the organization.
- An additional per-user budget assigned specifically to power users, on top of the universal one.
The budget itself stays pooled at the enterprise level. We're not carving out separate pots of money per team. What changes is the ceiling: no individual user, regardless of group, can exceed their assigned budget. A daily user is capped at the universal amount. A power user is capped at the universal amount plus their extra allocation.
Remark: the pooling matters. It means unused budget from daily users isn't wasted. It stays available at the enterprise level while still giving you a hard per-user ceiling to prevent runaway individual spend.
Configuring it step by step
This is done under "Budgets and alerts" on your organization or enterprise billing page. Concretely:
- Go to Budgets and alerts. Navigate to your organization or enterprise account, open Billing & Licensing, and click Budgets and alerts.
- Create the universal budget. Click New budget → set "Budget Type" to AI credits budget → under "Budget scope" choose Users → Universal. This creates a per-user budget that applies to every Copilot-licensed user by default.
- Set the universal amount above the per-license value. GitHub explicitly recommends setting it above $19 (Copilot Business) or $39 (Copilot Enterprise) per seat, so pooling still works and lighter users' unused budget is available to heavier ones instead of everyone being hard-capped at exactly their own license value.
- Identify your power users. Use the AI usage dashboard to see who's consistently bumping against the universal budget — agent-heavy workflows and large-codebase work are usually the pattern.
- Create an individual override per power user. Click New budget → set "Budget Type" to AI credits budget → under "Budget scope" choose Users → Individual user. Select the specific person, you want to give a different budget. An individual user-level budget overrides the universal one for that user only — nobody else is affected.
- Set an enterprise spending limit as a backstop. This caps total metered charges once the shared pool is exhausted; it doesn't affect how individual users draw from the pool, it's the ceiling on the pool itself.
- Enable "Stop usage when budget limit is reached" on the spending limit. User-level budgets always hard-stop automatically, but spending limits don't unless you turn this on — without it, you just get an email while charges keep accruing.
- Revisit monthly. Watch for users getting blocked early (universal budget too tight, or a new power user you haven't flagged yet) versus the pool lasting the whole cycle with no blocks (well-tuned).
Tip: if you don't have usage data yet, don't overthink the starting numbers — set something reasonable for the universal budget and tune it after your first billing cycle using the dashboard.
Why this works for us
- It's simple to reason about: two tiers, two numbers.
- It doesn't require an Enterprise Cloud account to get some form of cost governance.
- It scales the right way: as we identify more power users, we just assign them the extra per-user budget instead of restructuring the whole policy.
It's not as granular as cost-center-based reporting per team. If you need to answer "how much did Team X spend this quarter", this approach won't get you there directly. For us, controlling total spend and preventing individual overuse mattered more than per-team attribution, so the trade-off was worth it.
That's it. 2 budget tiers, pooled at the top, capped per user.