How to price AI features in your SaaS without rebuilding it later

Every guide to AI pricing hands you the same menu. Per seat. Per credit. Per token. Per outcome. Pick one, the article says, and the margin problem is solved.

The menu is not the hard part. A pricing model is a promise about what you can measure, and most SaaS products cannot keep that promise. You can decide on Monday to charge per resolved ticket, then discover on Tuesday that nothing in your codebase knows which customer triggered which model call, what that call cost, or how to stop it when an account runs away. The pricing page changes in an afternoon. The system underneath it takes a quarter.

So the useful question is not which of the 5 models is best. It is which models your product is currently allowed to have, and what you would need to build to unlock the others. Price at the wrong altitude and you will reprice twice: once when the margin bleeding shows up in the board deck, and again after the rebuild you did not budget for.

This is written for founders, CTOs, and product leaders at B2B SaaS companies that already have paying customers, and are now bolting AI onto a product that was priced back when serving one more request cost nothing. If you are pre-launch and picking a number for a pitch deck, this is more detail than you need.

In this article you will learn why AI breaks the pricing assumptions your product was built on, the 4 capabilities that decide which pricing models are actually available to you, what each of the 5 common models demands from your code, a worked example with real numbers, and the order to build it in so you only do this once.

‍

Key takeaways

• Your pricing model is an architecture decision. You can only charge for what your product can measure, attribute, enforce, and explain.

• AI product gross margins sit near 53% in 2026 against 80% to 90% for classic SaaS, so the old flat-rate maths does not carry over.

• The dangerous failure is not a big bill. It is a slow, invisible margin drift you cannot attribute to any specific customer.

• Build 4 capabilities first: cost attribution per call, metering per tenant and feature, enforcement at request time, and margin telemetry you can query.

• Every pricing model has a code prerequisite. Outcome-based pricing needs all 4 capabilities plus an agreed definition of the outcome.

• Start on the rung your code can already support, ship it, then move up. A metered model you cannot enforce is worse than a flat plan you can.

• Caps belong in the request path, not in the invoice. An overage you discover at month end is a loss you already took.

‍

Why AI features break the pricing model

Classic SaaS pricing rests on one quiet assumption: the marginal cost of serving one more user, or one more action, rounds to zero. That assumption is what makes per-seat pricing work. It is why unlimited tiers are safe, why your heaviest users are your most profitable, and why a support rep can hand out a trial extension without asking finance.

AI removes the assumption. Every summary, every extraction, every agent run has a real compute cost that lands on your bill whether the customer found the output useful or not. The economics invert. Your power users, the ones your whole retention story depends on, become your most expensive accounts. The customer who logs in daily and runs the AI feature on everything is simultaneously your best case study and your worst margin.

The numbers bear this out at the category level. ICONIQ's 2026 State of AI report puts average gross margins for AI products at 45% in 2025, rising to a projected 53% in 2026 and 59% in 2027. Bessemer's AI pricing and monetization playbook, published in February 2026, frames the same gap more bluntly: 50% to 60% gross margins for AI companies against 80% to 90% for traditional software. Those margins are improving as routing and caching mature, but they are not going back to 90%.

Here is the part that catches teams out. The damage does not arrive as a shocking invoice. It arrives as drift. Your blended gross margin slips 2 points one quarter and 3 the next. Nobody can point at the cause, because a flat per-seat plan deliberately averages every account into one number. By the time someone asks which customers are unprofitable, you have a year of contracts priced on maths that stopped being true.

The teams that handle this well are not the ones who picked the cleverest model. They are the ones who could answer "which accounts are underwater and by how much" in about 30 seconds.

‍

The real constraint

Pricing advice usually treats model selection as a strategy exercise. Study the customer's value metric, align price with value, choose accordingly. That is sound reasoning and it is where most articles stop. It also assumes your product can execute whatever the strategy concludes, and that assumption is usually false in a codebase older than the current model generation.

A pricing model is a set of claims your system has to be able to back up. Charge per credit and you are claiming you can count credits accurately, per tenant, in near real time, and refuse the next request when the balance hits zero. Charge per outcome and you are claiming you can detect the outcome, prove it happened, and defend that count when a customer disputes the invoice. None of that is a pricing decision. It is all engineering.

The pattern we see repeatedly in AI builds looks like this. A team decides on credits. It seems simple enough, a counter and a balance. Then the audit starts. Model calls turn out to be made from 6 different places: the web app, two background workers, a webhook handler, an internal admin tool, and a nightly batch job somebody wrote 2 years ago. Three of those have no user or tenant context attached to the request at all, because when they were written nothing downstream needed it. Cost cannot be attributed to an account because the information was never carried that far. What looked like a pricing change becomes a refactor across half the services.

That is the whole insight. You can only charge for what you can measure, attribute, enforce, and explain. Four verbs, and every pricing model needs some subset of them.

• Measure: you know the token or compute cost of an individual operation.

• Attribute: you can tie that cost to a specific tenant, user, and feature.

• Enforce: you can refuse or throttle the next request when a limit is reached.

• Explain: you can show a customer a line-item breakdown they will accept.

Miss any one of them and a pricing model that looked fine on a slide becomes unbillable, unenforceable, or indefensible in a renewal conversation.

‍

The 4 capabilities that decide your pricing options

These are the concrete things to build. None of them are exotic, and all of them are far cheaper to add before an AI feature ships than after 600 accounts are using it.

‍

‍

1. Cost attribution on every model call

Every call to a model should return, and store, what it cost. Not an estimate derived monthly from your provider invoice, but the actual input tokens, output tokens, model name, and computed cost recorded at the moment of the call, alongside the tenant id, user id, feature name, and request id.

This sounds obvious and it is very often missing. Teams log that a call happened and whether it succeeded. They do not log what it cost, because at prototype stage nobody was paying attention to the bill. Retrofitting this is the single highest-leverage day of work in the whole exercise, and it is usually a wrapper around your model client plus one table.

The detail that matters: attribute at the point of the call, not at the point of the user action. One user action can fan out into 9 model calls across a retry, a re-ranking step, and a validation pass. If you only record the user action you will understate real cost by a factor you will not discover until the provider invoice disagrees with you.

‍

2. Metering per tenant and per feature

Attribution gives you rows. Metering turns those rows into a running balance you can act on: this account has consumed this many units of this feature in the current billing period.

Two decisions shape everything downstream. First, pick a unit the customer can understand. Tokens are the wrong unit to expose, because no buyer has an intuition for what 40,000 tokens means or any way to predict their own consumption. A document processed, a ticket resolved, a report generated, a call transcribed: those are units a customer can forecast and budget for. Meter internally in tokens, bill in work units.

Second, meter per feature, not just per account. An account total tells you an account is expensive. A per-feature breakdown tells you the AI clause summary is 80% of the cost while producing 10% of the engagement, which is the sentence that actually changes a roadmap.

‍

3. Enforcement at request time

This is where most implementations stop short, and it is the one that costs money. A limit that is checked when you generate the invoice is not a limit. It is a report of a loss you already took.

Enforcement means the check happens in the request path, before the model call, and it can refuse. That requires the running balance to be fast to read, which usually means a cache in front of the ledger rather than a query across a month of usage rows on every request.

It also requires you to decide, in product terms, what happens at the limit. Hard stop with a clear message. Degrade to a cheaper model. Queue until the next period. Auto-purchase another block if the customer opted in. All are reasonable. Silently continuing and eating the cost is the only one that is not, and it is the default when nobody makes the decision.

Worth designing in from the start: the customer should be able to set their own cap below yours. Buyers are far more willing to accept usage-based pricing when they control the ceiling, because their real fear is not the price per unit, it is an unbounded bill.

‍

4. Margin telemetry you can query

The last capability is for you, not the customer. You need to answer, without a data project, which accounts are unprofitable this month, which features are dragging the blended margin, and how cost per work unit is trending as you change models and prompts.

The practical version is a single view joining usage cost to contract revenue per account per month, and a small dashboard on top of it. Cost per work unit deserves particular attention over time, because it is the number that tells you whether your engineering work on caching, routing, and prompt size is actually paying off, or whether you just moved cost around.

If you want the broader cost picture underneath all this, our breakdown of what it really costs to run an AI agent covers the components that show up in these numbers.

‍

Working through this for your own product? Our SaaS AI Blueprint walks through the same architecture and cost decisions as a build checklist you can take to your engineering team.

‍

The 5 AI pricing models and what each one demands from your code

With the capabilities framed, the model comparison becomes a lot less abstract. Each row below is a real prerequisite, not a preference.

‍

‍

Included in the plan

The AI feature is simply part of the tier, at no separate charge. It is the fastest route to market and the right call when the feature is a retention play or a competitive checkbox rather than a revenue line, and when usage is genuinely light and predictable.

It needs the least: attribution and telemetry, so you can watch what it costs you. It carries the most risk, because you have no mechanism to stop an account that decides to run the feature across their entire back catalogue. Include it only with a quiet internal cap and an alert when an account crosses it.

‍

Seat plus AI add-on

A flat monthly uplift per seat for access to the AI features. Commercially it is the easiest sell, because it preserves the predictability your buyers already signed up for, and it lets you raise price without renegotiating the pricing model.

The economics only work if usage per seat is reasonably tight. When your heaviest 5% of seats consume 30 times the median, a flat uplift is a flat rate priced for the median that gets consumed by the tail. Pair it with a fair-use ceiling you can actually enforce.

‍

Credits or a usage pool

Customers buy a block of units, in the plan or on top of it, and spend them down. This is the most popular middle ground for good reason: the customer gets a bounded, predictable number, and you get consumption that tracks cost.

It needs all 4 capabilities, and it needs a credit that maps to something a buyer understands. The most common mistake is defining a credit as a token count, which hands the customer a unit they cannot forecast. Define 1 credit as 1 document processed and adoption gets easier immediately.

‍

Metered usage

Pay for exactly what you consume, billed in arrears. It aligns revenue to cost more tightly than anything except outcome pricing, and it scales cleanly with your largest customers.

The friction is commercial, not technical. Procurement teams dislike unbounded line items, and a variable bill makes your revenue harder to forecast too. In practice almost nobody runs pure metering. ICONIQ found companies blending 1.7 pricing models on average, and consumption-based pricing climbing from 35% to 42% of companies in 6 months. The usual shape is a committed base plus metered overage, which is why hybrid has become the default answer.

‍

Outcome-based

You charge per result: a resolved ticket, a qualified lead, a successfully processed claim. It is the most compelling story you can tell a buyer, because they are paying for the thing they wanted rather than the compute that produced it. ICONIQ shows adoption rising from 18% to 23%, so it is real and growing, though still a minority.

It is also by far the most demanding. You need all 4 capabilities, plus reliable detection of the outcome, plus a definition of success that survives a dispute. When a ticket gets resolved and reopened 2 days later, did you earn the fee? That question needs an answer in the contract before it needs one in the code, and getting it wrong turns every invoice into a negotiation.

‍

A worked example

Numbers make this concrete. Take a contract management SaaS with 600 customer accounts on a $79 per seat plan, averaging 7 seats per account, so roughly $553 in monthly revenue per account. Serving costs before AI ran around $55 per account, a comfortable 90% gross margin.

They add an AI clause summary. Each summary sends about 12,000 input tokens and returns about 900 output tokens. At roughly current mid-tier model rates, that is around 5 cents per summary, all in.

Then the usage distribution shows up, and it is not normal. The median account runs 40 summaries a month, which costs $2. Margin moves from 90% to 89.6%, invisible. The top 5% of accounts run about 1,900 summaries a month. That is $95 of compute on top of $55 of existing cost, against $553 of revenue, so that account has quietly gone from 90% to 73% margin. A handful of accounts run 6,000 or more, at roughly $300 of compute, landing them near 36%.

Blended across the base, the reported gross margin falls about 4 points. On a flat plan there is no line item anywhere that says why, and no mechanism that would have stopped it.

Now price it with the capabilities in place. Include 50 summaries per account per month in the existing plan, which costs about $2.50 and covers the median user completely, so most customers see no change and no new friction. Above that, charge $0.15 per summary, roughly 3 times cost, and let each customer set their own monthly ceiling with a sensible default.

The heavy account that was destroying margin now generates 1,850 chargeable summaries at $0.15, which is $277.50 of additional revenue against $95 of cost. It moved from your worst margin problem to your best expansion account, and nothing about the product changed. The only difference is that the system could count, attribute, and stop.

Notice what made that possible. Not a clever pricing model. A ledger, a balance, and a check in the request path.

‍

The pricing ladder: start where your code is and earn your way up

You do not have to arrive at the sophisticated model immediately, and trying to usually goes badly. A metered model you cannot enforce is genuinely worse than a flat plan you can, because it creates a customer expectation of variable billing without the machinery to bill fairly or stop runaway usage.

A sane progression looks like this. Ship the feature included in the plan, with attribution and telemetry running from day one and a quiet internal cap. Watch real usage for 60 to 90 days, because your assumptions about the distribution will be wrong and the tail is where the money is. Once you have data, introduce an add-on or an included allowance with a visible, enforced fair-use limit. When usage variance justifies it, move to credits or committed-plus-overage, priced from your observed cost per work unit rather than a guess. Only then consider outcome pricing, and only where the outcome is unambiguous and machine-detectable.

Each rung requires the one below it to be working. That is the useful part of thinking about it as a ladder rather than a menu: it tells you what to build next, and it stops you from committing publicly to a model your system cannot honour yet.

‍

‍

How we approach the metering layer

When we build AI features into an existing product, the metering layer goes in before the feature ships, not after. In practice that means a thin wrapper around every model client that records cost with full tenant and feature context, a usage ledger with a cached running balance, a policy check in the request path that can refuse or degrade, and a margin view that finance can open without asking engineering for a query.

It is normally a small slice of the overall build, and it is the piece that determines whether the pricing conversation 6 months later is a strategy discussion or a rewrite. It also tends to pay for itself before any pricing change happens at all, because the first thing the telemetry reveals is usually that one prompt is 3 times longer than it needs to be, or that half the calls could be served from cache.

This is a standard part of how we scope SaaS development work when AI is in the product. The pricing model is a commercial decision, and it belongs to you. Our job is making sure the system can support whichever one you land on, and the next one after that.

‍

5 mistakes that cost the most

• Pricing from your own token cost instead of customer value. Cost sets your floor, it does not set your price. A summary that saves a lawyer 20 minutes is not worth 5 cents because it cost you 5 cents.

• Exposing tokens as the billing unit. Buyers cannot forecast tokens, so they either refuse the model or over-buy once and churn. Bill in work units and keep tokens internal.

• Treating the cap as a billing rule rather than a runtime check. If the limit is not enforced in the request path, it is not a limit.

• Launching with no attribution because the feature is "just a pilot". Pilots become the pricing baseline. Instrument on day one, when it costs a day rather than a quarter.

• Ignoring the tail of the usage distribution. Averages hide the accounts that matter. Plan for the 95th percentile, because that is where both your margin risk and your expansion revenue live.

‍

Where to start this quarter

The shift worth making is from treating AI pricing as a spreadsheet exercise to treating it as a product capability. Pick the model your system can honour today, instrument properly, watch real usage for a quarter, and move up the ladder when the data tells you to. That is how you avoid repricing twice and having the second one land as an unplanned refactor.

If it helps to have the build side written down, the SaaS AI Blueprint sets out the architecture and cost decisions to settle before an AI feature ships, in the order they come up.

‍

And if you are weighing this against a live roadmap and want a second opinion on which rung you are actually on, book a free call with our team. We will look at how your AI features are instrumented today and what it would take to support the pricing model you want.