A temporary increase to a GitHub Copilot user’s allowance is easy to approve. The awkward question is who remembers to remove it after a sprint, incident, or short project ends.

On September 1, 2026, GitHub made expiration dates for individual user budgets generally available for Copilot Business and Copilot Enterprise. When the date arrives, GitHub removes the individual budget automatically.

That deletion does not end budget evaluation. The practical result depends on the broader budget that takes over, so expiration and fallback need to be designed together.

Expiration turns a temporary override into a bounded rule

When creating or editing an individual user budget, an administrator can choose one of three expiration modes:

• No expiration, the default, which keeps the budget until it is edited or deleted
• The current billing-cycle boundary, where removal occurs as the next cycle begins
• A specific date, shown in the UI as a UTC date

The expiration can be changed or cleared later. This moves the cleanup decision to the moment when the exception is created instead of relying on a separate reminder.

GitHub identifies a single sprint, an incident, and a short-term project as useful cases. The feature is therefore best understood as an end condition for an exception, not as another permanent budget tier.

A three-level hierarchy decides the limit after expiration

GitHub Copilot has three user-level budget scopes, from broadest to narrowest: universal, cost-center, and individual. When several apply, the individual budget wins, followed by the cost-center user-level budget and then the universal budget.

Budget	Typical role	Priority
Individual user budget	Change the limit for one user	1
Cost-center user-level budget	Set a per-person limit for a department or team	2
Universal user-level budget	Provide the default for licensed users	3

When an individual budget expires, GitHub removes it. The user falls back to a cost-center user-level budget if one applies, otherwise to the universal budget; if neither exists, no user-level budget remains. The same order appears in GitHub’s budget setup documentation.

A cost-center user-level budget is different from a cost-center budget. The former caps each person’s AI credit consumption across the included pool and metered phases, while the latter caps a team’s metered charges only after the shared pool is exhausted.

The budget system gained an end state for individual exceptions

This feature continues the AI credit controls GitHub introduced in 2026. On June 1, GitHub activated usage-based Copilot billing and made user-level budgets generally available. On June 30, it added per-user budgets scoped to cost centers.

Those releases created a useful pattern: an enterprise-wide default, a team-level default, and an individual exception. Expiration does not add another tier; it removes the most specific tier at a planned boundary.

GitHub’s budget optimization guide recommends sizing steady-state budgets from historical usage and using individual overrides for temporary spikes. Team-wide differences can live in cost-center defaults, leaving expiring individual budgets for genuinely temporary needs.

Set the fallback before selecting a date in the UI or API

In the UI, open an enterprise’s “Billing & Licensing” area, choose “Budgets and alerts,” and create a “Bundled AI credits budget” with Users as the scope. Selecting a specific user exposes the Expiration control with no-expiration, billing-cycle-end, and specific-date choices. GitHub’s setup guide also documents the relevant enterprise owner and billing manager access.

For automation, pass expires_at when creating or updating an individual user budget. The Budgets REST API accepts a future YYYY-MM-DD value only for budgets whose budget_scope is user; on update, null or 0 removes an existing expiration.

A compact operating sequence is:

1. Put the steady-state limit in a universal or cost-center user-level budget.
2. Match the individual override’s expiration to the reason for the exception: a billing-cycle boundary or a specific project date.
3. Verify the amount that will apply after expiration against the user’s cost-center membership.
4. For API automation, validate both the user scope and the future date before sending the request.

User-level budgets cap consumption across both the shared pool and additional usage, and they always act as a hard stop. One AI credit equals USD 0.01, so a USD 30 budget represents 3,000 credits. When raising a temporary limit, compare both its end date and its credit difference from the steady-state fallback.

Expiration restores the standing rule instead of creating a new one

An individual budget can now describe both the size of an exception and when that exception ends. Choosing the billing-cycle boundary or a project date at creation time reduces the recurring cleanup work that previously depended on manual deletion.

The effective limit after expiration still comes from the fallback hierarchy. The practical answer is to treat universal and cost-center user-level budgets as the standing policy, then use expiring individual budgets only as bounded exceptions to it.

Source

• Title: Set an expiration date for individual user budgets
• URL: https://github.blog/changelog/2026-09-01-set-an-expiration-date-for-individual-user-budgets