On June 1, GitHub Copilot moved to usage-based billing, and the genuinely interesting thing about it is that, for a lot of people, the monthly number didn't move at all.

Copilot Business is still $19 per user per month. Copilot Pro is still $10. Pro+ is still $39. If you glanced at the pricing page and then closed the tab, you would conclude that nothing happened. But underneath that unchanged number, the thing the number buys has been quietly swapped out. Your $19 a month no longer buys "Copilot." It buys $19 of GitHub AI Credits — a balance, metered down by token consumption (input, output, and cached) at each model's published API rate. The subscription used to be a season pass. Now it's a prepaid debit card that happens to cost the same as the season pass did.

That sounds like a pedantic distinction. It isn't, and I want to walk through why.

What actually changed

The old model was premium request units — a coarse, countable bucket. You knew roughly how many "big" requests you got, and when you ran out, you were throttled. Crude, but legible. You could form a mental model of it.

The new model is token metering. As GitHub puts it, "usage will be calculated based on token consumption, including input, output, and cached tokens, using the listed API rates for each model." Each plan now ships with a credit allotment equal to its price — $19 of credits inside the $19 plan — and when that's gone, paid plans can buy more. Admins get budget controls at the enterprise, cost center, and user level. GitHub's own rationale is refreshingly plain: it "better aligns pricing with actual usage... and reduces the need to gate heavy users."

Read that last clause carefully, because it's the whole story. The flat-fee model was a subsidy with a ceiling. Light users overpaid; heavy users got throttled when they hit the wall. Usage-based billing removes the wall — and removes the subsidy. The heavy user is no longer gated; they're invoiced. The light user no longer overpays; they just consume less of a balance they've already bought. It is, in the most literal sense, fairer. It is also a transfer of cost variance from GitHub's balance sheet onto yours.

Here's the analogy I keep reaching for. A flat-rate buffet and a per-ounce salad bar can charge the same average customer the same money. But they are not the same product. At the buffet, your bill is fixed before you walk in, and the restaurant carries the risk that you're hungry today. At the salad bar, you carry that risk, and you find out what you owe at the scale by the register. Copilot just moved the scale to the register. Same food. Same average price. Completely different relationship to your own appetite.

Why this is a small-team problem specifically

If you're a large enterprise with a procurement team and a FinOps function, token metering is a Tuesday. You have people whose job is to watch meters. You've already lived through the cloud bill becoming a discipline.

Small teams have not. And small teams are exactly where this lands hardest, for a reason that has nothing to do with the total dollars and everything to do with predictability. A four-person shop can absorb a $19 line item forever because it's a known quantity — it goes in the spreadsheet once and never surprises anyone. A $19 line item that is actually a variable-consumption meter with a floor of $19 and no visible ceiling is a different animal. It's the difference between a fixed cost and a fixed minimum. You can budget the first one. The second one you have to watch.

I've written before that with these tools, you're often paying for a subsidy — and that the repricing event, when it comes, looks like a sudden hike but isn't. There's a quieter cousin of that: comfortable drift, the way teams accumulate pricing-surface exposure not through any single decision but through the gentle accretion of "sure, turn it on." Token metering is comfortable drift with the engine running. Every agent invocation, every "let it refactor the whole module," every overnight run you set up because the tooling finally made overnight runs trivial — each of those is now a line on the meter. The features that make the tool more capable are precisely the features that consume more credits. The product's improvement and your bill's growth are the same vector now. That coupling didn't exist under the flat fee, and it's the thing to actually internalize.

The thing to watch is the per-engineer meter

There's a second-order effect lurking here that I think is underdiscussed. Once consumption is metered and budgets can be set at the user level, you have built the substrate for individual cost accountability — a per-engineer productivity ledger, whether or not anyone calls it that.

That cuts two ways, and both ways are bad if you're not deliberate. If you set tight per-user budgets, you create adverse selection: an engineer watching their own credit balance will start reaching for the cheaper model on work that warranted the capable one, optimizing for budget conservation rather than task quality. They'll tokenmaxx — do the AI-assisted thing in the way that spends the fewest credits, not the way that produces the best code. If you set loose budgets and add a usage leaderboard "for visibility," you've built a consumption incentive, and consumption incentives reward the metric instead of the outcome. Either way, the meter starts shaping behavior, and the behavior it shapes is rarely "write better software."

What to actually do this month

I'm allergic to ending on dread, so here's the practical layer, none of it exotic:

  • Find out what you actually spent in May, in tokens. You can't manage a meter you've never read. Before you tune anything, get a baseline of real consumption per user. The number will surprise someone.
  • Set budgets as visibility, not as a leash — at first. Use the new enterprise/cost-center/user budget controls to observe for a billing cycle before you constrain. A budget set in ignorance is just a future incident.
  • Decouple "which model" from "whose budget." If individual engineers are watching their own balance, you've made model selection a personal finance decision. Centralize the model-choice policy so quality isn't quietly traded for credit conservation.
  • Treat the flat-fee floor as the floor it is. Your plan price is now a minimum, not a fixed cost. Re-line-item it in your budget as "AI tooling: $X floor, variable above." The honesty of that entry is worth more than its precision.
  • Audit the overnight and agentic runs. The unattended workflows that were free to leave running are now the highest-variance line on the meter. Not "turn them off" — "know what they cost."

The number on your Copilot invoice may not have changed on June 1. But if you're still treating it as a fixed cost, you're budgeting against a season pass you no longer have. What's the first metered line item that's going to surprise you — and would you rather find it in your own dashboard this week, or in the invoice next month?