LLM Cost Per User: Why MAU Averages Hide Your Margin Risk

Every board deck with an AI feature in it has one LLM number: total inference spend divided by monthly active users. It is the easiest number to produce and the least useful one you will put on a slide, because it answers a question nobody is actually asking.

The question that matters isn’t what your average user costs. It’s what your most expensive user costs, and whether you are still making money on them. Those two numbers can differ by an order of magnitude, and only one of them can sink a pricing model. Figures below are computed from our catalog as verified 2026-08-31.

Cost per MAU looks reassuring — that’s the problem

Take a per-seat product with a chat feature that carries conversation history — 3,000 input and 600 output tokens per request, engine defaults otherwise. A typical user sends 40 requests a month. Against a $20 seat:

Read the typical-user column and you would conclude LLM cost is immaterial — a few cents to well under a dollar against a $20 seat, on every model. Read the heavy-user column and Claude Sonnet 4.6 is eating 27% of the same seat. Both columns are true at the same time, for the same product. That is the entire problem with a single cost-per-MAU figure: it is an average over a distribution that isn’t shaped anything like a normal one.

Usage is power-law, and averages assume it isn’t

Software usage has always been skewed, but most SaaS could ignore it because the marginal cost of a heavy user was approximately zero. Serving someone who opens the app forty times a day costs about the same as serving someone who opens it twice. LLM features break that assumption completely: the heavy user’s marginal cost is real, and it scales linearly with their enthusiasm.

So the mean gets dragged upward by the tail — which makes it a bad estimate of the typical user — while still sitting far below what the tail individually costs you. It is the worst of both: too high to describe most users, too low to describe your risk.

The number to put on the slide instead

Here is a more honest question: at how many requests per month does a single seat stop being profitable on inference alone? Not counting hosting, support, salaries or payment fees — just tokens against the $20 you charge.

Claude Sonnet 4.6      1,099 req/mo   (37/day)
GPT-5.4                1,409 req/mo   (47/day)
Claude Haiku 4.5       3,297 req/mo   (110/day)
GPT-5.4 mini           4,696 req/mo   (157/day)
Gemini 2.5 Flash       9,664 req/mo   (322/day)
DeepSeek V4 Flash     11,534 req/mo   (384/day)

On Claude Sonnet 4.6 a $20 seat goes underwater at 1,099 requests a month — about 37 a day. That is genuinely heavy usage for a chat feature, and if your product is a chat sidebar you are probably fine. If it is the primary work surface — a coding assistant, a support console, an agent someone drives all day — that number is not comfortably far away.

The threshold moves on prompt size, not request count

Request count is the variable everyone watches, and it is the less dangerous one. Hold requests fixed and let conversations get longer — 10,000 input tokens instead of 3,000, which is an ordinary outcome of a chat that carries history — and the same $20 seat on Claude Sonnet 4.6 breaks even at 541 requests a month instead of 1,099: about 18 a day.

Nobody changed their behaviour. The same user, sending the same number of messages, became 2× more expensive because the transcript grew. This is the quadratic problem from stateless vs. with history arriving on your P&L: cost per user drifts upward over a customer’s lifetime even with completely flat engagement, and a cost-per-MAU chart will show that as a slow, unexplained climb.

Engagement and margin now point in opposite directions

This is the part that catches product teams rather than finance teams. Every growth playbook written in the last fifteen years assumes engagement is unambiguously good: a more active user retains better, expands more, and churns less, at no incremental cost. Free trials, generous limits and “unlimited” plans all rest on marginal cost being near zero.

With an LLM feature in the product, your most engaged cohort is also your most expensive cohort — and the two effects grow together. That doesn’t mean engagement is bad. It means you can no longer reason about growth and unit economics separately, and the org chart usually has those two conversations happening in different rooms.

Three numbers, three audiences

One metric cannot serve all of this. In practice you want three, and they answer to different people:

• Cost per MAU — for the board. The trend line matters more than the level. Rising cost per MAU with flat usage means your mix is shifting; rising cost per MAU with rising usage may be exactly what you want.
• Cost per user at p95 — for pricing. This sets your margin floor, and it is the number a seat price has to survive. If you only ever compute the mean, you will discover the p95 from a billing surprise instead.
• Cost per completed action — for engineering. The only one of the three your team can directly move, via caching, model choice, routing, or prompt size. The other two are outcomes of it.

What to actually do about the tail

• Price the p95, not the mean. Set the seat price against a user you would be unhappy to lose money on, not against the median.
• Meter the expensive thing, not the cheap one. Seats are a proxy for value that LLM features break. Usage-linked tiers, credits, or a fair-use ceiling realign price with cost — and are far easier to introduce before you have enterprise contracts than after.
• Route by cohort. A heavy user on a cheaper tier can be more profitable than a light user on the flagship. Routing is usually framed as a per-request decision; it works just as well as a per-cohort one.
• Cache before you re-price. On a history-carrying chat workload the prefix is highly cacheable, and cutting the per-request cost moves the break-even threshold directly — often far enough that the pricing problem stops being a problem.
• Alert on the threshold. Once you know the break-even request count, a user crossing it is a monitorable event rather than a quarter-end discovery.

None of this requires precision. It requires knowing roughly where the cliff is before you commit to a price — which is the whole argument for modelling costs at design time rather than reading them off an invoice.