Seat, Usage or Credit Pricing for an AI Product?

The problem classic SaaS pricing did not have

Traditional SaaS has close to zero marginal cost per user. Whether a customer logs in once a month or all day, your server bill barely moves, so charging per seat was safe.

AI features broke that. Every generation, summary and agent run costs real money, and usage is wildly uneven. In a typical twenty-seat account, two or three power users can account for most of the model spend. Charge per seat and those users are subsidised by colleagues who barely touch the feature. Charge nothing extra and a single enthusiastic customer can turn an account unprofitable within a month.

So the question is not which model is fashionable. It is which one keeps price and cost moving roughly together without scaring the buyer off.

Seat-based pricing: predictable, until it is not

Seats remain the easiest thing to sell. Finance teams budget for them, procurement understands them and there is no meter to argue about.

• Works when AI is a modest part of the product and usage per user is fairly even
• Needs a fair-use limit per seat, written clearly, or heavy users will eat your margin
• Struggles when AI replaces work, because customers buy fewer seats as it succeeds
• Hides your cost structure, which is comfortable right up until the model bill arrives

A seat price with a generous monthly allowance of AI actions, and a paid top-up beyond it, is a sensible default for many B2B products. It feels like seat pricing to the buyer and behaves a little like usage pricing for you.

Usage-based pricing: honest, and a little frightening

Pure usage pricing charges per unit consumed: per document processed, per thousand words generated, per minute of audio transcribed. It tracks your costs closely, and customers who get little value pay little.

The trouble is budgeting. A head of operations cannot easily approve an open-ended bill, and a buyer who fears a surprise invoice will quietly cap their team's use of the product. That undermines the adoption you need. If you go this way, give customers spend alerts, hard caps they control and a clear estimate before any large job runs.

The billing engineering is also heavier than it looks. Metering has to be accurate, idempotent and reconcilable to an invoice, which we cover in more depth in our piece on usage-based billing for SaaS.

Credit pricing: the compromise most AI products land on

Credits are prepaid units. The customer buys, say, 10,000 credits a month with their plan. A simple summary costs one credit, a long document analysis costs twenty, an agent run that touches three systems costs fifty.

This lets you price expensive actions differently without exposing token maths to the customer. It gives buyers a fixed monthly number, and it gives you room to change the credit cost of an action when your underlying costs change, within the terms you set.

Credits are a translation layer between what things cost you and what customers can reason about. Keep the translation simple or it stops translating.

The failure mode is complexity. If a customer needs a spreadsheet to predict their credit burn, you have rebuilt usage pricing with extra confusion. Keep it to a handful of action types, show the credit cost before an action runs, and let unused credits roll over for at least a month so nobody feels robbed.

Side-by-side comparison

How to choose, in order

1. Pull a month of real usage and cost per customer, not averages
2. Find the ratio between your heaviest and median user's AI cost
3. If that ratio is under about three, seats with a fair-use limit will probably do
4. If it is large and the cost-driving actions are few, use credits
5. If customers already think in units, like documents or minutes, use usage pricing with caps
6. Model each option against last month's customers before announcing anything

Step six is where most surprises surface. It is common to find that a credit model which looks tidy on paper would triple the bill of your three most loyal customers, because loyal customers are often the heaviest users. That is the kind of thing you want to discover in a spreadsheet, not in a renewal call. If you are changing pricing on an existing base, our notes on pricing changes without churn are worth reading first.

A word on cost engineering before pricing

Sometimes the right pricing answer is to make the product cheaper to run. Routing simple requests to a smaller model, caching repeated context and trimming prompts can cut the heavy-user problem down to something seat pricing absorbs. At SpiderHunts we usually look at cost per action before touching the price list, because a thirty per cent cost reduction is easier to ship than a new billing model. Our SaaS development work often starts exactly there.

Frequently asked questions