What a per seat price hides

The pitch: one price, unlimited use

A per seat price is easy to sell and easy to buy. You pay a flat monthly fee per person, everyone on the team gets a login, and the invoice doesn’t change whether that person used the tool twice or two hundred times. Finance likes it because it’s predictable. Engineering managers like it because they don’t have to explain a variable API bill to anyone above them.

The problem is that almost nothing about how these tools actually run is flat. Every prompt you send hits a model that charges by the token on the backend, every completion streams back at a cost that scales with output length, and every agentic step that reads a file, greps a codebase, or calls a tool adds more tokens to the meter. The seat price is a wrapper around that variable cost, built by the vendor to average out across a population of users who don’t all use the tool the same amount. When you buy a seat, you’re not buying a fixed amount of compute. You’re buying a bet that the vendor made about how heavy your usage will be.

Most of the time that bet works out fine for both sides. Where it stops working is worth understanding before you’re the one who finds out the hard way.

Where the per-seat model breaks

Think about what a single heavy day of agentic coding actually costs on the API side. An agent that reads a few dozen files for context, plans a multi-step change, writes code, runs it, reads the error, and iterates can easily push several million tokens through a model in an afternoon, counting both the input context it re-reads on every turn and the output it generates. Priced at raw API rates, that’s real money, often more than a seat costs for the whole month. A vendor selling unlimited seats is counting on most people not doing that every single day. The engineer who treats an agentic assistant as a background process running constantly is the one who breaks the average the pricing was built on.

That’s not a flaw unique to any one product. It’s just what happens when a subscription business is built on top of a usage-based cost. Streaming services do the same thing with bandwidth, cloud storage providers do it with the users who never delete anything. AI tools just make the mismatch bigger because the underlying compute is so much more expensive than serving a video file.

The three things seat pricing usually hides

rate limits and quiet downgrades

The number that shows up on the pricing page is the seat price. The number that actually controls your experience is the request limit, the message cap, or the token allowance sitting underneath it, and that number is usually one click away from the pricing page instead of on it. When you cross it, you don’t always get a hard stop. Plenty of tools quietly reduce your priority in the request queue, switch you to a smaller model for a window of time, or shorten how much context gets included in each call. Your output quality drops and nothing in the billing tells you why. If you’ve ever noticed a coding assistant getting noticeably worse late in the day or after a heavy sprint, that’s usually not your imagination.

the definition of “a seat”

“Per seat” sounds like it means “per person,” but the fine print decides what actually counts. Some tools bill every named login whether or not that person opened the app that month. Others pool usage across the team and let any seat draw from a shared bucket, which is generous until one heavy user drains it for everyone else. A few charge per active seat, calculated on a usage window you don’t control, so a contractor who logs in twice a quarter can still trigger a full month’s charge. None of this is visible from the sticker price. It only shows up when you read the actual terms of service or, more commonly, when the invoice doesn’t match what you expected.

what happens past the fair-use line

“Unlimited” in a pricing table almost always means “unlimited, subject to fair use,” and fair use is defined by the vendor, not by you. That line exists because the vendor’s own API costs are real and someone has to absorb them when a user’s behavior stops looking like the average the plan was priced around. The catch is that fair use thresholds are rarely published as a hard number. You find out where the line is by hitting it, usually through a support ticket, a throttled response, or an account flag, not through anything in the docs.

Doing the math yourself

The only way to know if a seat is a good deal is to work backward from what you’re actually doing with the tool, not from what the seat costs. Pull up how you’d realistically use it in a normal week: how many substantial coding sessions, how long the context windows run, how much output you’re generating and re-generating through iteration. Rough that out in tokens, apply current published API rates for a comparable model, and compare that number to the seat price.

If your estimated usage sits well under the seat price, the flat fee is working in your favor and you’re effectively subsidized by lighter users on the same plan. If your usage estimate comes out close to or above the seat price, you’re the person the vendor is betting won’t show up every day, and you should expect to feel a rate limit or a quality dip eventually even if the plan is marketed as unlimited. This isn’t a benchmark or a test result, it’s just arithmetic you can run yourself with your own usage pattern and the API’s own published rates, and it’s worth doing before you commit a whole team to a plan.

When per-seat is actually the better deal

None of this means usage-based pricing is automatically better. Pay-as-you-go API billing puts the variance directly on you, and variance is its own cost when you’re trying to forecast a budget or explain a bill to someone who doesn’t want surprises. A seat price that includes a generous allowance can genuinely be worth paying extra for, because you’re buying predictability, not just tokens. It’s also worth remembering that a vendor pricing seats has to cover support, infrastructure, and product work on top of raw model cost, so a seat price above the pure token math isn’t automatically a rip-off. The question isn’t whether per-seat pricing is good or bad in general. It’s whether the specific allowance behind the specific seat price matches how your team actually works.

Teams with steady, moderate usage across a lot of people tend to do well on seat pricing, because the averaging works the way the vendor intended. Teams with a small number of very heavy users running long agentic sessions tend to do better on usage-based billing, because they’re not subsidizing anyone and they can see exactly what’s driving the bill. If your team has both kinds of user, a mixed setup, lighter roles on seats and the heaviest users on direct API access, often ends up cheaper and more transparent than forcing everyone onto the same plan.

What to check before you buy

Before you sign a team up for a per seat plan, find the actual allowance behind the price. Ask what happens when a user exceeds it: a hard stop, a downgrade, a queue, or a bill. Ask whether usage is pooled or per person, and whether inactive seats still get billed. And run the token math on your own heaviest user, not your average one, because that’s the person who’s going to tell you whether the plan holds up in month three instead of week one.

A flat number on a pricing page is a marketing decision, not a technical one. The technical reality is metered underneath it whether the vendor shows you the meter or not.

If you want more breakdowns like this on how AI tools actually price and perform once you look past the marketing page, check out the rest of AI Tool Gazette.