LLM cost per user: how to price an AI feature in your SaaS

Adding an AI feature to a software product changes its cost structure. Most SaaS costs per user are small and predictable; an LLM feature has a cost that rises with every use. Before you set a price, a plan limit or a free tier, you need one number: what the feature costs per user per month. This guide shows how to calculate it, how heavy users distort it, and how to turn it into a price. Model prices are in US dollars per million tokens, taken from each provider's own pages on 2 November 2026. The usage figures are an illustration, not a measurement of any real product: replace them with your own.

Why price per user

Teams often start from the monthly invoice and divide by users. That gives an average, and it hides the question you actually need to answer: what does a typical user cost, what does your most active user cost, and what happens to margin if usage doubles after launch? Working from requests per user answers all three, and it lets you test a price before the invoice exists.

The example feature

Take an in-app assistant that drafts and edits text for the user. Each request sends the model:

• 1,500 tokens of fixed instructions: role, style rules and product context. The same on every request, so it can be cached.
• 1,500 tokens that change: the user's document, their instruction and any retrieved content.

The model replies with 400 tokens. That is 3,000 input tokens and 400 output tokens per request. A typical user makes 40 requests a month. A reasoning model that thinks before answering will bill extra output tokens for the thinking, so measure real output, not only the visible reply.

Cost per request

Cost per request = (input tokens × input price + output tokens × output price) ÷ 1,000,000. With the fixed 1,500 tokens read from the cache, they are billed at the cached-input rate instead. Cache-write charges are left out, because on steady traffic a cache is written rarely compared with how often it is read; our prompt caching guide has the write prices and lifetimes.

Cost per user per month

Multiply by requests. The table shows a typical user at 40 requests, a heavy user at 400, and the same typical user if every reply were five times longer (2,000 output tokens), all with the fixed prompt cached.

Two things stand out. The model you choose moves the cost by a factor of 100 between the smallest and the largest, so a model test on your own tasks is worth doing before pricing. And answer length matters: output costs five times as much as input per token on every model here, so a feature that writes long answers can cost three times as much per user as one that writes short ones, with the same prompt.

Heavy users

Averages are dangerous for usage-based costs. Suppose 1,000 users split three ways: 800 make 40 requests a month, 150 make 120, and 50 (5%) make 400. The average is 70 requests per user, and the 50 heaviest users generate 20,000 of the 70,000 requests, which is 29% of the total.

If your plan is flat-rate, the heaviest users cost the most and pay the same. That is acceptable when the cost is a small fraction of the plan price, and a problem when it is not. On a Sonnet 5.5 or Sol feature, a heavy user at $2.86 a month is a small share of a $20 plan (about 14%) but most of a $5 plan (about 57%). Fair-use limits, monthly request allowances, or paid top-ups keep that exposure bounded.

From cost to price

A simple starting rule is to choose the gross margin you want on the model cost, then work backwards:

price per user = model cost per user ÷ (1 − target margin on model cost)

At a typical cost of $0.50 per user (the 1,000-user mix on Sonnet 5.5 or Sol) and an 80% margin target, the feature needs to bring in $0.50 ÷ 0.20 = $2.50 per user per month. At a 90% target it is $5.00. Use the heavy-user cost, not the average, to set limits: at 400 requests costing $2.86, an allowance of 200 requests costs about $1.43.

This is a floor, not a price. Model tokens are one cost line. Retrieval, storage, monitoring, evaluation, support and the engineering to build the feature are separate, and what customers are willing to pay depends on the value they get, not on your cost. Use the formula to make sure a price cannot lose money, then price on value above it. Two more checks are worth doing: how the cost changes if usage doubles after launch (a successful feature is used more), and how it changes when a provider updates prices (Gemini 4 Argon, for example, has announced a price rise from 1 December 2026; see what it means for your bill).

Ways to lower cost per user

1. Cache the fixed prompt. In the example it cuts cost per request by 27% to 29% on the Astra, Opus, Sol and Sonnet rows. Longer fixed prompts save more.
2. Route by difficulty. Send simple requests to a small model and keep the larger one for hard cases. See our small versus large model guide.
3. Limit output. Set a maximum length and ask for concise answers where long ones add nothing.
4. Move work that can wait to batch. Background jobs such as summaries or nightly reports can use batch processing at half price; see the batch API guide.
5. Cap and meter. Per-user allowances turn an open-ended cost into a bounded one.

How to measure your own number

Log input, cached and output tokens for every request together with a user ID. After a week of real use you can read off requests per user, the spread between typical and heavy users, and the cost of each. Price the totals from the current price list with the API pricing calculator. If the feature is already live, the free Bill Analyzer reads your usage export and estimates the effect of caching, cheaper models and batch processing. For a ranked plan based on your real requests, with savings shown as ranges, see the LLM Cost Report.