Skip to main content

GitHub Copilot Switched to Token Billing in June. Some Teams Saw Their Bills Jump Overnight.

By Upendra

A meter dial pushed into the red zone representing spiraling AI billing costs

GitHub Copilot switched to usage-based billing on June 1, 2026. If your team didn't notice until the invoice arrived, you're not alone. This is the biggest change to Copilot's pricing model since launch, and the developer community's response was clear: over 900 downvotes and 400 comments on GitHub's own announcement thread in the first week.

Here's what actually changed, who got hurt, and what to do before next month's bill lands.

What the Old Model Was

The previous system used Premium Request Units (PRUs). Your plan came with a fixed monthly allotment. When you burned through it, Copilot didn't cut you off. It quietly fell back to a lighter base model. You kept working. You just didn't know you'd dropped to a less capable model. That was a reasonable trade-off for predictability.

That safety net is gone.

The New Model: AI Credits

Every plan now ships with a monthly AI Credits allowance. One credit costs $0.01. The plan prices didn't change, but now each plan comes with a defined credit budget:

  • Pro ($10/month): 1,500 credits
  • Business ($19/user/month): 1,900 credits per user
  • Enterprise ($39/user/month): 3,900 credits per user
  • Pro+ ($39/month): 7,000 credits

GitHub also added a new Copilot Max plan at $100/month aimed at heavy agentic users.

Code completions and Next Edit suggestions remain free. They don't consume any credits. The metering kicks in for Copilot Chat, Agent mode, code reviews, and anything that routes through a frontier model. The billing is token-based: input tokens, output tokens, and cached tokens, each priced per the model in use.

Where the Bills Are Exploding

Agentic usage is where the math breaks down for teams that weren't paying close attention.

A quick chat question and a multi-hour autonomous coding session no longer cost the same, which is fair. The problem is that most teams didn't know what kind of sessions their engineers were actually running.

A single complex agentic task on Opus 4.8, with real context length and multiple tool calls, can burn $0.50 to $2.00 of credits. Do that five times in a day and a Business plan user has already blown past their monthly allotment by day two. No warning, no fallback. Just overage charges.

The reports on GitHub's community thread are consistent: bills jumping from $29 to $750/month, from $50 to $3,000. These aren't edge cases. These are teams that leaned into agentic coding, the exact behavior GitHub has been pushing developers to adopt for the past year.

The Backlash Is Understandable, But GitHub Isn't Wrong

Over 900 downvotes make the frustration legible. But I think the underlying move is correct. Infinite agentic inference at a flat subscription price was never going to hold. Running a multi-hour Opus session against a large codebase costs real money to serve. The old model was cross-subsidizing heavy agentic users, and something had to give.

What GitHub got wrong is the communication. They framed this as "more transparency into your usage" when it was really a price increase for power users. Enterprise teams got minimal lead time to audit their actual usage patterns before the change took effect. That's a legitimate complaint.

I haven't run this across a large org, but my take is: if your team is doing mostly inline completions with occasional chat, the included credits are fine. You'll likely never hit the cap. For teams running agent-heavy workflows, this is now a real line item on your AI infrastructure budget.

What to Do This Week

Set spending limits first. GitHub added per-user budget controls and org-level spending caps. Configure both before anyone runs another agentic session. The setting lives in your GitHub organization billing settings under Copilot. Set hard stops, not just alerts.

Audit actual usage. Copilot's dashboard now shows model-level breakdowns. Pull the last 30 days and look at which models are being used and in what context. If the majority is Agent mode on Opus, you're burning credits fast.

Run the Max plan math. If you have engineers doing agentic work daily, the Max plan at $100/month may come out cheaper than overages on a Business plan. Model the actual usage, not the allotment.

Model-match your tasks. Copilot lets you configure which model backs each feature. Dropping from Opus 4.8 to Sonnet 4.6 for standard chat and code review cuts your per-token cost significantly with comparable results on most everyday coding questions. Reserve the top-tier model for tasks that genuinely need it.

The broader signal here is that AI product pricing is entering a second phase. Flat-rate subscriptions made sense when usage was predictable and inference was cheap. Agent workflows broke both of those assumptions. Copilot is the first mass-market developer tool to formally move to token economics. It won't be the last.

Labels:

Comments

Post a Comment

Popular posts from this blog

AngularJs call one method of controller in another controller .

By Upendra
I have seen many question about calling one method of one controller in another controller or extending scope of one controller in another controller.so here are the ways. if you want to call one controller into another or extending scope of controllers there are four methods available $rootScope.$emit() and $rootScope.$broadcast() If Second controller is child ,you can use Parent child communication . Use Services Kind of hack - with the help of angular.element() 1. $rootScope.$emit() and $rootScope.$broadcast() Controller and its scope can get destroyed, but the $rootScope remains across the application, that's why we are taking $rootScope because $rootScope is parent of all scopes . If you are performing communication from parent to child and even child wants to communicate with its siblings, you can use $broadcast If you are performing communication from child to parent ,no siblings invovled then you can use $rootScope.$emit HTML <body ng-app = ...
7 comments
Read more

Closures in javascript and how do they work ?

By Upendra
JavaScript Closures for Dummies  Closures Are Not Magic This page explains closures so that a programmer can understand them — using working JavaScript code. It is not for gurus or functional programmers. Closures are  not hard  to understand once the core concept is grokked. However, they are impossible to understand by reading any academic papers or academically oriented information about them! This article is intended for programmers with some programming experience in a mainstream language, and who can read the following JavaScript function: function sayHello ( name ) { var text = 'Hello ' + name ; var sayAlert = function () { alert ( text ); } sayAlert (); } An Example of a Closure Two one sentence summaries: a closure is the local variables for a function — kept alive  after  the function has returned, or a closure is a stack-frame which is  not deallocated  when the function returns (as if a 'stack-fr...
Post a Comment
Read more

Working with $scope.$emit , $scope.$broadcast and $scope.$on

By Upendra
First of all, parent-child scope relation does matter. You have two possibilities to emit some event: $broadcast  -- dispatches the event downwards to all child scopes, $emit  -- dispatches the event upwards through the scope hierarchy. If scope of  firstCtrl  is parent of the  secondCtrl  scope, your code should work by replacing  $emit  by  $broadcast  in  firstCtrl : function firstCtrl ( $scope ) { $scope . $broadcast ( 'someEvent' , [ 1 , 2 , 3 ]); } function secondCtrl ( $scope ) { $scope . $on ( 'someEvent' , function ( event , mass ) { console . log ( mass ); }); } In case there is no parent-child relation between your scopes you can inject  $rootScope  into the controller and broadcast the event to all child scopes (i.e. also  secondCtrl ). function firstCtrl ( $rootScope ) { $rootScope . $broadcast ( 'someEvent' , [ 1 , 2 , 3 ]); } Finally, when you need to ...
Post a Comment
Read more