Skip to content
LPR Studio
FREN
Contact us

AISaaSPricingBudget

Building an AI SaaS product: inference costs, margins, lock-in

10 min read

An AI SaaS product has a cost that traditional SaaS mostly does not: every use is billed. The model provider charges for the text processed, request by request, so your margin depends not just on your subscription price but on how heavily each customer uses the product and on a price list you do not control. Three things decide whether the business works: inference cost per customer, a pricing model that covers it, and an architecture that lets you change models.

This article draws on first-hand experience with Tubissime, a personalised song service created with AI that LPR Studio designed, built and runs itself. We do not recommend any particular AI provider: the right model depends on your task, and it keeps changing.

What is different from traditional SaaS

Traditional SaaS has high build costs and low marginal costs: a new customer adds a little hosting and a little support. Our breakdown of what it costs to build a SaaS platform covers those lines.

AI SaaS adds a third line: inference, running the model on every request. It has three awkward properties.

  • It scales with usage, not with the number of customers. Two customers on the same plan can cost very different amounts.
  • A third party sets the price, and can change it.
  • It depends on choices the customer never sees: prompt size, how much context is sent, how many calls one action triggers.

What inference costs, from published price lists

Providers publish prices in US dollars per million tokens, with one rate for input sent to the model and a higher one for output it generates. Checked on official pages on 3 November 2026:

ProviderExample modelInput / output (per million tokens)
AnthropicClaude Haiku 5.5$0.10 / $0.50
AnthropicClaude Sonnet 5.5$2 / $10
OpenAIgpt-6-luna$0.10 / $0.50
OpenAIgpt-6.1-sol$2 / $10
GoogleGemini 3.8 Flash$0.75 / $3.75
GoogleGemini 4 Argon$2 / $10
Mistral AIMistral Large$0.5 / $1.5

Sources: Anthropic pricing (Claude Haiku 5.5 rate for prompts up to 100,000 tokens), OpenAI pricing, Gemini API pricing, Mistral AI pricing. Read the table as orders of magnitude, not a ranking: quality depends on the task, and a cheap model that often fails ends up costing more than it looks.

Cost per customer, worked through

An assumption to replace with your own measurements: an active customer sends 300 requests a month, each with 5,000 input tokens and 1,000 output tokens.

Model price (input / output)Cost per requestMonthly cost of that customer
$0.10 / $0.50$0.001$0.30
$2 / $10$0.02$6
$10 / $50$0.10$30

The same customer can cost a few cents or tens of dollars a month depending on the model. If that customer makes ten times more requests than planned, the cost goes up tenfold. The subscription does not.

Levers that lower the bill

  • The right model for each step. Classification or extraction often works with a small model; final drafting may justify a stronger one.
  • Batch processing. Anthropic, OpenAI and Google bill requests that can wait at half price, according to their pricing pages, and Mistral AI advertises the same 50% reduction.
  • Caching repeated context such as instructions and reference documents: Anthropic, OpenAI and Mistral AI bill cached input well below the normal input rate.
  • Less context. Send the passages that matter, not the whole file.

Pricing that protects the margin

AI SaaS pricing has to follow usage one way or another.

ModelHow it protects marginWatch out for
Subscription with quotaThe quota caps cost per customerPlan overage pricing or throttling
Prepaid creditsThe customer pays before consumingMake the value of a credit easy to understand
Pay per outputEvery output is paid forSuits occasional use
Unlimited flat rateIt does notA few heavy users are enough to lose money

Our guide on how to price a SaaS product covers tiers, free trials and annual plans in more depth.

What running Tubissime taught us

Tubissime sells personalised songs. The customer tells a story, AI writes the lyrics, the customer reviews them and can ask for another version before paying, and then the music is composed. Here is what its case study documents, and the lessons we draw for any AI SaaS.

Pay per order, no subscription. Every song involves AI generation, and every song is paid for. A creative studio, paid with credits, serves users who want to write their own tracks. Both models tie revenue to consumption.

A back office that shows real cost. For each customer: generation cost, revenue and margin. That is how you know whether the price holds, order by order, instead of finding out from the provider's monthly invoice.

Prices adjustable without a redeploy. Prices and credits are changed in the back office, without touching the code. When a cost moves, responding does not require a release.

A human checkpoint before the next step. The customer reviews and edits the lyrics before the music is composed. Beyond quality, it avoids starting the composition on lyrics that are not right.

Model dependence: the risk founders forget

An AI SaaS sits on top of a provider that can change three things without asking you.

Price. As of 3 November 2026, Google's pricing page announces that Gemini 4 Argon will go from $2 / $10 to $4 / $20 per million tokens on 1 December 2026, and Gemini 3.8 Flash from $0.75 / $3.75 to $1.50 / $7.50 on 1 January 2027. A product priced on thin margins at the old rate loses them overnight.

Availability. Providers retire models. Anthropic's pricing page marks several versions as retired, and Google's states that from 1 December 2026, requests sent to Gemini 2.5 Pro will be routed to another model and billed at that model's rate.

Behaviour. A new version can respond differently to the same prompts: tone, length, output format.

Three safeguards, all cheap if built in from day one:

  1. A single model access layer in the code, so a change of provider happens in one place.
  2. Versioned prompts and a test set in your repository, replayed on every model change.
  3. A second model tested regularly against that set, ready to take over.

These are the same principles we apply to a custom AI agent for a business, applied to a product you sell.

What does not change: the rest of the SaaS

The model call is a small part of the product. Everything else is ordinary SaaS: accounts, payments, invoicing, permissions, support, hosting, security. AI adds obligations of its own: if you serve users in the EU, the EU AI Act requires transparency about AI-generated content, and data protection law applies as soon as a request contains personal data. The broader view of adding AI features to a business application covers human review and data quality, which matter just as much in a product.

Where the product value really sits

A thin wrapper around a public model is easy to copy: anyone with the same API key can rebuild it in a weekend. The defensible part of an AI SaaS is usually elsewhere:

  • The workflow around the model: what the user provides, what they check, what happens with the output afterwards.
  • Domain data and rules the model does not have on its own: templates, vocabulary, constraints of a specific trade.
  • Integration with the tools your customers already use.
  • Trust: clear review steps, predictable results, and support when something goes wrong.

Those are also the parts that survive a change of model, which makes them the safest place to invest.

Pre-launch checklist

  1. Measure consumption on real cases for each candidate model, and derive a cost per customer profile.
  2. Model the heavy user, not just the average one.
  3. Choose a pricing model that follows usage: quota, credits or pay per output.
  4. Log the cost of every request per customer from the first version.
  5. Isolate the model call and keep a second model tested.
  6. Watch your providers' pricing pages: an announced change can be prepared for before it takes effect.

Frequently asked questions

Why are AI SaaS margins harder to protect than traditional SaaS margins?

Because every use costs money. In traditional SaaS, an extra customer adds little hosting cost. In AI SaaS, each request is billed by the model provider according to the amount of text processed. A very active customer can therefore cost more than their subscription brings in, unless pricing takes usage into account from the start.

What pricing model works best for an AI SaaS product?

One that tracks the real cost of usage. Three models work well: a subscription with an included quota and paid overage, prepaid credits, or pay per output for occasional use. Unlimited flat-rate plans carry the most risk, because a handful of heavy users can consume the whole margin of the product.

How can an AI SaaS reduce its dependence on one model provider?

Route every model call through a single access layer in your code, keep prompts and test sets in your own repository, and regularly run a second model against those tests. Providers change prices and retire versions, so a product that can switch models in days keeps control of its margin and its roadmap.

Should an AI SaaS track AI cost per customer from the first version?

Yes. Logging the customer, the model and the tokens used for every request is cheap to build at the start and expensive to retrofit. Without that data you cannot tell which customers are profitable, set a fair quota, or compare two models on real traffic instead of guesses.