Understanding GitHub Billing and management: from licenses to fair AI credit controls

Buying GitHub Copilot licenses is only the beginning of the governance story. The licenses are purchased centrally, but administrators still need to decide who receives a seat, how usage is attributed to the right part of the business, and what happens when included AI credits run out.

Those decisions happen through several related controls:

• Copilot seat assignment determines which people are licensed.
• Cost centers group attributable usage around a team or business owner.
• AI credit included usage caps create boundaries around included credits associated with a cost center's licenses.
• Cost-center budgets govern paid usage after included credits are exhausted.
• User-level budgets (ULBs) limit how much an individual can consume.

Why does this separation matter? Without it, an administrator can easily mistake one control for another. An included usage cap does not set an overage policy, and a cost-center budget does not guarantee every person an equal share. Each control answers a different question.

This article follows the complete flow, starting before a cost center exists and ending with different policies for Business and Developers, where we place them each in separate cost centers with distinct included-usage boundaries, paid-usage budgets, and ULBs.

Series

This is part of a series on GitHub Admin and billing controls.

• Managing surprise bills
• Better together: GitHub Admin UI + Billing API
• Understanding GitHub Billing and management: from licenses to fair AI credit controls, we're here

Problem 1: A central purchase does not identify who is licensed

Our story starts with a purchase, but purchasing seats does not yet tell us who can use Copilot. This is the first problem to solve because cost centers, budgets, and AI credit controls all depend on GitHub knowing which named users actually hold eligible licenses.

Suppose an enterprise purchases 400 Copilot seats for a workforce that includes 600 employees. The purchase creates a centrally managed pool of seats. It does not automatically license 400 unspecified people, nor does every developer receive a fraction of a license.

At this point, the enterprise knows how many seats it owns, but it cannot yet connect those seats to people, teams, or cost centers.

Solution: Assign seats to named users

An administrator assigns those seats to specific users, either directly or through the supported administrative assignment process. At that point, GitHub can distinguish between:

• A person who belongs to the enterprise but has no Copilot seat.
• A person who has been assigned an eligible Copilot seat.
• A licensed person whose usage is attributable to a particular cost center.

This distinction matters because cost-center included credits are based on attributable eligible licenses, not raw headcount.

For example, imagine a Developers cost center containing 200 people:

Developers in the cost center	Developers with eligible Copilot seats	Licenses that can contribute to the calculation
200	200	200
200	120	120
200	0	0

The cost center does not receive an included-credit boundary based simply on having 200 members. GitHub looks at the eligible licenses attributable to those members and calculates the included amount from those licenses.

NOTE: The exact included-credit amount is calculated by GitHub according to the applicable licenses and product terms. Administrators do not manually divide the enterprise's included credits by cost-center headcount.

Now the enterprise knows who is licensed. That solves entitlement, but it creates the next question: when those users consume AI credits, which part of the business owns that usage?

Fig 1: A developer cost center

Problem 2: Licensed usage has no business owner

A list of licensed users is not yet a governance model. Finance and administrators still need to connect usage to the team, program, or financial owner responsible for it.

Why does this matter? A single enterprise can contain groups with very different usage patterns. Business Operations may have predictable demand, while Developers may run more intensive AI workflows. Treating both groups as one undifferentiated population makes it difficult to protect included usage or govern overage appropriately.

Solution: Use cost centers to establish ownership

Cost centers provide that attribution boundary around resources such as users, teams, or organizations. They do not purchase licenses or assign Copilot seats. Instead, they connect licensed activity to the part of the business responsible for it.

For this scenario, create two cost centers:

• Business, containing the relevant Business users or teams.
• Developers, containing the relevant engineering users or teams.

GitHub can then determine which eligible Copilot licenses are attributable to each cost center. Conceptually, the relationship is:

Cost-center included credits= ∑(included credits from eligible licenses attributed to that cost center)

This is accounting attribution, not a second license purchase. The enterprise still owns and manages the seats centrally. The cost center tells GitHub where the associated usage and included-credit entitlement belong for governance purposes.

With that ownership structure in place, GitHub can tell which licenses are attributable to Business and which are attributable to Developers. Ownership is now clear, but both groups can still participate in the same included-credit pool. That creates the next risk.

Fig 2: Developers and Business cost centers

Problem 3: One group can consume another group's included credits

By default, included AI credits can function as a shared enterprise resource. That is convenient, but it can produce an uneven outcome: one group may consume included credits funded by licenses associated with another group.

Imagine Developers has an unusually intensive month. Without a separate boundary, its members may continue drawing from the shared pool, reducing the included credits available to Business. Attribution tells us who owns the usage, but attribution alone does not protect either group's share.

Solution: Enable the included usage cap

The AI credit included usage cap changes that behavior for a cost center. When enabled, GitHub calculates an included-credit boundary from the eligible licenses attributable to that cost center.

For example, enable the checkbox for both Business and Developers. Each cost center can then use the included credits calculated from its attributable licenses without the other cost center consuming beyond its own boundary.

The safest way to describe this is:

The cost center receives a protected included-usage boundary calculated from its attributable eligible licenses.

It is tempting to call those credits "guaranteed to me," but that wording can imply more than the control provides. The boundary belongs to the cost center, not to an individual, and it does not guarantee that every member receives an equal allocation.

The shared-pool problem is now addressed, but the checkbox also exposes the next question: what happens after a cost center exhausts its protected included credits? The cap separates included usage; it does not define the paid-usage policy.

Fig 3: Included usage cap checked on a cost center

Problem 4: The included usage cap does not stop overage

Once a cost center reaches its included-credit boundary, additional eligible usage may become paid usage when paid AI credit usage is enabled. A cost-center budget determines how that overage is monitored or stopped.

Why is a separate budget necessary? The included usage cap says, "Do not continue consuming included credits beyond this cost center's calculated boundary." It does not necessarily say, "Block all subsequent usage." A spending control is required to define that second outcome.

Our two cost centers need different outcomes. Business should stop before overage, while Developers should be allowed to continue so the enterprise can observe real demand.

Solution for Business: Use a $0 hard budget

Business should use its included credits but create no overage. Configure a $0 cost-center budget and enable Stop usage when budget limit is reached.

Together, the controls mean:

1. Business uses the included credits associated with its attributable licenses.
2. The included usage cap prevents it from drawing beyond its protected included boundary.
3. The $0 hard budget allows no paid usage after included credits are exhausted.

The $0 budget does not prevent Business from using included credits. It establishes a zero-dollar allowance specifically for the paid-usage phase.

NOTE: If paid AI credit usage is disabled for the entire enterprise, a $0 cost-center budget may be redundant. It becomes important in this scenario because Developers must retain access to paid usage under the same enterprise account.

!Business cost center with a $0 hard budget](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/fw05ktbkv415rph8jm5u.png)

Fig 4: Business cost center with a $0 hard budget

Solution for Developers: Start with a soft budget

Developers need more flexibility. Configure a funded cost-center budget, such as $20,000, but leave Stop usage when budget limit is reached disabled.

This is a soft budget. It provides a target and supports alerts, but it is not a hard ceiling. Usage can continue beyond $20,000 unless another applicable control stops it.

That behavior is useful while the organization learns the team's real demand. Administrators can monitor spending, review whether the usage produces value, and later decide whether to change the amount or turn on the stop control.

At this point, Business and Developers have distinct overage policies:

Cost center	Included usage	Paid-usage budget	Stop usage	Outcome
Business	Protected boundary enabled	$0	Yes	Use included credits, then stop
Developers	Protected boundary enabled	$20,000	No	Use included credits, then allow monitored paid usage

We have now defined what paid usage means for each cost center. However, the Developers budget controls the group total, not the behavior of each person inside the group. One heavy user could still consume a disproportionate amount, which leads to the next problem.

Fig 5: Developers cost center with a $20,000 soft budget and no stop control

Problem 5: An aggregate budget does not create individual fairness

The $20,000 Developers budget gives administrators visibility into aggregate paid usage, but it does not divide that amount fairly among the people in the cost center. A few heavy users could consume most of the available capacity while everyone else remains far below the group budget.

Why add a ULB when Developers already has a $20,000 budget? The two controls operate at different levels:

• The $20,000 cost-center budget monitors the Developers group's aggregate paid usage.
• A cost-center ULB gives each person in Developers an individual ceiling.

Solution: Add a cost-center ULB

A user-level budget limits one person's total AI credit consumption during the billing cycle. It follows the user across included and paid usage and acts as a hard stop when the applicable limit is reached.

For example, configure a $200-per-user cost-center ULB for Developers. This prevents a small number of heavy users from consuming a disproportionate amount while other users receive little opportunity to work.

The $200 value is a maximum, not a reservation. It does not set aside $200 for every person, and unused capacity from one user is not a personal entitlement that another user can claim. It simply says that each covered user stops when their individual consumption reaches $200.

This makes the policy more predictable and equitable without requiring administrators to create a separate budget for every member of the cost center. The common baseline solves the fairness problem, but a uniform limit can be too restrictive for specialized roles.

Fig 6: Developers cost center with a $200 per-user ULB

Problem 6: One baseline does not fit every role

A shared baseline will not fit every role. A platform engineer, AI lead, or approved power user may have a legitimate need for more capacity than the Developers baseline permits.

Raising the $200 limit for the entire cost center would solve that person's problem by giving everyone more capacity. That is broader than necessary and weakens the fairness policy we just established.

Solution: Add an individual override

For example, create an individual ULB of $400 for softchris. That individual policy takes precedence over the $200 Developers cost-center ULB.

The precedence is:

1. Individual ULB
2. Cost-center ULB
3. Universal ULB

This lets administrators start with a broad enterprise default, apply a more suitable baseline to a cost center, and reserve individual overrides for documented exceptions.

An individual override should still be reviewed. More capacity is not automatically better governance; it should correspond to an approved role or business outcome. We have now solved each problem at the narrowest appropriate scope.

Fig 7: Individual ULB override for a specific user in the Developers cost center

Resolution: See the complete control model

Now that each control has been introduced separately, we can connect them into one end-to-end model.

1. Purchase Copilot seats centrally. The enterprise or organization owns the seat pool.
2. Assign seats to named users. This establishes who holds an eligible Copilot license.
3. Attribute users, teams, or organizations to cost centers. This connects licensed activity to Business or Developers.
4. Enable the included usage cap. GitHub calculates a protected included-credit boundary from eligible licenses attributable to each cost center.
5. Set cost-center budgets. Business receives a $0 hard budget; Developers receives a $20,000 soft budget.
6. Set a cost-center ULB. Developers users receive a $200 individual ceiling.
7. Add approved exceptions. softchris receives a $400 individual ULB.

The resulting Budgets and alerts view tells a coherent story:

Type	Scope	Amount	Purpose
Cost center	Business	$0, stop enabled	Prevent paid overage after included usage
Cost center	Developers	$20,000, stop disabled	Observe aggregate paid usage without an immediate hard stop
User • Cost Center	Developers	$200 per user	Apply a fair individual baseline across the cost center
User	softchris	$400	Preserve an approved individual exception

These four rows do not show the included usage caps themselves; those are configured on the cost-center details. The rows show the controls that govern paid usage and individual consumption after the attribution model has been established.

Checkpoint: Avoid the most common misunderstandings

The controls become easier to operate when their boundaries are explicit. Keep these distinctions in mind:

• Purchasing 400 seats does not automatically license an unspecified 400 people. Seats must be assigned to users.
• Putting 200 people in a cost center does not mean 200 licenses contribute to its included-credit calculation. Only attributable users with eligible licenses contribute.
• An included usage cap does not assign an equal number of credits to every person.
• An included usage cap does not, by itself, define the cost center's paid-usage policy.
• A soft cost-center budget is an observation and alerting threshold, not a hard ceiling.
• A cost-center ULB is a per-user maximum, not a guaranteed allocation for each person.
• An individual ULB overrides a broader cost-center or universal ULB for that user.

The easiest way to remember the model is:

Assign the license. Attribute the usage. Protect included credits. Govern paid usage. Limit the individual.

Outcome: Different teams, appropriate controls

Business and Developers now operate under the same enterprise purchase but follow policies suited to their work.

Business can consume the included credits associated with its attributable licenses and then stops before creating paid usage. Developers can continue into paid usage while administrators observe demand against a soft budget. A cost-center ULB prevents a few users from dominating consumption, while individual overrides preserve approved exceptions.

No single checkbox provides all of that behavior. The result comes from combining license assignment, cost-center attribution, included-credit boundaries, spending budgets, and ULBs in the right order.

That order is the practical governance lesson: protect included usage first, decide how paid usage should behave second, and then add per-user controls where fairness or predictability requires them.