What cost per user per month actually measures
Cost per user per month is the token bill one active user generates in a billing period. It is the bridge between two numbers that otherwise never meet: the per-million-token rate on your provider's pricing page, and the per-seat or per-month price on yours. A provider rate tells you nothing about whether a $20 subscription works. Multiply that rate by how much a real user actually consumes and it tells you almost everything.
The chain is short. A user starts some number of sessions in a month. Each session runs some number of turns. Each turn bills a number of tokens — and that number is much larger than the words the user typed, because it includes the system prompt, any retrieved documents, the tools schema, the whole conversation so far, and the model's reply. Multiply the three together and you have tokens per user per month. Multiply by the rate and divide by a million and you have money.
The reason this matters more for AI features than for ordinary software is that the marginal cost is not close to zero. A conventional web feature costs a fraction of a cent per request and the finance team can round it away. A long-context model call costs real money every single time, and it scales linearly with engagement — the users who love your product most are the users who cost you most. Any pricing decision made without this number is a guess.
Use the result as a floor, not as your cost of goods sold. Tokens are the largest and most volatile line, but retrieval, embeddings, vector storage, evaluation runs, logging, egress and human support all sit on top. If you want the full picture, size the retrieval side with the embedding cost calculator and the vector database storage calculator and add them to this figure.
The formula, variable by variable
Cost per user is a plain product with one unit conversion in it:
C = s × m × t × R ÷ 1,000,000
s, sessions per month. Take this from your analytics, not from your hopes. Count only users who are active in the period, because that is the denominator you will divide the bill by later. If you have a distribution rather than an average, run the calculator twice — once at the median and once at the 90th percentile — because the two answers are usually far apart.
m, messages per session. One message means one billed request to the model. A single user action can be several requests: a router call, a retrieval-grading call, a generation call and a summarisation call are four, not one. Agentic features are where this number quietly triples.
t, tokens per message. The one people underestimate. A 40-word question is around 50 tokens; the request carrying it might be 6,000 because it drags a 2,000-token system prompt, three 1,000-token retrieved chunks and the prior turns of the conversation along with it. If the conversation history is resent each turn, tokens per message grows through the session rather than staying flat, so use the session average rather than the first turn.
R, the blended rate. Providers price input and output separately, and output is usually the dearer of the two. Blending collapses them into one number weighted by the mix you actually send:
R = (input tokens × input rate + output tokens × output rate) ÷ total tokens
For a turn with 1,200 input tokens at $3.00 per million and 300 output tokens at $15.00 per million, that is (1,200 × 3 + 300 × 15) ÷ 1,500 = (3,600 + 4,500) ÷ 1,500 = $5.40 per million blended. Note what the blend does: output is 20% of the tokens and 56% of the cost. If you shorten replies you move the blend, not just the volume. For a request-level breakdown of input and output separately, use the LLM API token cost calculator.
The division by 1,000,000 exists only because vendors quote per million tokens. Everything else is multiplication, which is why the answer is so sensitive to each factor: doubling any one of the four doubles the cost.
Worked example: a $20 assistant at 20 sessions a month
You sell an AI assistant at $20 per user per month. Analytics say an active user starts 20 sessions a month and sends 6 messages per session, and instrumentation on the API client says the average request bills 1,500 tokens including the reply. Your blended rate is $3.00 per million. You have 5,000 active users.
- Requests per user. 20 sessions × 6 messages = 120 requests per user per month.
- Tokens per user. 120 × 1,500 = 180,000 tokens per user per month.
- Cost per user. 180,000 ÷ 1,000,000 = 0.18 million tokens; 0.18 × $3.00 = $0.54.
- Gross margin. ($20.00 − $0.54) ÷ $20.00 = 19.46 ÷ 20 = 0.973 = 97.3%.
- Price for a 70% margin. $0.54 ÷ (1 − 0.70) = 0.54 ÷ 0.30 = $1.80. Any price above that clears the target on tokens alone.
- Bill at scale. $0.54 × 5,000 = $2,700 per month, or $32,400 a year.
That looks comfortable, and at the average it is. Now run the same arithmetic for a power user who starts 100 sessions, sends 10 messages each, and pushes 4,000 tokens per message because the feature retrieves documents: 100 × 10 = 1,000 requests, × 4,000 = 4,000,000 tokens, ÷ 1,000,000 × $3.00 = $12.00. Margin on the same $20 price is (20 − 12) ÷ 20 = 40%. The product did not change. The user did.
The gap between $0.54 and $12.00 for the same subscription is the whole reason this calculation is worth doing before you publish a price rather than after.
How to read the result
Read three things off the output, in this order.
First, the ratio of cost to price, not the cost. Fifty-four cents sounds trivial and twelve dollars sounds alarming, but neither means anything until it is divided by the price. The calculator gives you both the percentage of price consumed and the margin left. Because this margin counts tokens only, treat it as a ceiling: every other cost of serving the feature comes out of what remains.
Second, the shape of the distribution, not its average. Usage of a chat feature is heavily skewed — a small share of users generate a large share of the requests. That has a specific consequence for a flat-price plan: the average tells you the bill, and the tail tells you the risk. Compute the figure at your 90th-percentile user and ask whether that user is still profitable. If they are not, you need a cap, a metered tier, or a cheaper model on the heavy path.
Third, which lever moves the number. All four inputs multiply, so a 30% reduction in any one of them cuts cost by the same 30%. That makes tokens per message the usual first target, because it is the factor engineering controls directly and users never see: trimming a system prompt, truncating history, retrieving three chunks instead of eight, or capping reply length all reduce t without touching s or m. Cutting sessions or messages, by contrast, means reducing engagement, which is rarely what you want.
If the margin is thin, the ordered menu of fixes is: shrink the context, cache the unchanging prefix, route easy turns to a cheaper model, then change the price. Caching in particular is nearly free to implement on a long static system prompt — size it with the prompt caching savings calculator before you consider anything more invasive. If your volume is very large and steady, the self-hosted versus API break-even calculator tells you whether owning the inference changes the picture at all.
Token cost per user per month at common usage and rates
| Tokens per user per month | $0.50 / 1M | $3.00 / 1M | $15.00 / 1M |
|---|---|---|---|
| 50,000 | $0.025 | $0.15 | $0.75 |
| 200,000 | $0.10 | $0.60 | $3.00 |
| 500,000 | $0.25 | $1.50 | $7.50 |
| 2,000,000 | $1.00 | $6.00 | $30.00 |
| 10,000,000 | $5.00 | $30.00 | $150.00 |
Every cell is tokens ÷ 1,000,000 × rate. Compare the row you land on with your monthly price: at 2,000,000 tokens a month, a $15 blended rate costs $30 and a $20 subscription is already under water.
Mistakes that make this number wrong
- Counting user messages instead of API requests. Routers, retrieval graders, tool-call round trips and summarisation passes are billed requests too. A feature that looks like one call per turn is often three or four.
- Using the first turn's token count for the whole session. If you resend the conversation each turn, tokens per request grow as the session goes on. Take the session average from your own logs.
- Blending input and output with the wrong weights. Output usually costs several times input, so a blend that assumes an even split understates cost whenever replies are long.
- Dividing the bill by registered users rather than active users. That produces a flattering cost per user and a margin you cannot defend. Use the same active-user definition on both sides.
- Treating the average user as the whole population. A flat price with a skewed usage distribution is a bet that the tail stays small. Size the tail explicitly.
- Forgetting free tiers and trials. Trial users consume tokens and pay nothing, so their cost belongs in customer acquisition cost, not in gross margin — but it does belong somewhere.
- Ignoring retries and failures. A request that times out after generating 400 tokens is still billed. Add your observed retry rate to the message count.
Gross margin here is a ceiling, not a cost of goods sold
The margin this calculator reports subtracts model tokens and nothing else. A complete cost of goods sold for an AI feature also carries embedding generation, vector store hosting, object storage for documents, evaluation and regression runs against the model, observability, and the support burden of a feature that occasionally gets things wrong. Each of those is small next to tokens at low volume and stops being small at high volume. Quote the number in this calculator as token gross margin and keep it distinct from the margin your accountant reports.
Where this sits among the other AI cost questions
This calculator answers the pricing question. Three neighbouring questions need different tools, and confusing them is common.
"What does one request cost?" is a request-level question and belongs in the token cost calculator, which keeps input and output separate instead of blending them. Use it while you are optimising a prompt; use this one while you are setting a price.
"Should we run our own GPUs?" is a volume question. Self-hosting replaces a variable per-token cost with a fixed hourly one, so it wins only above a break-even volume that depends on how well you keep the hardware busy. That threshold, and the utilisation assumption behind it, is what the break-even calculator exists to expose.
"Should we fine-tune?" is a question about trading a one-off training cost against a permanently shorter prompt. The fine-tuning versus long-prompt calculator finds the request count at which the trade pays back.
One structural point ties all of them together. Token-metered costs are variable, and variable costs scale with success. That is the opposite of the classic software shape, where the marginal user is nearly free, and it changes what a good business model looks like: usage caps, credit systems, tiered model routing and per-seat limits are not hostile pricing tactics in an AI product, they are the mechanism that keeps the marginal user profitable. Decide which of them you need while the number in this calculator is still small.
Key terms
- Blended rate
- A single price per million tokens that weights the input and output rates by the proportion of each you actually send. It lets you multiply one rate by total tokens instead of tracking two streams.
- Token gross margin
- Revenue minus model token cost, divided by revenue. An upper bound on true gross margin, because it excludes every other cost of serving the feature.
- Active user
- A user who used the feature at least once in the billing period. The denominator must match the population whose usage you measured, or cost per user is meaningless.
- Context
- Everything sent to the model on a request: system prompt, tool definitions, retrieved documents, conversation history and the user's message. It is billed as input tokens on every single turn.