LLM cost per user is the only number that decides whether your AI feature works

Providers sell tokens. You sell seats, or plans, or requests. The conversion between those two units is where an AI product either has a business model or doesn't.

By Soufiane Bellahmar · Founder and editor, LLM Cost Lab
Figures recomputed from the 60-model dataset on every build. Rates last verified 2026-08-16.

There is a specific moment in the life of every AI feature when someone senior asks what it costs, and the answer comes back in dollars per million tokens. That answer is useless to them, and it is useless because it is denominated in the supplier's unit rather than the business's. Nobody sells tokens. You sell a subscription, or a seat, or an outcome.

The number that matters is cost per active user per month. It is the number that determines gross margin, which determines whether the feature can be bundled into an existing plan, needs its own price, or should not ship at all.

The conversion

Three quantities produce it:

• Interactions per active user per month. Not registered users — active ones, and only the ones who touch the AI feature.
• Tokens per interaction, input and output separately. These are priced differently, usually by a factor of four or five, so a single blended figure will mislead you.
• The model's two rates.

Multiply and you have it. The difficulty is never the arithmetic; it is that the first two numbers are usually guesses, and the guesses are usually low. Instrument them before you trust them.

A worked example across the price distribution

Take a moderately engaged user: 40 interactions per month, each sending 2,500 input tokens (a system prompt, some retrieved context, and the user's message) and receiving 500 output tokens. That is 100,000 input and 20,000 output tokens per user per month.

Priced against five models drawn from across our distribution — cheapest, first quartile, median, third quartile, most expensive:

The cheapest option costs $0.00560 per user per month. The median costs $0.170. The most expensive costs $6.60. Same feature, same usage, same users.

Why this decides the business model

Put those against a $20 per month subscription and the picture stops being abstract.

• At $0.00560, inference is 100% gross margin territory — it disappears into the noise alongside hosting, and you can bundle the feature into an existing plan without thinking about it.
• At $0.170, inference is 99% margin. That is a real cost line. It survives, but it needs watching, and a heavy-usage cohort will hurt.
• At $6.60, the arithmetic breaks. You are looking at usage caps, a higher price point, or a different model.

Note what did not change between those three scenarios: the product, the users, the value delivered. Only the model choice. This is why model selection is a business decision that happens to be made by engineers, and why it should be revisited on a schedule rather than made once at the start of a project when usage patterns were unknown.

The distribution problem

Averages will betray you here, and it is worth being specific about how.

AI feature usage is not normally distributed. It follows something closer to a power law: a small group of users generates a large majority of the tokens. If your average user has 40 interactions per month, your ninety-ninth percentile user may have twenty times that. On a flat-rate plan, that user costs twenty times as much and pays the same.

This is survivable and normal — every flat-rate business has heavy users. It becomes dangerous in two situations. The first is when the heavy tail is large enough to move the blended average, which happens more often than intuition suggests. The second is when your heaviest users are also your most price-sensitive, which is common in developer tools and means you cannot simply raise their price.

Model the percentiles, not the mean. Then decide deliberately whether the tail is a cost of doing business, a signal to introduce usage-based pricing, or a case for routing that cohort to a cheaper model.

The levers, in order of leverage

Model choice

The largest lever by a wide margin, as the numbers above show. The question is never "what is the best model" but "what is the cheapest model that is good enough for this specific call." Those are different questions and only the second one has a useful answer. Choosing a model by cost works through how to decide it.

Routing

Most products have a mix of easy and hard requests. Sending everything to the model sized for the hardest one means overpaying on the majority. A classifier in front — even a crude one — that routes simple requests to a small model typically cuts blended cost substantially while leaving the hard path untouched.

Caching

If your system prompt and retrieved context are stable across a user's session, prompt caching reduces the input side directly. Since input is usually the larger token count in a RAG-shaped application, this matters more than its share of the rate card suggests. The caching calculator prices it at your hit rate.

Context discipline

Retrieving twelve chunks when four would do is a 3× multiplier on your largest token category, applied to every request forever. Retrieval quality is a cost control, not just a quality control, and it is the one most often left untuned.

To run these numbers on your own usage profile, the monthly cost estimator takes interactions and token counts directly, and the cost per request calculator works from a single call upward. If you want to compare two candidate models on identical assumptions, the model switching calculator shows the annual difference.