An LLM feature looks free right up until the monthly bill lands. Here is what actually drives per-user cost and where startups lose margin most often.
What a single request costs
The base formula is simple: request cost equals input token price times input token count, plus output token price times output token count. Output tokens cost several times more than input tokens with every provider, so the length of the model's answer moves the bill more than the length of your prompt.
If a feature generates long-form text, emails, descriptions, commented code, most of the cost sits in generation, not in whatever context you sent the model.
A user is not one request
The mistake nearly everyone makes early on: pricing a single API call and multiplying by user count. In reality one user makes several calls per session, and that changes the picture entirely.
A conversation grows with every turn: the fifth question in a chat drags the whole history into context, so you are no longer paying for one short question but for everything accumulated. An agentic flow where the model plans its own steps can make a dozen calls for one user task.
So the right unit is not the request, it is the session or the task as a whole. Work out how many calls one user action needs on average and multiply cost per call by that number, not by one.
What actually kills margin
Three things puncture unit economics most often.
Heavy users. Usage distribution is almost always skewed: a small slice of accounts generates most of the tokens. If the feature has a flat price, those accounts run at a loss and everyone else is quietly subsidizing them through the shared subscription price.
Retries. The model got it wrong, the app called again, then once more. Every attempt gets billed at full price, and the business metric only sees the successful final result, not the cost behind it.
Growing context in long sessions. A support chatbot that keeps the full conversation history pays for that history on every following message. Without trimming or summarizing it, one long session can cost several times what a short one costs.
How to work out a feature's cost
Gather three numbers over a representative period: average token spend per user action, average number of actions per user per month, and the share of failed calls that had to be retried.
The formula follows: monthly cost per user equals average number of actions, times average cost per action, times a retry adjustment, usually a multiplier between 1.1 and 1.3 if the feature has automatic retries built in.
Look at percentiles, not just the average. A median user might cost pennies while the 95th percentile costs several times more. Pricing off the average often hides exactly how much the most active slice of your audience is losing you.
How to price it without going negative
A flat subscription price works when usage variance across users is small. When variance is large, it is smarter to build a limit into the plan: a fixed number of requests per month at a fixed price, then an add-on or an upgrade beyond that.
A second working move is pricing in a buffer above today's model cost, not against today's price exactly, to cover a future price hike or a jump to a stronger model. Margin calculated flush against current API pricing tends to vanish the moment a provider changes its rates.
How to avoid missing a cost blowup
Running the unit economics once at launch is not enough. You need an ongoing view of where the spend actually comes from: which feature, which user, which model.
Claudexia tracks usage per API key, so you can hand out separate keys per feature or per customer segment and see which one is eating the budget. Sub-organizations with their own limits help once a team grows and there is more than one product: each gets its own budget and its own warning threshold, instead of one shared pool nobody personally owns.
In short
The cost of an LLM feature is not the price of one API call. Price it per session, not per request, watch percentiles alongside the average, and build in a buffer for the model getting more expensive. Splitting spend by key and by feature turns guessing into numbers.