GitHub Copilot's Usage-Based Billing: A Builder's Cost Guide

What changed on 1 June

GitHub flipped every Copilot plan onto usage-based billing on 1 June 2026. It is the single biggest change to how Copilot is priced since the product launched, and it lands the way most metered-AI changes land: quietly in a changelog, loudly in the timelines of developers who only noticed when the billing model under their daily tool moved.

• Premium requests are gone. The premium request unit (PRU) — the thing Copilot used to ration — has been replaced by GitHub AI Credits from 1 June.
• Every plan now includes a monthly AI-Credit allotment. Paid plans can purchase additional usage once the allotment is spent.
• Usage is metered on tokens. Credits are drawn down on input, output and cached tokens, charged at the listed API rate for each model you call.
• Headline prices held. Pro is still $10/month, Pro+ $39/month, Business $19/user/month, Enterprise $39/user/month — but the number now buys credits rather than a fixed count of requests.
• Completions stay free. Code completions and Next Edit suggestions remain included in every plan and do not consume AI Credits.

The reaction was not warm. Visual Studio Magazine summarised the change as "you will get less, but pay the same price"; TechCrunch rounded up developer reaction under a "what a joke" banner. Whether that is fair depends entirely on how heavily you use the credit-consuming features — which is exactly why you need a cost model rather than a vibe.

What an AI Credit actually is

Conceptually, an AI Credit is a pre-paid unit of model spend. Instead of "you get 300 premium requests a month", the deal is now "you get a pool of credits a month, and each credit-consuming action draws from the pool in proportion to the tokens it processes". A short chat against a cheap model barely dents the pool; a long agent run that reads a large repository, reasons over it and writes a multi-file change against an expensive model draws far more.

Three properties matter for budgeting. First, cached tokens are billed — they are cheaper than fresh tokens but not free, so repeated context still costs you. Second, fallback experiences have been removed: when you are out of credits and have no budget headroom, the credit-consuming feature simply stops, rather than silently downgrading to a lesser model. Third, admin budget controls govern the ceiling, which is the lever that turns "usage-based" from a liability into something you can actually plan around.

This is the same metered shift sweeping the rest of the AI-coding market. We have already watched it play out in Cursor's move to usage billing on its PR-review and Bugbot tier, and the economics are converging across tools: you pay for tokens consumed, and the discipline of estimating tokens becomes a first-class engineering skill rather than a finance afterthought.

Before and after, plan by plan

The prices look identical on the pricing page. The substance underneath them is what moved. Here is the shape of the change across the four paid tiers.

Plan	Price (unchanged)	Before 1 June	After 1 June
Copilot Pro	$10/month	Fixed monthly premium-request quota	Monthly AI-Credit allotment; buy more if needed
Copilot Pro+	$39/month	Larger premium-request quota	Larger AI-Credit allotment; buy more if needed
Copilot Business	$19/user/month	Per-seat premium requests, admin policy	Per-seat AI-Credit allotment + admin budget controls
Copilot Enterprise	$39/user/month	Largest premium-request quota, org policy	Largest AI-Credit allotment + org budget controls

Across all four, two things are constant: completions and Next Edit suggestions stay included and unmetered, and anything beyond the included allotment is purchased usage on top. The question that decides your bill is no longer "which tier" — it is "how many credit-consuming tokens does my team actually burn".

How to model your real monthly cost

You were not given per-model credit prices in any announcement, and neither were we — GitHub publishes them per model, and they change. So do not chase a single magic number. Build a repeatable estimate instead. The method below works whatever the published rates are on the day you run it.

Step 1 — Separate free work from metered work

Pull a week of your own usage and split it in two: completions and Next Edit suggestions (free, ignore them for budgeting) versus agent runs, chat turns and any credit-consuming feature (metered, count these). Most individual developers are surprised by how much of their day is free completion — and how concentrated their metered spend is in a handful of long agent sessions.

Step 2 — Estimate tokens, not requests

For each metered action, estimate three numbers: input tokens (the context you send, including the slice of repository the agent reads), output tokens (what the model writes back), and cached tokens (repeated context across turns in a session). A long agent run over a large repo can be six figures of input tokens before it writes a line. Multiply each by the listed API rate for the model you are calling on the day, then sum. That is your credit draw for that action.

Step 3 — Multiply by frequency, then by team

Take your per-action draw, multiply by how often you run that action in a working day, then by working days, then by seats. This is where a usage-based bill diverges hard from a flat one: ten engineers each running twenty agent sessions a day against an expensive model is a materially different invoice from the same ten running two. Model your heavy users separately from your light ones rather than averaging.

Step 4 — Set the budget ceiling before, not after

Admin budget controls let you cap spend at a figure you choose. Set that ceiling to your modelled estimate plus a buffer, not to infinity. Because fallback experiences are gone, hitting the ceiling stops credit-consuming features cleanly rather than running up a surprise — which is the behaviour you want for a predictable monthly number.

Cached versus fresh, and when to lean on free completions

Two operational habits move the bill more than any plan choice. The first is watching the cached-versus-fresh token split inside a session. Cached tokens are billed at a lower rate than fresh ones, so an agent loop that keeps reloading the same context with no caching is quietly the most expensive way to work. Structuring a session so stable context is cached once and reused pays for itself on any sustained agent task.

The second is deliberately routing routine work to the free surfaces. Boilerplate, obvious completions, line-level edits — these are exactly what completions and Next Edit suggestions are for, and they cost nothing. Reserve the credit-consuming agent and chat features for work that genuinely needs reasoning over a lot of context. This is the same model-routing discipline we walked through for raw token economics in our Gemini 3.5 Flash cost-per-task breakdown: match the cheapest tool that does the job to the job, and only escalate when the task demands it.

It is also worth tracking which model an agent run lands on. As we noted when Cursor's Composer 2.5 reached parity with frontier models, a cheaper model that gets the task done in one pass can beat an expensive one that needs three. Under per-token billing, the model your agent selects is now a direct line item, not a quality preference.

What it means for Indian and UK teams

The dual-market sting is different on each side. For Indian startups, the obvious one is foreign exchange: Copilot bills in US dollars, and a usage-based invoice that flexes with token consumption is harder to forecast in rupees than a flat per-seat charge. A budget that looked comfortable can drift on FX alone, before a single extra agent run. Tighter runways make the case for hard admin ceilings and heavy use of the free completion surfaces even stronger — measure first, then cap, then let the team work inside the cap.

For UK teams, the friction is procurement and per-seat planning. Finance and procurement functions are built around predictable per-seat licences, and a metered line item that moves month to month complicates approvals and renewals. The honest answer is to present procurement with a modelled range — a floor (allotment only) and a ceiling (your admin budget cap) — rather than a single number, and to lean on the budget controls so the ceiling is a real, enforced figure rather than an aspiration. For larger orgs on Enterprise, model heavy and light users separately so the per-seat blended figure you take to finance reflects reality.

Both markets share the bigger picture: this is the metered-AI future arriving in the most widely used coding tool there is. We have written before about how parallel agents change the IDE itself in our piece on Cursor 3's parallel-agent paradigm — and the more agents you run in parallel, the more directly token discipline becomes a cost discipline. The teams that come out ahead are the ones that treat token estimation as an engineering practice now, while the change is fresh, rather than reverse-engineering it from an invoice later.

The bottom line

Strip away the reaction and the change is simple: Copilot moved from rationing requests to metering tokens, kept its sticker prices, and handed you budget controls to manage the difference. Whether that is a downgrade or a wash depends on your usage shape, not on the headline. Audit your free-versus-metered split, estimate tokens rather than requests, set an admin ceiling before the first invoice, and lean on the unmetered completions for routine work. Do that, and usage-based billing becomes a number you control rather than one that surprises you.