The End of Flat-Rate AI: GitHub Copilot’s Shift to Usage-Based Billing

GitHub has announced a major change to Copilot billing.

From 1 June 2026, GitHub Copilot is moving away from premium request units and into a usage-based billing model built around GitHub AI Credits.

For anyone leading engineering teams, managing software budgets, or building AI-enabled delivery models, this is an important signal.

AI tooling is starting to look less like traditional SaaS pricing and more like cloud infrastructure pricing.

Here’s what is changing:

- Tokens, not requests Premium request units are being replaced by GitHub AI Credits. Usage will be calculated using input tokens, output tokens, and cached tokens, based on the published rates for each model.

- Base plans become credit pools The subscription prices are not changing. For example, Copilot Business remains $19 per user per month, but that now includes $19 worth of monthly AI Credits.

- Autocomplete is still included Code completions and Next Edit Suggestions remain included and will not consume AI Credits.

- Enterprise usage becomes pooled For Business and Enterprise customers, included usage can be pooled across the organization. That is a good move because it avoids unused credits being trapped with individual users.

- Fallback behaviour is going away Previously, if a user ran out of premium requests, Copilot could fall back to a lower-cost model. Under the new model, usage is governed by available credits and budget controls.

- Copilot code review becomes more expensive to run Copilot code reviews will consume AI Credits and, for private repositories using GitHub-hosted runners, GitHub Actions minutes as well.

And this is where I think it gets interesting.

The agentic era has a real compute cost.

Copilot is no longer just an autocomplete tool sitting inside your IDE. It is becoming an agentic platform capable of running longer, more complex coding sessions across repositories.

That changes the economics completely.

When AI is helping finish a line of code, flat-rate pricing makes sense.

When AI is reviewing pull requests, reasoning across a codebase, generating changes, refactoring modules, and running multi-step workflows, the cost model starts looking much closer to cloud compute.

This is the part engineering leaders need to pay attention to.

The question is no longer just:

“Should our developers use AI?”

The better question is:

“Do we understand how AI usage translates into operational cost?”

For South African businesses, this matters even more. These costs are priced in dollars, while many of our budgets are managed in rands. That means token consumption, exchange rates, and team behaviour all start affecting the real monthly cost.

Budget controls are no longer optional.

By June 2026, teams should be thinking about:

How much AI usage is reasonable per developer? Which models should be available by default? Should code review agents run on every PR or only selected PRs? How do we monitor usage by user, team, model, and workflow? Where do we set hard caps before experimentation becomes invoice shock?

I don’t see this as a bad move.

I see it as the AI tooling market maturing.

We are moving from the “all-you-can-eat buffet” phase of AI adoption into a utility-style model where usage, governance, and cost visibility matter.

For companies building serious AI-enabled engineering practices, this is probably the right direction.

But it does mean one thing very clearly:

AI adoption now needs financial architecture, not just technical enthusiasm.

Are you tightening your organization’s AI budget controls, or are you opening the floodgates and letting your agents run wild?