Why our AI bill exploded when we moved off per-seat pricing

If your AI bill exploded when you moved off per-seat pricing, the cost driver is the shift in how you work. It shifted from headcount to a work pattern, and the work pattern changed in the same quarter. Seat pricing gave you a ceiling you could multiply out a year in advance. Usage pricing bills based on context size, agent step counts, and retries, none of which anyone tracked when the contract was signed.

What per-seat pricing was quietly doing for you

Seat pricing was a forecasting instrument disguised as a line item. Headcount times rate times 12, and the number you got was the worst case. You could take it to a board meeting and defend it without knowing anything about how anyone used the tool.

That’s the part teams miss when they move off per-seat pricing. The seat model wasn’t cheaper. It capped variance, and the cap did more work in your planning cycle than the rate did.

I’ve sat on the buying side of this. As a former CTO, I signed multi-year tool agreements where the entire finance conversation centered on the per-head rate, because it was the only variable. Nobody asked how the tool would be used, and that wouldn’t have changed the number.

What changed in the workflow at the same moment

Two shifts landed close enough together that most orgs experienced them as one event.

The first is agentic execution. A chat-style assistant answers a question and stops. An agent reads files, plans, edits, runs the test suite, reads the failure, and tries again. Each turn is a billable request with its own context.

The second is context size. Large context windows let you hand a model a whole repository, and handing a model a whole repository became the default because it’s the easiest thing to do. You pay for that context on every turn, not once per task.

Put those together, and one engineer working the way engineers now work generates a request volume unrelated to the seat they occupy. Same person, same desk, 50 times the consumption of the colleague next to them who’s still using tab completion.

Where the money actually goes

Four drivers, and, in my experience, they explain almost every AI bill that exploded after per-seat pricing.

Context per turn. The most expensive habit in the building is giving an agent the entire codebase for a task that touches three files. It costs more, and it often produces a worse patch because the relevant context is buried.

Turn count. A task that converges in 4 turns and one that loops 30 times before hitting a step cap can differ by roughly an order of magnitude on the invoice. If you haven’t set a step cap, you don’t have an upper bound.

Retry storms. An agent loop wrapped around a flaky test suite will retry with full context each time. This is the single most common cause of a spike that nobody can put a finger on at month-end, and it’s usually one repository doing it.

Model Teams point everything at the largest model available, including commit message drafting and lint fixes. Every provider publishes the rate difference between tiers on its pricing page, and almost no one compares it to their own task mix.

I’m not going to put dollar figures on any of that. I don’t have your provider’s contract, your negotiated rate, or your task mix, and a number I invented here would be worse than no number because you’d anchor on it. Take your provider’s published per-million-token rate, pull your usage export, and multiply it by your own consumption.

If the export doesn’t match the story finance is telling, get 20 minutes with us, and we’ll roast the numbers together.

Why the invoice arrives before anybody can explain it

The billing cycle and the engineering cycle run at different speeds, and that gap is where the panic lives.

Picture the meeting. A finance partner has the September invoice open on a laptop, three times the August figure, and she’s asking a reasonable question: what did we get for it? The staff engineer in the room knows exactly which two weeks caused it because he wired an agent into the migration work, saving the team a fortnight. He can say that. He can’t show it.

Nobody’s behaving badly in that room. The cost side has an instrument with daily granularity and the delivery side has an anecdote.

If you want the delivery side of that conversation measured over the same window as the invoice, connect a repository and the historical window scores in the first pass.

How to get an upper bound back without per-seat pricing

You can’t return to seat pricing, and you probably shouldn’t want to. You can rebuild the ceiling with four controls.

Step caps on every agent. A hard maximum on turns per task. This alone turns an unbounded workflow into a bounded one and exposes the tasks that really need more room, instead of hiding them inside a runaway loop.

Scoped context by default. Directory-level or package-level scope, with whole-repository context as an explicit choice somebody makes rather than the setting nobody changed.

Routing rules by task class. Cheap model for formatting, renaming, commit messages, and test scaffolding. Expensive model for design, debugging and anything touching a public interface.

Per-project budgets with account-level alerts. Not to block work. Make the spike visible the day it happens, not on the invoice five weeks later.

Those four give you a forecastable range. Finance wanted a range with stated assumptions based on per-seat pricing from the start.

What to measure on the other side of the bill

An AI bill, on its own, has only one available response: to cut it. To hold a renewal, you need the delivery figure for the same window, and it has to be the shipped value rather than the count.

Our own Q2 2026 study splits the change in performance per engineer into exactly two components, across 699 engineers and 137,592 qualifying commits in 65 public repositories across 6 organizations.

Components of the Q2 2026 change in performance per engineer

Year over year and quarter over quarter, 699 engineers, 65 public repositories

Grouped columns show commits per engineer up 14.9% year over year, while performance per commit rose 100.4%; quarterly figures were minus 11.2% and plus 32.4%, so the annual change reflects the value of each change rather than the count of changes.

Commits per engineer moved 14.9% year over year. Performance per commit moved 100.4%. Report token spend against commit volume, and you’re dividing a variable cost by the component that barely moved.

Two caveats travel with that, and I’d carry both into any meeting where you cite it. The study doesn’t quantify what share of the level shift, if any, was attributable to assistant adoption. And 21 of the 65 repositories are AI or agent SDKs whose category demand grew over the same window, so for those repositories, you can’t separate throughput per engineer from market growth.

What I’d do in the first week

Find every account that can consume tokens, including the one opened on a personal card during a spike. Set step caps. Turn on account-level alerts. Then run the delivery measurement backward over the same months the invoices cover, so the next time the bill moves, you have two lines on the same chart instead of one.

Talk to us if you’d rather have that second line before the next invoice lands.