How Much Does an AI Feature Cost Per User?
The average cost per user is the least useful number in this calculation. What decides whether your pricing survives is the gap between your median user and your ninety-ninth percentile.
Take your monthly AI provider bill, divide by monthly active users, and you have a number that will mislead you. Not because the arithmetic is wrong, but because AI usage is not distributed the way that average implies. A handful of users will consume twenty or fifty times the median, and whether your pricing works depends entirely on them, not on the middle of the curve.
Here is the calculation that actually tells you something.
Start With the Unit, Not the Bill
Before you can attribute cost to a user, you need cost per action. That means logging, on every AI call your app makes: the user, the feature, the model, input tokens, output tokens, and the computed cost. One row per call.
ai_usage
id
user_id
feature -- 'summarise', 'chat', 'image', ...
model
input_tokens
output_tokens
cost_usd -- computed at write time, not later
created_atCompute the cost at write time rather than deriving it in a report. Prices change, models get swapped, and a report that applies today's rates to last quarter's calls will be quietly wrong. Store what it cost when it happened.
If you do not have this table, that is the whole task for this week. Everything below is a query against it, and without it you are estimating from a provider invoice that does not know which of your users did what.
Then Ask for Percentiles, Not the Mean
With per-call costs recorded, the question becomes a single query, and the shape of the answer is the point. Postgres computes percentiles natively with percentile_cont, so this needs no extra tooling.
select
count(*) as users,
round(avg(cost)::numeric, 4) as mean,
round(percentile_cont(0.5) within group (order by cost)::numeric, 4) as p50,
round(percentile_cont(0.9) within group (order by cost)::numeric, 4) as p90,
round(percentile_cont(0.99) within group (order by cost)::numeric, 4) as p99,
round(max(cost)::numeric, 4) as worst
from (
select user_id, sum(cost_usd) as cost
from ai_usage
where created_at >= date_trunc('month', now())
group by user_id
) per_user;A representative result from a text-heavy product looks something like this:
Statistic | Cost this month | What it tells you |
|---|---|---|
Median (p50) | $0.31 | What a normal user actually costs |
Mean | $0.94 | Dragged up by the tail, describes nobody |
p90 | $2.10 | Your engaged users, the ones you want more of |
p99 | $14.80 | The group that decides whether a flat plan works |
Worst | $71.40 | Either your best customer or an unbounded loop |
Mean at three times the median is the normal shape, not an anomaly. It means any calculation built on the average is describing a user who does not exist.
Why the Tail Decides Your Pricing
Consider two products with an identical $0.94 average cost per user, both charging $15 a month.
Product A | Product B | |
|---|---|---|
Median user cost | $0.80 | $0.31 |
p99 user cost | $3.10 | $14.80 |
Worst user | $9.00 | $71.40 |
Margin on a p99 user | Healthy | Roughly zero |
Margin on the worst user | Thin but positive | A loss of $56 |
Same average. Completely different business. Product A can price flat and stop thinking about it. Product B has a real exposure at the top of its distribution, and its options are a usage cap, a higher tier, or a metered component. This is the comparison the per-seat and usage-based debate ultimately turns on, and it is why choosing between per-seat and usage-based pricing should follow the measurement rather than precede it.
Work out what fraction of revenue the worst decile consumes. Under about fifteen per cent, flat pricing is comfortable. Above thirty, you are subsidising heavy users with light ones, which works only while the mix holds, and the mix never holds once word gets around.
The Costs the Query Misses
Provider spend is the visible part. Three things sit outside it and routinely change the answer:
Retries and failures. A call that errored still cost you if the provider billed it. Log failed calls with their cost, or your real spend exceeds your measured spend by a margin you cannot see.
Work that happens without a user. Nightly summarisation, embedding refreshes, scheduled reports. Attribute it to the users it serves or it will sit uncosted in a corner of the bill.
Free-tier and trial users. Often the most expensive cohort per head, because they are exploring rather than working. Query them separately from paying users or they will distort both numbers.
Storage, bandwidth and compute belong in the total too, though they are usually a smaller share than people expect. What it costs to run an AI-built app covers the rest of the stack; this calculation is specifically about the metered AI portion, which is the part that scales with behaviour rather than with headcount.
What to Do With the Number
Set the cap before you need it. A per-user quota generous enough that ordinary users never notice, low enough that a runaway loop cannot cost you hundreds. Your p99 is the natural place to look for it.
Price the tiers off p90, not the mean. Your paying customers concentrate above the median, so a plan costed against the mean is costed against your free users.
Alert on individual users crossing a threshold. A user at fifty times median is either a great enterprise lead or a bug, and you want to know which within hours.
Recheck after any model change. Swapping models moves every number here, sometimes by a factor of five. Cheaper per token does not always mean cheaper per user, because a weaker model often needs more retries.
Look at cost per user per feature. One feature usually dominates, and that is where a caching or prompt change pays for itself.
Underneath all of it is a question this calculation exists to answer: whether the way you charge matches the way the cost arrives. That is the core of AI monetization strategy, and it is a far easier conversation to have with a percentile table in front of you.
That last point is where most of the savings actually sit. Once you know which feature carries the cost, the specific techniques in reducing AI API costs have somewhere to aim, instead of being applied evenly across calls that were never the problem.
Frequently Asked Questions
How do I calculate AI cost per user?
Log every AI call with the user id and the cost computed at the time of the call, then sum per user for a period. Report the median, p90 and p99 rather than the average, because usage distributions are heavily skewed.
Why is the average cost per user misleading?
Because a small number of heavy users pull it well above the median. The mean typically lands at two or three times what a normal user costs, so it describes neither your typical user nor your expensive one.
What is a reasonable AI cost as a share of revenue?
It depends on your margins, but if AI spend for a given plan exceeds roughly a fifth of that plan's price, you have little room for the rest of the business. Measure it per tier, since the mix differs sharply between them.
Should I cap AI usage per user?
Yes, with the cap set well above what ordinary users do. Its job is not to shape normal behaviour, it is to bound the damage from a runaway loop or an abusive account.
Do free trial users need to be counted separately?
Yes. Trial users often cost more per head than paying users because they are exploring rather than working, and mixing them into one figure distorts both.
How did this land?
About the author

Growth & SEO Lead
Manuele covers distribution: SEO, content strategy, and how AI-built products find their first thousand users. He tests everything he recommends.


