On 1 June 2026 GitHub moved Copilot to usage-based billing. The seat prices didn't move: Business is still $19 per user per month and Enterprise is still $39. What changed is underneath. Each seat now carries an allotment of AI credits, 1,900 a month on Business and 3,900 on Enterprise at a cent apiece, and those credits are spent by the token at each model's published rate. GitHub's explanation is the most useful sentence I've read about AI budgeting this year: under the old model, "a quick chat question and a multi-hour autonomous coding session can cost the user the same amount."

That used to be the vendor's problem to absorb. Now it's on your invoice. If your 2027 technology budget is being set this quarter, it's worth asking whether the AI line is still written in a unit that predicts the bill.

The seat price held. What the seat buys didn't.

For June, July and August, existing Business and Enterprise customers got promotional included usage: $30 a month per Business seat and $70 per Enterprise seat. September was the first month at the standard allotment. Same line on the invoice, 37% less included usage per Business seat and 44% less per Enterprise seat.

The credits are also pooled at the billing entity. A hundred Business seats make a shared pool of 190,000 credits, $1,900 a month. The seat count sets the size of the pool. It says nothing about who draws it down, or whether the draw is chat questions or agents running for hours. When the pool runs dry, an administrator chooses between two settings: keep going at published per-credit rates, or block usage until the next billing cycle. That's a budget decision. It now lives in a settings screen, and it has a default.

GitHub isn't unusual here. It's just unusually clear. The Gemini 3.8 Flash price I quoted in choosing the right model and effort for the job is introductory and doubles on 1 January 2027, the first day of any calendar budget year. Promotional allotments and introductory prices are line items with end dates now, and the end date is the part a seat-based forecast leaves out.

Where the overruns already land

The Futurum Group published survey results on 10 September 2026 from 1,636 enterprise technology decision makers. 46.9% said their actual AI spend is above plan: 35.6% moderately, 11.3% substantially. 31.8% are roughly on plan. 10% have no formal AI budget at all.

The number I'd look at twice is what happens next. Of the 767 organisations running over, 47.6% ask for more budget and 43.3% absorb the overrun and reconcile it later. Only 17.2% pause or reduce an AI initiative. The answers overlap, so they add up to more than a hundred, but the shape is clear: an overrun is mostly handled as a finance event after the fact, not as a decision about which piece of work was worth what it cost. That's what you'd expect when the unit the budget is written in, a seat or a department, isn't the unit that drives the cost.

A seat is a headcount. A job is a cost driver.

A seat budget is people times price times twelve. It's comfortable, because headcount is something finance already forecasts well. But the cost now moves with something else: how many times a piece of work runs, how many tokens each run takes, and the rate for the model and effort level it runs on. One seat can carry a developer who asks ten questions a day and another who hands an agent a migration on Friday afternoon. The seat price is the same. The draw on the pool isn't.

A job is the thing a finance partner can actually reason about. Triage every inbound support ticket. Pull the renewal terms out of every supplier contract. Review every pull request overnight. Draft the first version of every quarterly board pack. Each one has a volume you can count, a model tier and effort level someone chose or inherited, a cost per accepted result, and a person who answers for it.

What a job line looks like

I'd give every line six fields. The job, in words a finance partner can read without a glossary. Monthly volume, from last quarter's actual usage rather than a licence count. The model tier and effort level, written down so the next default change can't move it silently. Cost per accepted task, measured, because retries and rejected drafts are where the real spend hides. An owner. And the date anything about the price changes: a promotion ending, an introductory rate expiring, a model being retired.

The total is the sum of the jobs, plus one exploration line for work nobody has scoped yet, with a cap and a named owner of its own. Seats don't disappear from this budget. They become an input: the size of a pool that some of the jobs draw on, not the forecast itself.

The dates belong in the budget

Every dated price change is a point where the forecast should be checked against reality. GitHub's promotional allotment ended on 31 August. Gemini 3.8 Flash re-prices on 1 January. Claude Sonnet 4 and Opus 4 retired on 15 June, which I wrote about in every model you depend on has a sunset date. None of those were secret, and each one was easy to miss inside a total. Next to the job it affects, with its own date, it's hard to miss.

What I'd actually do before the number locks

Build the job list from last quarter's real usage, not from licences. Measure cost per accepted task for the five jobs that spend the most, because that's where a change in cost per task moves the total. Forecast agent work separately from chat work, even when both run on the same seat, because they're different cost shapes. Where a vendor gives you spend controls, set them deliberately. GitHub's run at enterprise, cost centre and user level, and the choice between continuing at published rates and blocking until next cycle deserves a decision per cost centre, not a default. Give each job an owner, so an overrun arrives as a question about that job rather than a variance on a spreadsheet. And put every dated price change in the budget as a re-forecast trigger.

The seat count will still be in next year's budget. It just stops being the forecast. A budget written as jobs can be argued with line by line. One written as seats can only be argued with as a total.

Sources, all read 6 October 2026: GitHub, "GitHub Copilot is moving to usage-based billing," 27 April 2026 (github.blog), for the 1 June change, unchanged seat prices, the promotional allotments for June to August, and the quoted rationale. GitHub Docs, "Usage-based billing for organizations and enterprises" (docs.github.com), for the 1,900 and 3,900 credit allotments, the one-cent credit, pooling at the billing entity, the budget levels and the two policies when the pool is exhausted. GitHub changelog, "Updates to GitHub Copilot billing and plans," 1 June 2026. The Futurum Group, "46.9% of Enterprises Report AI Spend Over Budget in 2H 2026," 10 September 2026 (futurumgroup.com), from its CIO and Technology Buyers survey. The Gemini 3.8 Flash pricing is from Google's launch post of 2 September 2026, as cited in the earlier article. The percentage reductions in included usage are my arithmetic from GitHub's figures. Plans and prices change often, so check the vendor pages before relying on them.

If you're setting next year's AI line this quarter and want a second reader to turn the seat count into a job list, that's a good half hour.

Book a discovery call Back to Thinking