Keep Shipping: When an AI Budget Runs Out

Disclaimer: I work at Microsoft. This is my personal view, based only on public information. It isn’t an official position or a product recommendation.

I kept returning to the moment a developer reaches a spending limit mid-task. The budget owner needs to keep spending controlled; the developer wants to keep working. A hard stop protects the budget, but it does not answer what should happen next.

GitHub Copilot gives me a concrete case to examine. When a user reaches an applicable hard-stop budget, the AI-credit-consuming features covered by that budget pause. On paid plans, code completions and next edit suggestions may remain available. Budget ownership and precedence depend on the configured enterprise, organization and user controls.

Could an organization approve a higher spending cap while restricting which models remain available? That is the design experiment behind this article. Whether the combination preserves the intended policy has not been verified in a pilot. It is my take on the problem, inspired by OpenAI’s spend controls, not a recommendation that every organization adopt the same policy.

Copilot users are the people working with GitHub Copilot. They want to finish the task, understand why credit-consuming features have paused, and know how to request more usage. In the example, one user represents that perspective.

The budget owner controls spending rules and model access. Here, that means someone authorized to manage those enterprise settings, not simply a repository administrator. They decide how much additional consumption to allow and when a temporary exception should expire.

I built a private prototype to automate some of that admin’s work: checking reported usage, changing the managed model-team memberships, and applying approved budget changes. The admin still verifies Luna-only access and approves the additional usage in this design; the automation does not approve its own spending.

OpenAI’s usage-limit controls for eligible ChatGPT Enterprise and Edu workspaces separate a person’s allowance from the workspace’s overall spending control. They support defaults, individual exceptions, and approved temporary increases.

The part that interested me was the operating model: give people a normal allowance, make additional usage an explicit decision, and let a temporary exception expire rather than become a permanent entitlement.

That does not mean copying OpenAI’s billing units or assuming every product works the same way. ChatGPT workspace controls and OpenAI API-platform controls are different surfaces. Neither should be treated as interchangeable with GitHub’s billing model.

GitHub also has native requests for additional Copilot budget and expiring individual user-level budgets. The request flow is not available for enterprises with managed users, so check its availability for your account.

My extension was to connect an exception with a narrower choice of models: instead of immediately restoring the original set of approved models, could a small allowance on a lower-priced GPT-6 option be enough for some of the remaining work?

OpenAI inspired the allowance-and-exception pattern. The lower-priced model transition is my experiment, not a claim about an OpenAI feature.

Before building anything, I had to separate two controls that are easy to blur together.

An available model is not necessarily an affordable model. Giving someone permission to use a cheaper model does not make it free, and it does not override an exhausted user budget.

Under GitHub’s AI-credit billing model, included credits are pooled at the billing-entity level. A Copilot Business seat contributes 1,900 credits to that pool; it does not create a private 1,900-credit wallet for its holder.

A user-level budget is an additional control over how much a person can consume, including both pooled and metered usage. If that budget is exhausted, credit-consuming features are blocked even when the pool still has capacity. Code completions and next edit suggestions remain available on paid plans.

This meant my proposed fallback needed two things, in the right order: establish and verify the intended model restriction, then apply an explicitly approved budget cap.

It could not be a way around the budget.

I chose a fictional user’s monthly journey to make the idea concrete. The numbers below are example policy choices, not a claim that everyone should have the same limit.

The example starts with a $19 user-level cap, equivalent to 1,900 AI credits at the published rate; it is not a reserved credit allocation. The fallback model is GPT-6 Luna, which is lower-priced than the other GPT-6 options in GitHub’s published model prices. The proposed cap increase is 100 credits ($1 of AI-credit consumption), limited by this prototype’s policy to once per user per monthly cycle.

Here, “all models” always means the models the enterprise has approved. It does not include models prohibited by its security or compliance policies.

The example’s $40 cap includes the proposed $1 increase (raising the cap from $19 to $20) and a separate approved $20 increase. If an increase arrives earlier, the calculation starts from the current cap instead. In this prototype’s intended state machine, switching teams does not reset tracked consumption or authorize another grant; this is not a GitHub billing guarantee.

There is an important administrative distinction, too. My prototype accepts an increment: “add $20.” GitHub’s native approval interface sets a new total budget. To add $20 to a current $20 cap there, the new total is $40, not $20.

Raising that cap does not purchase or reserve credits. It permits more consumption, which can create additional charges when included capacity runs out. GitHub’s other spending controls, including applicable enterprise, organization, or cost-center limits and paid-usage policy, still have to allow it.

My initial idea sounded simple: put an exhausted user on a temporary team that only has access to Luna.

But GitHub’s enterprise-team model grants are additive. If another team grants a model, or the enterprise enables it for everyone, adding a more restricted team does not take that access away.

The design uses dedicated model-access teams and removes the managed full-model grant during the fallback transition. Those teams must not also control repository permissions or Copilot license assignments.

Other grants still matter. The design cannot claim Luna-only access just because one membership changed successfully.

There is also a broader prerequisite: enterprise teams mode changes where granular model policy is managed and deactivates organization-level model settings. The model-policy targeting through enterprise teams described by the linked documentation is an opt-in public preview. That is not a small switch to enable casually for a single-user experiment. An existing enterprise would need to assess the effect on everyone else before adopting it.

The prototype design uses GitHub Actions and public APIs to coordinate the transition. Native GitHub budgets remain responsible for spending enforcement.

The unpublished prototype is designed to detect exhaustion, keep the existing cap in place, remove its full-model grant, and establish the fallback membership. An administrator would then need to verify the intended model restriction in the relevant clients before approving a $1 cap increase. The implementation and its idempotency behavior cannot be independently inspected or tested.

That verification step is deliberate. I have not established a supported API signal that proves all relevant clients and existing sessions have applied the restriction. A successful membership response is not enough evidence, and a fixed delay would not make it enough.

So this is not seamless fallback. There is still a pause.

Scheduled reconciliation is not instantaneous. Public documentation does not establish whether a membership change automatically remaps the model in every existing conversation. I assume a user may need to refresh their client or choose Luna themselves; that needs per-client testing.

That is the gap between the ambition and the implementation. “Keep shipping” is the question I am exploring, not a result I can claim simply because the automation runs.

A cheaper model is only useful here if it can do the work.

The remaining task might need capabilities, context, or tools that make a particular model unsuitable. More retries can erase an apparent saving. Waiting for an administrator can erase the continuity benefit.

I would want to evaluate:

• Whether the developer completes the task at an acceptable level of quality.
• The total AI cost of getting to that result, not just the model’s token price.
• Time spent blocked, switching models, or waiting for approval.
• The administrative effort required to operate and recover the workflow.

The comparison is not only “expensive model versus cheap model.” It is also “this custom transition versus a normal, approved budget increase.”

Compared with stopping usage, the grace allowance authorizes more consumption. Compared with unrestricted access to the original model set, it might reduce the cost of the remaining work. Whether that trade is worthwhile needs evidence.

The private prototype is designed around native user budgets, dedicated enterprise model teams and GitHub Actions. It is intended to record operations so a retry does not request the same increase twice and to tie temporary increases to a monthly cycle; these guarantees cannot be independently verified without public code and tests.

The prototype is not published as a public repository, so this article describes the approach and trade-offs rather than offering a runnable implementation.

I have not completed a live enterprise pilot. I do not yet have measured savings, delivery improvements, or evidence that this approach suits every AI-assisted workflow. A native budget increase may be the simpler answer in many cases.

That does not settle the experiment either way. It tells me what to investigate next.

This is Part 1 of the Keep Shipping prototype series. Part 2 will turn the sketch into explicit policy: which budget applies, what each transition can change, and what must remain untouched. Subscribe to the writing RSS feed to get future installments.

The idea I want to carry through the series is simple:

A spending limit can be correct while the experience around it still deserves better design.

That is what “keep shipping” means in this prototype series: exploring a more useful path through a legitimate constraint, not pretending the constraint has disappeared.

Product behavior and availability are time-sensitive. These are the primary references behind the design; check the documentation and the controls available in your own environment before treating the example as an implementation plan. The GitHub references were reviewed on 13 October 2026. The OpenAI usage-limit guidance was reviewed on 7 October 2026. Availability and prices can change.

• OpenAI: manage usage limits, temporary increases, and workspace spending controls
• GitHub: AI-credit billing for organizations and enterprises
• GitHub: user budgets, precedence, and expiration
• GitHub: requests for additional Copilot budget
• GitHub: enterprise model availability and additive team grants
• GitHub: enterprise-team model policy targeting public preview
• GitHub: GPT-6 Luna availability
• GitHub: Copilot models and pricing

← All writing