AI SaaS pricing models in 2026: per seat, usage, hybrid, and what to pick

Why AI pricing is different from classic SaaS

Classic SaaS pricing assumed the cost of serving one more user was close to zero. A project management tool costs you almost the same whether a customer logs in once a day or fifty times, so founders could price purely on perceived value.

AI SaaS breaks that assumption. Every prompt to a model API, every embedding, every rendered image, and often every agent step has a direct, variable cost. This is sometimes called variable COGS (cost of goods sold): your cost to serve scales with how much a customer actually uses the product, not just with the fact that they have an account.

The practical result: two customers on the same 49 dollar plan can have wildly different profitability. A light user might cost you 80 cents a month in inference. A power user running the same plan through automation might cost 60 dollars. Under a flat per seat price, the light user subsidizes the heavy one, and if you have too many heavy users, the plan runs at a loss.

So the first pricing decision for an AI founder is not which model to put on a landing page. It is understanding your own cost structure well enough that any model you pick can survive your worst-case user.

How to compute cost per active user

Cost per active user is the total variable cost of serving one customer for one month, summed across every metered input: model tokens, embeddings, storage, third party APIs, and background compute.

List every cost driver tied to usage rather than to the existence of an account: input and output tokens to your primary LLM, embedding calls for retrieval, vector database queries, per-action third party APIs (search, OCR, transcription), and compute for background jobs.

For each driver, multiply the unit cost by expected monthly volume for a representative user, then sum. Do this twice: once for a median user, and once for a heavy user, typically 5 to 10 times the median volume. Without real data yet, estimate volume from your own demo, then revise after your first 100 users.

Worked example: cost per user for an AI writing assistant

Assume a product that generates blog drafts, using a mid-tier LLM priced at 3 dollars per million input tokens and 15 dollars per million output tokens.

A median user generates 20 drafts a month, each using roughly 1,500 input tokens and 2,000 output tokens. Monthly input tokens: 20 times 1,500 equals 30,000. Monthly output tokens: 20 times 2,000 equals 40,000. Input cost: 30,000 divided by 1,000,000, times 3, equals 0.09 dollars. Output cost: 40,000 divided by 1,000,000, times 15, equals 0.60 dollars. Add 0.05 dollars for embeddings and retrieval. Total median cost: 0.74 dollars a month.

Now a heavy user at 8 times median volume: 160 drafts a month. Input tokens: 240,000, costing 0.72 dollars. Output tokens: 320,000, costing 4.80 dollars. Add 0.40 dollars for heavier retrieval. Total heavy user cost: 5.92 dollars a month.

At a 29 dollar plan, the median user costs 0.74 dollars, a 97.4 percent gross margin. The heavy user costs 5.92 dollars, a 79.6 percent margin. Both clear the 60 to 80 percent target even at the heavy end, so a flat 29 dollar plan works here, as long as a cap stops anyone from pushing far past 8x median without hitting an upgrade prompt.

Rule of thumbThe math changes fast if your heavy user is 30x the median instead of 8x. Always model the actual distribution you expect, not just the median, before committing to a flat price.

Per seat pricing

Per seat pricing charges a fixed amount per user account, independent of usage. It is easy to explain and forecast, and familiar to buyers, which is why most founders reach for it first.

It works when usage per user is fairly uniform, for example a writing tool with a natural cap on how much one human can produce in a day. It fails when one seat can trigger unlimited automated work, which is the case for most agent products and bulk processing tools.

• ▸Use when: usage is human-paced and predictable, with a natural daily ceiling.
• ▸Avoid when: one seat can run background jobs, agents, or bulk automation.
• ▸Guardrail: publish a fair-use ceiling, even on plans marketed as unlimited.

Usage based pricing

Usage based pricing charges per unit of consumption: per run, per token, per resolved ticket, per generated asset. Margins stay intact by construction, because price scales with the same variable that drives cost.

Small customers can start cheaply, and whales pay proportionally to what they consume. The downside is buyer anxiety: procurement teams hate unpredictable invoices, and self-serve users abandon signup when they cannot estimate a normal bill.

If you go usage based, invest early in a live cost estimator, spend alerts before a threshold is hit, and hard caps that prevent runaway bills from a bug or a misconfigured automation. Without these, usage based pricing generates support tickets faster than revenue.

Credit systems

A credit system wraps usage based pricing in a friendlier interface. Users buy or receive a bucket of credits, and each action consumes a published number of them.

Credits give buyers predictability, since they check a balance instead of an accumulating dollar figure, and give you a fixed exchange rate you can adjust as model prices change. Credits also make upgrades feel like restocking rather than renegotiating a contract.

The main risk is opacity. If a user can't tell what a credit buys before spending it, trust collapses the first time they run out early. Publish a clear table mapping every action to its credit cost.

Hybrid: base plan plus credits

A hybrid model combines a base subscription with a generous included allowance plus metered overage or credit top-ups above it. This is where most AI SaaS companies land once they reach product-market fit.

The base fee covers fixed costs and gives buyers a predictable budget line. The included allowance covers typical usage at a cost already inside your margin target. Usage above the allowance meters automatically or requires a top-up, protecting you from whales without capping growth for your best customers.

This model beats pure usage based pricing for most products because buyers still get a number to budget against, which removes the anxiety that kills self-serve conversion, while you keep protection against the tail of your usage distribution.

Outcome based pricing

Outcome based pricing charges for a measurable result, such as a dollar amount per resolved support ticket or per qualified lead, rather than for the compute consumed to get there.

This aligns price directly with value and can command a much higher price per unit than the usage based equivalent, since you price against the outcome, not the tokens. It works best where success is unambiguous and fast to verify, like an AI support agent resolving a ticket without escalation.

The downside is complexity: you need a reliable way to measure the outcome and handle disputes. Most founders should grow into outcome based pricing after they have usage data from a simpler model, not start there.

Free tier and trial design under token costs

A free tier on an AI product carries real marginal cost, unlike classic SaaS, so it needs a hard cap rather than an open door.

The safest structure is a time or credit limited trial: a fixed number of days, or a fixed number of credits, whichever comes first, with no auto-renewal into a free plan. This lets prospects experience real value without an open-ended cost center, and creates a natural moment to ask for a card.

If you want an always-free tier, size the cap against your worst-case acceptable loss per free user, not a round number that feels generous. A 'friendly' 50 free credits a month sounds fine until 5,000 free signups cost you 3,000 dollars in inference for zero revenue.

• ▸Prefer a time or credit limited trial over an open-ended free plan.
• ▸Require a card for trials involving expensive operations like image or video generation.
• ▸If you keep a free tier, size the cap against your actual per-unit cost, not instinct.

Margin targets: why 60 to 80 percent

Aim for 60 to 80 percent gross margin per plan, measured against a heavy-user scenario, not the median, because gross margin funds support, sales, and product development.

Below 60 percent, an AI SaaS usually can't afford the support and iteration speed needed to compete, especially once payment fees and cost creep are added. Above 80 percent, you likely have room to add usage-heavy features that strengthen retention without hurting margin.

The heavy-user check matters because averages hide the plans that actually lose money. A plan can show 85 percent margin on the median user and still lose money on the top 10 percent by usage. Run the margin math against your 90th or 95th percentile user, not just the average.

Guardrails against abuse

Rate limits, fair-use ceilings, and hard caps keep your worst-case cost from exceeding what a plan can support. They are not optional extras on an AI SaaS pricing page.

A rate limit caps requests per minute, hour, or day per account, protecting against both abuse and legitimate but runaway automation. A fair-use ceiling is a documented, generous but finite limit on 'unlimited' plans, giving you a basis to reach out before an account breaks your unit economics. A hard cap stops usage entirely once a threshold is hit, with a clear message and upgrade path, rather than accruing cost you can't recover.

Publish these limits in plain language on your pricing and terms pages. Hidden limits generate churn when customers hit them by surprise; visible limits, framed as protecting service quality for everyone, generate far less friction.

How to price your first version with no data

With no usage data yet, price from a cost model built on realistic assumptions, add a safety margin, and plan to revise within your first 90 days of real usage.

Build a cost-per-user estimate the way the worked example above does, using actual token counts from internal testing, not a generic industry number. Then assume your estimate is wrong by 2 to 3 times in the expensive direction, and check that your price still clears 60 percent margin under that assumption.

Launch with the simplest model that survives this stress test, usually a flat or hybrid plan with a visible cap, rather than a complex usage system you have no data to calibrate. This is part of why the LaunchLoop directory recommends listing with a public, simple price from day one: it forces the discipline of picking a defensible number before launch, instead of hiding behind a 'contact us' link while the cost model is still unclear.

When and how to raise prices

Raise prices when your data shows a clear signal: rising costs are compressing margin below target, your best customers ask for a tier you don't sell, or your price has stayed flat while value has visibly grown.

The clearest signal is margin compression: if more than 10 percent of accounts on a plan are unprofitable at your target margin, the price or the usage cap needs to change. A second signal is demand-side: prospects converting easily and rarely negotiating suggests you're priced under the market.

When you raise prices, announce the change to existing customers with at least 30 days notice, explain the reason in plain terms (rising model costs, new capability, more generous limits), and give current customers a materially better deal than new signups for a defined period.

Grandfathering existing customers

Grandfathering means letting existing customers keep their current price or terms when you raise prices for new customers, and it's the standard way to raise prices without a churn spike.

The simplest form is a flat grandfather: existing customers keep their exact price indefinitely, or for a fixed period such as 12 months, after which they move to the new price with advance notice. A softer form gives existing customers a smaller increase than new customers, framed as a loyalty discount.

Communicate the change directly by email, well before it appears on an invoice. Customers who learn about a price change from a surprise charge churn at a much higher rate than customers told in advance with a reason, even when the dollar amount is identical.

Packaging into three tiers

Package pricing into three visible tiers on a public page, with the middle tier positioned as the intended default choice for most buyers.

A typical structure: a starter tier priced as an easy first purchase with a capped allowance, a middle tier priced for your actual target customer, and a top tier for power users with a higher cap, priority support, and enterprise-adjacent features like SSO. Mark the middle tier as 'most popular,' since buyers default to the option a vendor signals as standard.

Keep pricing public. Hidden pricing behind a 'contact sales' link costs you self-serve conversions and hurts SEO and GEO visibility, since AI answer engines and search both favor pages with concrete numbers over pages requiring a form fill. If you're listing your product on a directory like LaunchLoop, having a clear public price also makes your listing far more useful to the founders and buyers browsing it.

• ▸Three plans maximum, with the middle one visibly the intended choice.
• ▸Annual discount between 15 and 20 percent, framed as two months free.
• ▸Publish exact limits and overage rules on the pricing page, not buried in terms of service.
• ▸Grandfather early customers when you reprice, and tell them before they see the invoice.