The most useful thing GitHub Copilot's usage-based billing has done in its first four days is not lower anyone's AI spend. It is revealing, in exact dollar amounts, how little visibility developers have had into what they were actually doing.
On June 2, Visual Studio Magazine reported a developer who was facing a $180 bill for the month of June — on the first day of metered billing. They hadn't done anything unusual. They were coding the way they'd been coding all year. What changed was the accounting. The developer who burned 8% of their $39-per-month Pro+ credit allocation in two hours didn't suddenly become a heavier AI user. They became a measurable one.
GitHub Copilot switched from flat pricing to usage-based billing on June 1. Every plan now includes a monthly AI Credits allotment matching the plan cost, and code completions stay flat, but agentic sessions, multi-file chat, and code review consume credits at API token rates. One developer on Reddit reported that a Claude session to fix website issues cost 1,180 credits — roughly 16% of their monthly Pro+ allotment — for results they described as mediocre. At that burn rate, a $39 plan runs out in six days.
The developer community's reaction has been fast and predictable: anger, and migration planning. OpenRouter, Anthropic direct, OpenAI direct, RooCode, LM Studio — all seeing traffic from Copilot users who feel the switch was a bait-and-switch. "You will get less but pay the same price," as one developer summed it up to Visual Studio Magazine.
That framing is understandable and the frustration is fair. But it is not the most interesting thing happening here.
Flat Pricing Was a Measurement Amnesia Device
A $19-per-seat monthly fee was not a deal. It was a mechanism that made it impossible to distinguish high-value from low-value AI use.
When assistance costs a fixed amount regardless of consumption, there is no incentive to ask which sessions are productive. A three-minute chat that clarifies an unfamiliar API produces the same charge as a two-hour agentic session that fails to fix a database migration and requires a developer to spend another hour cleaning up after it. The cost signal is identical: zero, above the flat rate.
What flat pricing created was the illusion that all AI use was equally cheap, therefore equally worth doing. Usage-based billing breaks that assumption by making the cost of each session legible.
The developer who burned 16% of their monthly credits on a mediocre result could not have known, in a flat-rate world, that they had just consumed the equivalent of five days of AI budget on one ambiguous task. Now they know. The question that was previously invisible — is this particular session worth what it costs? — now has a number attached to it.
Where the Credits Are Actually Going
The expensive pattern is not small completions. Those are cheap. It is long agentic sessions on open-ended, underspecified problems.
This matches what usage analytics from the old premium request model consistently showed: the median developer interaction is inexpensive; the mean is pulled up by a small number of long sessions where a developer hands an agent an ambiguous task, the agent explores, generates extensive output, hits dead ends, and requires substantial correction to produce anything usable.
These sessions feel productive because there is a lot of activity. The agent is running, files are being touched, code is being written. The developer is doing real cognitive work — reviewing, redirecting, verifying. But the ratio of useful committed output to total tokens consumed is often very low, and under flat pricing that ratio was completely invisible.
Under usage billing, every one of these sessions has a line item. The developer who spent $6 on a single change request knows, for the first time, that they spent $6 on a single change request. Whether that was justified depends on what the change was actually worth — a question flat pricing never forced anyone to answer.
The sessions that will look worst in the first month of billing are not the ones you'd expect. They are the exploratory, open-ended agent runs that generated a lot of output and required a lot of steering. The sessions that will look reasonable are the focused, well-specified ones — where you handed the agent a clear task with clear acceptance criteria and it delivered.
That distinction existed before June 1. You just had no way to see it.
The Migration Won't Fix the Underlying Problem
The common migration target is Anthropic or OpenAI directly, via a managed proxy like OpenRouter. This makes sense as a cost optimization — direct API access can be cheaper than Copilot's credit model for heavy agentic usage.
But the visibility problem travels with you. Switching to OpenRouter does not give you a per-task cost breakdown mapped to your git history or PR cycle time. You will have a potentially cheaper API bill. You will not have any better answer to the question Copilot's billing just forced into focus: which AI sessions are producing value proportional to what they cost?
The information value of Copilot's billing change is precisely that it attaches a dollar amount to each session type. That is the mechanism that makes the ROI question concrete. Migrating to a cheaper provider to avoid that cost signal is solving the budget problem while discarding the diagnostic.
If you migrate, track your usage by session type at the new provider. The same pattern — expensive long sessions with low output ratios — will show up there too. Now you will have cheaper per-token rates and the same measurement gap.
Use the Shock as a Diagnostic
Before you migrate or cap your credits, run a few weeks of metered Copilot usage deliberately and look at what your consumption breakdown actually is.
Agentic sessions on ambiguous tasks will be the expensive outliers. The question to ask about each is not whether it was too expensive in the abstract — it is whether the output it produced justified the cost. Some of them will. An agent session that navigates an unfamiliar codebase and produces a fix you could not have written as quickly is worth real money. These sessions exist. They are not the problem.
The sessions worth cutting are the ones where the agent spent an hour generating code that required two hours of correction, on a task where the problem wasn't well-defined to begin with. You were running those sessions in the flat-rate world too. You just had no way to see them as distinct from the productive ones.
The developers who are going to get the most out of AI tools in the next year are not the ones who minimize credit spend or find the cheapest provider. They are the ones who use the cost signal to understand where AI is actually useful for their specific kind of work — and stop doing the expensive sessions that aren't.
The $180 bill on Day 1 is the worst-case outcome of the billing change. The best-case outcome is that you know, for the first time, what you have actually been spending AI on. That is worth more than a month of flat-rate credits.