Per-seat pricing vs the inference bill: four AI pricing models, one decision framework
Two years ago, SaaS pricing was per-seat and procurement could model it. The arrival of inference as a cost driver broke that model. Every SaaS team shipping AI features now faces the same question: how do we charge for a feature whose cost scales with usage, in an industry whose revenue shape scales with seats? Four pricing models are now in production. Each suits a different cost and adoption profile. This piece names the models, states who each suits, and explains the procurement implications that come with each.
We are deliberately not publishing vendor price lists. List prices change quarterly; the model shapes do not. The model is what procurement and architecture teams should be reasoning about.
The four models
| Model | What the buyer pays | Vendor margin shape | Buyer risk |
|---|---|---|---|
| Per-seat (flat) | Fixed $/user/month | Vendor absorbs inference; margin shrinks as usage grows | None on cost; risk is vendor throttling usage |
| Seat + AI fee | Fixed $/seat, plus fixed $/seat/month AI add-on | Predictable; vendor wins if usage stays low | Paying for capability that may not be adopted |
| Credit pool | A block of credits per period; consumption-denominated | Vendor hedges between user variance | Credit exhaustion mid-period |
| Pure usage | $/token, $/request, $/task | Direct cost pass-through with margin | Bill volatility; hard to budget |
A fifth hybrid — seat for humans, usage for agentic traffic — is emerging but is not yet consistent across vendors.
Per-seat: still right for low-variance features
Per-seat survives where inference cost is a small, flat share of feature cost — summaries, drafts, field cleanup. Bounded cost per interaction, low variance between users.
Per-seat fails where usage varies wildly between users of the same tier. If one seat consumes 100x the inference of another, the heavy user is unprofitable. Vendors handling this either throttle silently (bad for buyers), or quietly switch the price model (worse).
Seat + AI fee: the enterprise default this year
A fixed add-on fee per seat per month is how most major SaaS vendors are pricing AI features in mid-2025. It converts an uncertain cost into predictable ARR.
For buyers, the model is easy to budget and easy to forecast adoption costs. The trap is paying for unused capability. If 30% of seats actively use AI features but the fee applies to 100% of seats, the effective per-active-seat cost is roughly 3x list. Procurement teams should negotiate the AI fee on the seats that will actually enable the feature, not the whole tenant.
Credit pools: cost control without line-item chaos
Credits translate many different AI operations (a summary, a translation, an agent step) into a single unit. The buyer buys a block; consumption draws from it.
This suits vendors whose AI spans multiple model tiers and task shapes — a credit abstracts “we do not want to publish 40 line items.” It suits buyers who want a spending envelope without per-request tracking.
The failure mode is opacity. Credit-per-operation mappings are vendor-defined and change. A buyer who does not instrument credit consumption per feature cannot answer “what is summarisation costing us?” from the credit ledger alone.
Pure usage: the honest model, the hardest to buy
Passing inference cost through at unit price plus margin is the cleanest economic model. It aligns vendor and buyer. It also terrifies procurement: bills can vary widely month to month, and forecast error lands on the buyer’s budget.
Pure usage suits technically mature buyers who instrument their own usage, and vendors whose customers can absorb variance. It does not suit teams selling into finance-led procurement.
Which model for which feature
The decision hinges on two properties: cost variance per user, and the buyer’s adoption risk.
| Cost variance | Adoption uncertainty | Best model |
|---|---|---|
| Low | Low | Per-seat |
| Low | High | Seat + AI fee on the subset of seats that enable it |
| High | Low | Credit pool |
| High | High | Usage, with a buyer-negotiated cap and alert threshold |
A vendor shipping both low-variance and high-variance AI features can end up combining models. That is a legitimate design, not a fudge — procurement should expect to see it.
Procurement implications that are not about price
Three non-price issues recur in AI addendum negotiations in 2025:
- Metering transparency. If the vendor charges usage, the buyer needs a consumption API — not a monthly PDF. Lack of a programmatic metering endpoint is a genuine blocker.
- Cost attribution. Enterprise buyers increasingly require usage to be attributable per team, per customer tenant, or per feature. Vendors who cannot provide this force buyers to rebuild attribution from logs.
- Model-tier disclosure. A vendor selling “AI credits” that silently route between cheaper and more expensive models is asking buyers to bet on their routing decisions. Contract language should specify what model families a credit buys.
What we would change in our own contract review
Before signing any AI feature addendum, a technical procurement review should demand: the metering granularity, the credit-to-model mapping (if credits), the per-seat applicability (if per-seat), the cap-and-alert mechanism (if usage), and the exit terms on price changes at renewal. These five items determine the effective commercial shape far more than the headline per-seat or per-credit figure.
The bottom line
There is no universal best model. The choice is a cost-variance problem, not a category-trend problem. Vendors optimise for their margin shape; buyers should optimise for the predictability and attribution they need. Where the two conflict, the model that surfaces its actual consumption data wins in the long run.