Most AI coding tools now bill on a hybrid: a seat price with an included allowance, then usage on top. The label on the plan tells you less than the shape of your team's usage does.
Why the distinction has narrowed
Pure seat pricing made sense when these tools did autocomplete. Consumption per developer was roughly constant, so a per-head fee tracked the underlying cost.
Agentic workflows broke that. When a tool plans, edits across files, runs tests and retries, one prompt becomes dozens of model calls. Consumption stopped being a function of headcount and became a function of how people work.
So every vendor now meters something. The real question is not which pricing model, but what proportion of your bill will be usage rather than seats — and that is decided by your team's distribution of use.
The distribution is the deciding variable
Two teams of twenty engineers can produce very different bills.
Even distribution. Everyone uses the tool for completions and occasional chat, nobody runs agents all day. Consumption is predictable, the included allowance mostly covers it, and the bill is essentially seats. Seat-dominated pricing is a good deal here — you get a cap.
Barbell distribution. Four engineers run agentic workflows constantly and consume enormous volume; twelve use it lightly; four barely touch it. Seat pricing overpays for sixteen people and undercharges for four, and the four will blow through any allowance. Usage-dominated pricing fits the reality better.
The barbell is far more common than teams expect, and it is invisible until someone looks at per-user consumption.
Work out which you are before choosing a plan. If your current tool reports per-user usage, sort it descending. If the top 20% account for most consumption, you have a barbell.
What seat pricing actually buys
Predictability. A known number times headcount. For finance this is worth real money in avoided variance.
No behavioural drag. Nobody hesitates to run an agent because they are thinking about cost. This matters more than it sounds — metered pricing quietly discourages exactly the usage you bought the tool for.
Simple administration. Adding a person is a known cost.
What it costs you is that light users subsidise heavy ones, and there is no signal when someone's usage becomes extreme.
What usage pricing actually buys
You pay for what you use. Light users cost almost nothing.
Visibility. Metered usage is measured usage. You can see who and what is consuming, which is the input to every optimisation.
Elasticity. A quiet month costs less.
What it costs you is variance, the administrative overhead of a bill that moves, and the risk that a runaway agent produces a surprise.
The hidden variable: model routing
Whichever you pick, the largest cost lever is usually not the plan. It is which model the tool routes to.
The price gap between a frontier model and a well-chosen smaller one is roughly an order of magnitude, while the benchmark gap on mechanical editing is a few points. A team defaulting everything to the largest available model is overpaying by a multiple, and no pricing plan fixes that.
If you only do one thing after reading this, check which models your coding tools actually call. It usually moves more money than the plan choice.
A practical way to decide
Measure current per-user consumption for a month. Most tools expose this. Sort descending.
Model both plans against that distribution. Seats times price, versus estimated usage at the metered rate.
Add a stress case. Assume agentic use doubles, because it has been doing so. A plan that only works at current volumes is a plan you will renegotiate.
Check the visibility each option gives you. A cheaper plan with no per-user reporting is more expensive the first time you need to explain an increase.
Whichever you choose, hold the number
The practical difficulty is that these tools sit alongside your direct API spend and your cloud bill, each in its own console, and nobody holds the combined developer-tooling figure.
StackSpend tracks Cursor, GitHub and the direct providers together, breaks usage down by model and user, and flags deviation against a per-service baseline — so a runaway agent is a same-day signal rather than a line on next month's invoice.
FAQ
Is per-seat or usage-based pricing cheaper for AI coding tools?
It depends on how usage is distributed across your team. Even, moderate usage favours seats; a small group doing heavy agentic work with everyone else light favours usage-based. Team size alone does not decide it.
Why has my AI coding tool bill grown without adding people?
Almost always increased agentic usage. Agents turn a single prompt into many model calls, so consumption scales with how people work rather than with headcount.
How do I forecast AI coding assistant costs?
Measure current per-user consumption, model it against the plan's rates, then add a stress case at double the agentic usage. Recent growth in agentic workflows makes the stress case the more realistic one.
Does model choice matter more than the pricing plan?
Usually yes. The price gap between frontier and smaller models is around an order of magnitude, which is a bigger lever than the difference between plans.
