LLM cost per user: the calculator, the formula, and the margin math

Quick answer: the formula and where it lands.

Cost per user per month = requests per user per month × (input tokens per request × input rate + output tokens per request × output rate) ÷ 1,000,000. Every LLM bill reduces to that one line. The per-token rates are public, so the whole calculator exercise is estimating three numbers about your own product: how often an active user triggers the model, how many tokens each request carries in, and how many come back out. For a typical chat-style SaaS feature, an engaged user triggers roughly 150 requests a month, and each request carries about 2,000 tokens in (prompt template, retrieved context, replayed history) and 400 tokens out. At current flagship rates that user costs between roughly $1.30 and $2.60 a month in model spend; on a budget-tier model the same user costs under $0.20. That spread, more than any prompt trick, decides whether your AI feature has software margins or reseller margins. The sections below turn the formula into a working calculator: what each input actually means, a full worked example for a freemium SaaS, a per-model comparison table, and the levers that genuinely move the number.

The four inputs, and how to get real values for them.

Resist the urge to guess these numbers from intuition. Every OpenAI-compatible chat completions response includes a usage object with exact prompt and completion token counts, so a week of logging gives you measured distributions instead of estimates. That distinction matters because cost per user is not one number: usage is heavily skewed, and the average sits well below the users who will actually shape your bill. Segment into light, typical, and power profiles before you multiply anything, then price each segment separately.

• Requests per active user per month. Pull this from your own logs and count model calls, not user sessions. One "send" in your UI can fan out into several calls once you add tool use, query rewriting for retrieval, or a moderation pass.
• Input tokens per request. The sum of your system prompt, retrieved context, the conversation history you replay, and finally the user's message. In most products the user's own text is the smallest slice of the request.
• Output tokens per request. Bounded by your max_tokens setting and shaped by product design. A summarizer that returns 150 words behaves nothing like an open-ended chat that rambles for 800.
• The model's rates. Published per million tokens, one price for input and a higher one for output. Across the catalog used on this page, output rates run two to six times the input rate, so verbose responses punch above their weight.

Worked example: a freemium writing assistant.

Make it concrete: an AI writing assistant priced at $15 a month, with 10,000 monthly active users and 800 paying seats. Each request carries a 600-token system prompt, about 1,100 tokens of document context, and a 300-token user instruction, so 2,000 tokens in and roughly 400 back out. Users split about 70% light, 25% typical, and 5% power, and the table prices each profile on a flagship (gpt-5.4) and a budget model (deepseek-v4-pro). The blended row is the one that matters. At the 70/25/5 mix, the average active user runs about 88 requests a month, which costs $0.78 on gpt-5.4 and about $0.10 on deepseek-v4-pro. Scale by 10,000 MAU and the same product pays roughly $7,800 a month on the flagship or about $970 on the budget model. Against $12,000 of MRR from 800 paying seats, model spend alone eats about 65% of revenue in the first case and about 8% in the second: same feature, same users, gross margin of roughly 35% versus roughly 92%. Notice who pays for it, too. Each paying seat carries its own usage plus that of about 11 free users, which is why free-tier design belongs in the cost model from day one.

Why the per-user number surprises people.

None of these are billing errors; they are the mechanics of the API. The pattern to internalize is that cost tracks tokens processed, not user actions, and most tokens in a modern product are ones no user ever typed. It is also why two products with identical user counts on the same model can have bills ten times apart.

• Users do not send tokens, your prompt template does. A 20-word question rides on top of a system prompt, retrieval chunks, and history, so the request the API bills is often 50 to 100 times larger than what the user typed.
• Multi-turn chat re-bills the past. Turn 12 resends turns 1 through 11 as input, so the marginal cost of a conversation grows with its length even when the user's messages stay short.
• Free users bill at exactly the same rate as paying users. An unthrottled power user on the free tier can burn more in tokens than a paid seat brings in.
• Usage follows a power law. A small share of users generates a disproportionate share of tokens, and a calculator fed with averages will underprice exactly the users who hurt you.
• Regenerations, retries, and abandoned streams still bill. Every click of "try again" is a full-priced request, and tokens already streamed are paid for even if the user navigates away.
• Output is the expensive direction. Output rates run several times input rates, so features that produce long responses drift to the top of the bill without any change in traffic.

The same user on every model: a cost comparison.

Here is the typical profile from the worked example, 150 requests a month at 2,000 input and 400 output tokens each, priced across the catalog. Read the last column as a margin question: what share of a $15 subscription does one engaged user's model bill consume? The jumps between tiers dwarf anything you will win by tuning prompts. Moving one tier down this table routinely cuts per-user cost in half or better, and the gap between the top and bottom rows is more than fifty to one. This is why model routing, covered next, is the first lever worth engineering time, and why the calculator should always be run against at least three candidate models before a feature ships.

Seven levers that actually cut cost per user.

Work the list top down. Metering makes everything else measurable, token budgets remove the tail risk, and the template and output caps trim a real slice of every request. The compounding wins, though, are the two structural levers at the bottom: sending most traffic to a cheaper tier and paying a lower rate on every token that remains. Applied to the worked example, routing plus a lower unit rate moves the blended user from $0.78 toward the $0.10 neighborhood, which turns the same $12,000 of MRR from a thin-margin business into a comfortable one.

• Meter per user from day one. Log the usage object from every response keyed by your internal user ID. You cannot manage a unit cost you cannot see, and retrofitting attribution after launch is painful.
• Give the free tier a token budget, not a request cap. A request cap treats a 500-token question and a 15,000-token document rewrite as equal, so your worst case stays unbounded. A daily token budget per free user puts a hard ceiling on it.
• Shrink the request template. Audit the system prompt line by line, cap retrieved context at the chunks that measurably improve answers, and summarize or window conversation history instead of replaying all of it.
• Cap output per feature. Set max_tokens to what each feature needs; a headline generator does not need 2,000 tokens of headroom. Because output rates run several times input rates, this lever is stronger than it looks.
• Route by task, not by habit. Default to a budget model and escalate only the requests that need flagship reasoning. In the table above, that swaps most of a $1.32 user for a $0.16 one.
• Cache what repeats. Identical requests such as onboarding examples and canned suggestions can be served from your own cache, and provider-side prompt caching discounts the stable prefix of your template on repeat calls.
• Lower the unit rate itself. Routing traffic through a cheaper OpenAI-compatible endpoint changes the rate column without touching your code paths. APIsRouter, for example, lists global models 20% below official prices and Chinese models below their official rates, billed pay as you go with no subscription.

Build the calculator into your stack.

The spreadsheet version of the formula fits in a dozen lines of Python. Plug in your own request profiles and the rates of the models you are evaluating: The static script answers "can we afford this feature". The production version replaces assumptions with measurements: tag every request with your user ID, store the token counts the API already returns, and cost per user becomes a database query instead of an estimate. Aggregate it weekly by segment and the calculator maintains itself.

RATES = {
    # USD per 1M tokens: (input, output)
    "gpt-5.4": (2.00, 12.00),
    "claude-sonnet-4-6": (2.40, 12.00),
    "claude-haiku-4-5": (0.80, 4.00),
    "glm-5": (0.514, 2.314),
    "deepseek-v4-pro": (0.3915, 0.783),
    "deepseek-v4-flash": (0.126, 0.252),
}

def cost_per_user(model, requests, tokens_in, tokens_out):
    rate_in, rate_out = RATES[model]
    per_request = (tokens_in * rate_in + tokens_out * rate_out) / 1_000_000
    return requests * per_request

# Typical profile: 150 requests of 2,000 in / 400 out
for model in RATES:
    monthly = cost_per_user(model, 150, 2000, 400)
    print(f"{model:<18} {monthly:.2f} USD / user / month")

FAQ