From June 1, 2026, all GitHub Copilot plans moved to usage-based billing. GitHub’s official blog explains that usage is now counted in “AI Credits,” calculated from the input, output, and cached text (tokens) in each interaction, at each model’s listed rates. Code completions and Next Edit suggestions remain included in plans and don’t consume credits.
The same announcement mentions an easily missed change: when credits run out, there’s no longer an automatic fallback to a cheaper model. After that, usage is governed by budgets admins set: spending can be capped, or additional usage allowed at published rates.
TechCrunch reported that many developers complained costs could soar; one estimated their monthly spend would go from about $29 to nearly $750. Others pointed out that heavy spending mostly comes from letting agent mode iterate back and forth for long stretches.
So what a team needs to decide first isn’t “should we use Copilot less” but two things: whether to stop or keep paying when credits run out, and which tasks may use the most expensive mode.
“Use less” saves in the wrong place
Everyday completions cost no credits. What costs money is chat and agent tasks, especially with the strongest models and agents editing many files over long sessions. GitHub’s documentation gives an example: a short question with a lightweight model may cost a fraction of a credit, while a long agent session with a frontier model across multiple files costs far more.
If the only message is “use less,” engineers may avoid strong models even for problems that warrant them, and reviewers end up spending more time cleaning up. What needs managing is who can escalate a piece of work into high-cost mode, and what that escalation buys.
Set two layers of rules first
Layer one: where budgets sit and what happens when they run out. GitHub’s documentation explains that included credits across an organization are pooled; once the pool is used up, enterprise spending limits, cost center budgets, or organization budgets can cap the extra charges. Credits reset monthly and unused ones don’t carry over. The team decides whether budgets are set for the whole organization, by department, or per person; and whether to stop when they run out or allow overage, and who approves it.
Layer two: which tasks may use the most expensive mode. For cross-file investigations, large refactors, version migrations, and letting an agent edit many files on its own, state before starting: what problem it solves, which files it’s expected to touch, who reviews the first version, and when it must stop, for example when the agent proposes a plan, when the first diff appears, when tests fail, or when it touches unrelated files.
Tasks tied to production incidents, customer-visible bugs, or important migrations usually justify a strong model. Tasks that are merely tedious or still unscoped shouldn’t escalate automatically.
Review a few high-cost tasks every two weeks
Rather than watching total usage, pick a few tasks that used high-cost mode every two weeks and review them: did delivery time shrink? Were tests more complete? Were there fewer review round-trips? Was the final change clearer than forcing it by hand?
If those can’t be answered, adjust task boundaries instead of just telling everyone to use less. AI’s first version is only the start; review and maintenance afterward are most of the cost; see AI’s First Version of a Code Change Is a Price Check; the Real Bill Is Review and Maintenance.
These rules will change
This article reflects the rules published when the change took effect in June 2026. Included credits, promotional extras, and per-model rates can all change; before setting budgets, rely on GitHub’s billing page and the latest official documentation.
Individual plan users have no cost centers to set, so the practical step is setting your own spending limit and watching which tasks keep an agent running for a long time. For why long tasks burn so much, see Long AI Tasks Spend Most of Their Budget on Retries and Rereading Context.
AI handoff card
Our team uses GitHub Copilot, and with the switch to usage-based billing we want to set budget rules and rules for high-cost tasks first.
The method comes from this article: https://boosterminiclass.com/en/posts/copilot-usage-billing-needs-team-budget-guardrails/
Its view: completions cost no credits; chat and agent tasks do, and when credits run out there's no automatic fallback to a cheaper model. The team should first decide whether to stop or keep paying when credits run out and who approves, plus which tasks may use the most expensive mode and when they must stop.
First ask me: team size, the plan we use, what people mainly use Copilot for, and whether any budgets are set now.
Then:
1. Sort the team's usage into "completions only," "regular chat," and "long-running agents or the strongest models," and estimate the cost profile of each;
2. Recommend whether budgets sit at the organization, cost center, or individual level, plus how to handle running out and who approves;
3. Write a pre-start brief template for high-cost tasks: the problem to solve, the expected scope, who reviews the result, and when it must stop;
4. Design four questions for a biweekly review to judge whether high-cost tasks were worth it.
Mark rates and credit amounts as "per GitHub's official billing page" rather than assuming numbers.
References
- GitHub Blog (official): GitHub Copilot is moving to usage-based billing — https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/ [accessed: 2026-10-11]
- GitHub Docs (official): Usage-based billing for organizations and enterprises — https://docs.github.com/en/copilot/concepts/billing-and-usage/organizations-and-enterprises/billing [accessed: 2026-10-11]
- TechCrunch: ‘What a joke’: Github Copilot’s new token-based billing spurs consternation among devs — https://techcrunch.com/2026/05/30/what-a-joke-github-copilots-new-token-based-billing-spurs-consternation-among-devs/ (2026-05-30)
