When Your AI Feature Costs More Than the Subscription
A customer costing you more than they pay is not one problem. It is three, and the fix is completely different depending on which one you have.
If a customer pays you $29 a month and their AI usage costs you $34, you do not have a pricing problem. You have a cohort problem, and the fix depends entirely on whether that customer is typical, exceptional, or the future.
Most advice here jumps straight to "add usage limits". That is sometimes right and often premature, because it treats every negative-margin account as the same thing. They are not. Work out which of three situations you are in first.
Establish the shape before you touch anything
Pull per-customer AI cost for the last full month and sort descending. Then look at the distribution rather than the total.
Case one: a long tail of heavy users. The top 5% of accounts consume a wildly disproportionate share, and the median account costs you a fraction of its subscription. Your average margin is fine. You have an outlier problem.
Case two: the median is underwater. Half your accounts cost more than they pay. This is not an outlier problem, it is a product economics problem, and no amount of rate limiting fixes it.
Case three: costs are climbing with engagement. Margin was fine at onboarding and degrades as customers get good at the product. This is the most dangerous one, because it looks healthy right up until retention improves.
The response is different in each case. Case one is a policy change. Case two is a pricing change. Case three is an architecture change, and the sooner the better.
Case one: a few accounts are eating the margin
You do not need to reprice everyone because eleven accounts are unusual. Options in rough order of how much goodwill they cost:
Look at what they are doing first. Heavy usage is frequently a bug on your side: a retry loop, a feature that reprocesses the same document on every page load, a customer who wired your API into a cron job because you never said not to. A meaningful share of "expensive customers" are actually expensive code paths.
Cheapen the request before you cap it. Caching identical or near-identical prompts, trimming context that is not doing work, and routing simple requests to a smaller model routinely cut per-request cost substantially with no change to what the customer sees. Reducing AI API costs is where to start, because it is the only lever here that nobody resents.
Then set a fair-use ceiling. Generous enough that 95% of accounts never see it, explicit in the terms, with a clear upgrade path when they hit it. A ceiling that catches ordinary users is a support burden dressed up as a pricing policy.
Case two: the median account loses money
There is no operational fix for this. The price is wrong, the product is too expensive to run, or the plan includes something it should not.
Three genuine options, and they are not equally available:
Move | When it fits | The cost |
|---|---|---|
Raise the price | Product is clearly delivering the value | Churn on the weakest cohort, and one hard month |
Move AI to a metered add-on | AI is one feature among many | Revenue becomes lumpier and harder to forecast |
Cut inference cost structurally | You have obvious inefficiency left | Engineering time, and there is a floor |
Most teams try the third first because it is the only one that does not require talking to customers. That is understandable and usually correct as a first pass, but it has a floor. You cannot optimise your way from minus 20% gross margin to plus 70%. At some point the conversation happens.
When it does, raising prices on an AI product is the mechanics, and usage-based versus flat-rate pricing is the structural question underneath it. The metered add-on is the middle path and it is underused: keep the flat subscription for everything that is cheap to serve, meter the one component whose cost genuinely varies with use.
Case three: cost grows with engagement
This is the one that quietly kills otherwise-healthy products, because every other metric is telling you things are going well.
The mechanism is usually one of three:
Context accumulates. Conversation history, document sets and retrieved chunks grow with tenure, so the same action costs more for a two-year customer than a two-week one.
Power users adopt the expensive path. They discover the feature that runs the big model and use it constantly.
Retention improves. Nothing changed except that fewer people leave, so the mix shifts toward long-tenured heavy accounts.
The architectural fixes are specific. Cap or summarise conversation history rather than replaying it. Cache the stable part of long prompts. Reserve the expensive model for requests that measurably need it. All three are ordinary engineering, and all three are much cheaper to do at 200 customers than at 2,000.
The forecasting fix matters just as much: model cost per account by tenure cohort, not as a blended average. A blended average hides case three completely. Forecasting revenue for an AI subscription product has the cohort mechanics, and it is worth doing the cost side with the same shape.
What to do this week
If you have not looked at this yet, the sequence is short:
Per-customer AI cost, last full month, sorted. Ten minutes.
Same number split by signup cohort. Another ten. This tells you whether you are in case three.
Check the top five accounts for a bug before you conclude anything about pricing.
Only then decide whether the answer is a limit, a price, or a rewrite.
Doing step three before step four saves a surprising number of teams from repricing in response to their own retry loop.
None of this needs to be dramatic. Negative margin on some accounts is normal in a product that includes a variable cost, and the mistake is not having a few of them, it is not knowing which of the three situations you are in. The broader picture of making AI products pay for themselves is mostly this: knowing your unit economics before the board asks.
FAQ
Should I add usage limits if some customers cost more than they pay?
Only after checking whether those accounts are outliers or the median, and after checking for a bug on your side. Limits are the right answer for a small tail of heavy users and the wrong answer for a pricing problem affecting everyone.
How do I know if my AI costs will keep growing?
Split cost per account by signup cohort rather than looking at a blended average. If older cohorts cost more per account than newer ones, cost is growing with engagement and you have an architecture problem, not a pricing one.
Is it better to raise prices or meter the AI feature?
Metering fits when AI is one component of a broader product and its cost genuinely varies with use. A price rise fits when the whole product is underpriced. Metering makes revenue harder to forecast, which is a real cost, not a detail.
How much can I realistically cut inference costs?
Caching, context trimming and routing simple requests to smaller models often produce substantial savings, but there is a floor. If your gross margin is deeply negative, optimisation buys time rather than fixing the model.
Should I tell customers their usage is expensive?
For a handful of outliers, yes, and early. A direct conversation with an upgrade path lands far better than a limit that appears without warning, and heavy users are often your most committed ones.
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.
