Per-Seat vs Per-Token Pricing: Which One Fits Your Team

Two pricing shapes dominate AI tooling. One charges per person per month regardless of what they do. The other charges per token regardless of who sent it. Almost every vendor is some variation on those two, and the variation matters less than which of the two you are actually on.

The mistake is treating this as a procurement question about unit price. It is a question about the shape of your usage curve, and the two shapes fail in opposite directions.

What each price is actually metering

A per-seat price meters headcount. It assumes that a person is a reasonable proxy for consumption — that a developer with a licence uses roughly what another developer with a licence uses, and that the vendor can average across a population and still make margin.

A per-token price meters work. It makes no assumption about who is doing it. A cron job and a senior engineer are the same customer to a metered API, which is precisely why metering scales to workloads that have nothing to do with people at all.

That difference explains most of what follows. Per-seat is a bet that usage correlates with headcount. Per-token is a bet that it does not, and prices accordingly.

What per-seat optimises for

Per-seat pricing buys predictability, and predictability is worth real money to the person who owns the budget line. You know next quarter's bill the moment you know next quarter's hiring plan. Finance can approve it once and stop thinking about it.

It also removes the meter from the developer's field of view, and that second-order effect is larger than most teams expect. When usage is not visibly charged, people stop rationing. They let an agent explore. They run the eval set a hundred times instead of arguing about whether it is worth it. They paste in the whole file instead of the function they think is relevant, which produces better answers.

Under metered billing every one of those decisions carries a small tax, and developers respond to taxes. Cutting context to save tokens is a rational response that reliably makes output worse. Per-token vs flat-rate pricing works through that behavioural cost in more detail.

What per-token optimises for

Per-token pricing is honest about the underlying cost structure. Inference genuinely costs more when you use more, and a metered price passes that through without cross-subsidy. If you use very little, you pay very little — no minimum, no unused licences, no true-up.

It also decouples spend from headcount entirely, which is what you want for anything automated. A pipeline that classifies support tickets has no seats. A CI job that reviews pull requests has no seats. Trying to price those under a per-seat model produces absurdities like buying a licence for a service account.

And metering gives you a lever. Every optimisation — shorter prompts, cached prefixes, a cheaper model for the easy 80 percent — shows up on the invoice next month. Under per-seat, the same work shows up nowhere.

The workload each one punishes

Per-seat punishes small teams doing heavy automated work. Three engineers running a large agent fleet pay for three seats and consume like thirty, which sounds like a win until the vendor notices and imposes fair-use limits, at which point you discover the flat rate had a cap in it all along. Is unlimited AI actually unlimited covers how those caps usually work.

It also punishes large teams with a long tail of light users. If half your licences belong to people who open the tool twice a month, you are funding the heavy half through the light half, and the effective rate for the light half is terrible.

Per-token punishes uneven usage, and specifically it punishes agents. Models are stateless, so every turn resends the whole conversation, and input tokens grow roughly with the square of turn count. A single instruction becomes dozens of requests each carrying everything before it. That is why per-token bills for agentic work land nothing like the estimate, and why agent costs are unpredictable is a category of its own rather than a forecasting failure.

Modelling both against your own curve

Do not compare list prices. Compare distributions.

Pull thirty days of usage and produce tokens per user per month, not the mean but the full spread. You are looking for the p50 and the p90. Multiply the p50 by your metered rate and compare it to the seat price: that tells you what the median user costs under each shape. Then multiply the p90 and compare again. If the p50 comes in well under the seat price and the p90 comes in well over, you have a population that per-seat is subsidising in one direction and taxing in the other.

The second number that decides it is the ratio between them. A team where p90 is twice p50 is predictable enough that metering is fine — you can forecast it and the variance is manageable. A team where p90 is fifteen times p50, which is common once agents are in the mix, is a team that will keep being surprised by metered invoices no matter how carefully it forecasts. Forecasting AI spend goes into how to build that projection.

Third, count the seats that would exist purely to hold a licence. Service accounts, CI runners, shared bots. If that count is material, per-seat is already the wrong shape regardless of the arithmetic.

Hybrids and where they leak

Most vendors now ship a hybrid: a seat price with an included allowance, then metered overage above it. This is usually the honest version of both models, because it charges for the population average and passes through the tail.

The leak is in how the allowance pools. An allowance that pools across the account absorbs individual spikes and behaves like a flat rate for most teams. An allowance that is strictly per seat means your one heavy user goes into overage while nine unused allowances expire, and you get the worst of both shapes at once. Ask which it is before signing anything, and see how caps and overages are designed for what to look for.

Flat-rate managed access, including what we sell at ProjectCOZY, is the far end of this spectrum: predictable per-person cost, no meter in the developer's eyeline, and correspondingly less useful if your load is a batch pipeline rather than people.

A decision rule

If your usage is dominated by people doing interactive work, and the p90 to p50 ratio is wide, take the per-seat or flat-rate shape. You are buying variance reduction and the removal of a behavioural tax, and both are worth more than the few percent you might save on unit price.

If your usage is dominated by automation, or if it is genuinely spiky across months, take per-token. Seats are the wrong unit for work that has no people in it, and metering rewards the optimisation work you are going to do anyway.

If you cannot tell which you are, you do not have the instrumentation yet. Start by attributing spend per user and per workload for a month — attributing agent costs covers the mechanics — and let the distribution answer the question rather than the sales deck.