AI Coding Assistant Pricing — Per Seat vs Usage-Based

AI coding tools have settled into two pricing shapes, and they fail in opposite directions. Choosing the wrong one rarely shows up in the first month. It shows up in the third, when either finance asks why you are paying for twelve seats that four people use, or when a single ambitious refactor produces a bill nobody budgeted for.

Per seat: predictable, frequently wasted

Editor-based assistants — Cursor, Copilot, Devin Desktop (formerly Windsurf) — almost always price per developer per month. The appeal is obvious. You multiply headcount by a number and that is the line item. Procurement understands it, it does not fluctuate, and nobody has to explain a spike.

The waste is equally predictable and much less discussed. Assistant usage inside a team is never evenly distributed. A minority of developers use it constantly, a larger group uses it occasionally, and some quietly stop within a month while the seat keeps billing. Unless you check actual usage rather than assigned licenses, per-seat pricing bills you for enthusiasm you do not have.

The fix is unglamorous: review seat utilisation quarterly and reclaim the dormant ones. Most teams never do this, which is precisely why per-seat pricing is attractive to vendors.

Usage-based: honest, harder to forecast

Agent-style tools — Claude Code, Codex — generally bill by consumption rather than by head. The logic is sound. An agent working autonomously through a large refactor consumes vastly more than someone accepting occasional completions, and charging both the same would either overcharge the light user or undercharge the heavy one.

The advantage is that cost tracks value. If nobody delegates anything this month, you pay close to nothing. The disadvantage is that a single motivated engineer discovering they can hand over an entire migration will produce a number that has no relationship to last month's.

This is manageable, but only if you manage it. Set spending limits before rollout rather than after the first surprise. Make the cost of a delegated task visible to the person delegating it — engineers make sensible decisions when they can see the meter, and wildly unsensible ones when they cannot.

Which model suits which team

If your usage is broad and shallow — most developers, most days, mostly completion — per seat is almost certainly cheaper and definitely calmer. The predictability is worth a modest premium.

If your usage is narrow and deep — a few engineers occasionally handing over large structural work — usage-based is dramatically cheaper. Buying twelve seats so that three people can run a quarterly migration is a poor trade.

Many teams end up with both, and that is a legitimate outcome rather than a failure of discipline: per-seat for everyday editing across the team, usage-based for the smaller group doing heavy structural work.

The costs that are not on the pricing page

Two line items get missed consistently.

The first is review time. An assistant that produces a large volume of plausible code shifts effort from writing to reviewing. That is usually a good trade, but it is not free, and it lands on your most senior people — the ones whose time is most expensive.

The second is switching cost. Adopting an AI-native editor means the team leaves an environment they have configured over years. That cost is real, one-off, and almost never modelled. It is also the single most common reason a promising trial quietly dies.

Before you sign

Run a two-week trial with a spending cap and measure actual usage rather than reported enthusiasm. Check whether the vendor charges differently for the models behind the tool — several pass through model costs, which means your bill moves when their upstream pricing moves. And confirm what happens at renewal, since introductory rates in this category have been unusually short-lived.

To weigh cost against how autonomous you actually need the tool to be, the AI Coding Assistant Finder scores both together.