This is a story of how you receive a higher bill than expected and how GitHub's Billing Controls help clarity and predictability. Let's begin our story.
The AI bill is higher than expected. Now what?
Finance wants to understand what is driving the cost. Engineering leaders, on the other hand, want to preserve the productivity gains behind the increased usage. The administrator needs to balance both priorities and put a policy in place that the business can understand.
One question drives the investigation:
Where is the increase coming from, and how do we control it without disrupting valuable work?
To answer it, we first need to follow the spend. Once we know who owns it, we can apply guardrails at the right level.
Setting a limit too early could restrict useful adoption without addressing the main source of cost. So, let's find out what changed and who can act on it.
The investigation begins in the billing administration portal, where usage and budget settings appear in one place.
Fig 01: A unified billing workspace connects usage evidence to budget controls.
First, we identify which product changed. GitHub reports this by SKU, which simply means the billing category for a product or service.
Fig 02: Grouping metered usage by billing category highlights Copilot Enterprise usage.
Grouping usage by billing category shows which product is driving the increase. In this example, the chart points to Copilot Enterprise usage. Leaders can then ask whether that growth comes from valuable adoption, an unusual workload, or demand that has outgrown its budget.
Once you know which product is driving the cost, find out who owns the usage. An enterprise-wide total can hide a sharp increase in one organization.
Fig 03: Organization-level grouping identifies the business unit accountable for demand.
The organization view points to the leader who can connect that usage to business results, estimate future demand, and decide what to do next.
An organization may still be too broad. A cost center is a billing group that connects usage to the team, program, or function responsible for the cost.
Fig 04: Cost-center analysis reveals concentrated usage averaging about $20,000 per month.
Here, one cost center accounts for most of the AI credit usage and averages about $20,000 per month. That gives leaders a practical starting point. A $20,000 alert may suit normal demand, while a growth team, seasonal workload, or strategic migration may need more headroom, or more room to spend before reaching the limit. The right amount depends on expected usage, financial risk, and the value the work creates.
The investigation has now produced an answer: most of the increase comes from one cost center spending about $20,000 per month. The next question is what to do about it.
Rather than place one restrictive limit on everyone, the administrator can add guardrails at three levels: across the organization, for the cost center driving the increase, and for individual users who need a different limit.
The Budgets and alerts page is where those decisions become policy.
Fig 05: The Budgets and alerts page provides the New budget action.
Let's start with the broadest guardrail and then make it more specific.
An organization budget gives finance a clear limit for usage charges. License costs are separate and do not count toward this amount.
Fig 06: A $200,000 organization budget establishes a configurable boundary for paid usage.
The $200,000 organization budget shown here is an example. The right amount depends on expected usage, available included credits, growth plans, and what would happen if paid usage stopped. This shared budget applies only to additional paid usage after included credits are used. It does not include license costs.
There is one timing detail to keep in mind: if you create the budget partway through a billing cycle, GitHub does not count usage from earlier in that cycle. The first bill can therefore exceed the displayed $200,000 limit.
The Stop usage when budget limit is reached toggle controls what happens next. Leave it off and GitHub sends notifications while usage continues. Turn it on and affected paid usage stops at the limit. GitHub Copilot code completions and next edit suggestions still work because they do not use this paid AI credit allowance. A blocked request also does not automatically switch to a cheaper model.
The organization budget covers shared paid usage across the organization. A cost-center budget gives a specific team an earlier warning.
Fig 07: A $20,000 cost-center threshold monitors current demand without stopping usage.
In this example, the administrator sets a $20,000 alert and leaves the stop toggle off. The owner can review the workload, remove waste, or ask for a higher limit before usage is interrupted.
The same timing rule applies here: if the budget is created partway through the billing cycle, earlier usage is not counted. The first bill can therefore exceed the displayed $20,000 limit.
Fig 08: Threshold alerts route emerging cost risk to owners before month-end.
Alerts give people time to act. Finance can review expected spending, the cost-center owner can explain the increase, and the administrator can adjust the limit or turn on stopping if needed.
Shared budgets do not control how many AI credits one person can use. Per-user budgets do. They count both included and paid credits, and they always stop further AI-credit use when the person's limit is reached.
Set these limits from broad to specific:
Fig 09: A $200 per-user cost-center exception adds targeted headroom without raising the enterprise baseline.
The screenshot shows the second step: a $200 per-user limit for one cost center. Start with the universal baseline, then add an individual override only when someone has a clear need for a different amount. This keeps exceptions easy to review and avoids raising the limit for everyone just to support one specialist.
What happens when several limits cover the same user? Precedence is simply the order GitHub follows to choose the user-level budget that applies.
Fig 10: Policy precedence applies individual overrides before cost-center and universal user limits.
Among user-level budgets, the individual override comes first, followed by the cost-center per-user budget and then the universal baseline. For example, imagine a $100 universal baseline, a $200 cost-center limit, and a $500 individual override. The specialist gets $500, colleagues in that cost center get $200 each, and everyone else gets $100 each.
Shared organization and cost-center limits still apply separately. Whichever relevant limit is reached first blocks further usage. A person may still have money left in an individual budget when the shared limit has already been reached. The reverse can also happen: a person's limit may stop their usage while the shared budget still has room.
Setting the limits is only the start. Someone still needs to review what happens next.
Finance can see where paid usage is limited. Business owners can see which costs they own. Engineering leaders can see where exceptions protect important work. Included-pool controls protect shared credits, organization and cost-center budgets limit additional paid usage, and per-user budgets set individual limits.
Assign someone to review alerts, blocked requests, approved exceptions, and business results on a regular schedule. When a team repeatedly reaches its limit, that owner can look for waste, compare usage with results, and recommend a change. Finance and engineering leaders can then approve the change or step in when cost and delivery needs conflict.
With those responsibilities clear, finance can see the cost, business leaders can own it, and administrators can adjust the controls before the next surprise bill arrives.
The story above introduces each control when it becomes useful. This table collects the technical differences in one place for reference.
| Control | What it does | What it counts | What happens at the limit |
|---|---|---|---|
| Organization or cost-center budget | |||
| Monitors or limits shared paid usage | Additional paid usage after included credits are used; license costs are excluded | Sends alerts, or stops affected paid usage when stopping is enabled | |
| Included AI credit pool | |||
| Protects the credits included with licenses assigned to a cost center | Shared included AI credits calculated by GitHub | Blocks more AI-credit use, or allows paid usage when paid usage is enabled | |
| Per-user budget | |||
| Limits one person's total AI-credit use | Included and paid AI credits for that user | Always stops more affected usage |
When an included AI credit pool runs out, administrators can block further AI-credit use or allow it to continue as paid usage, as long as paid usage is enabled. Some reductions to the pool take effect in the next billing cycle, so check the timing before relying on a lower limit.