Free tool · No email required
AI feature cost per user calculator
Every LLM pricing calculator on this search result takes two numbers, input tokens and output tokens, and multiplies them. That’s arithmetic you can do in a spreadsheet, and it answers a question nobody is actually asking. What a request costs barely matters. What a user costs per month does, and so does whether the feature still has a margin at the price already printed on your pricing page.
So this one starts from a usage shape rather than a token count, and it prices the four things that decide the real bill: the cached prefix, the conversation history that gets replayed on every call, the retries nobody forecasts, and the share of traffic a small model can serve. Then it divides the result into what you charge and tells you the gross margin and the break-even price. It updates as you type, it shows every line, and there’s no form.
The reasoning behind the model is in our piece on what an AI feature actually costs to run per user. Read that for the argument. Use this for the multiplication.
LLM cost per active AI user, per month
$0.00966 per model call, 6 calls a session, 20 sessions a month. A heavy user at 5x costs $5.80 over the same month.
| Line | Tokens | Rate / 1M | Per call |
|---|---|---|---|
| Prefix served from cache60% of the 4400-token system-prompt-plus-context prefix, at the cached-input rate. | 2,640 | $0.170 | $0.00045 |
| Prefix written to cacheThe misses. A miss on a cacheable prefix is a cache write, which some providers price above plain input rather than at it. | 1,760 | $2.13 | $0.00374 |
| Conversation historyReplayed in full on every call and never cacheable at the front of the prompt, because it is the part that changes. | 1,200 | $1.70 | $0.00204 |
| Generated outputPriced several times higher than input almost everywhere. Reasoning tokens bill here too, whether or not you display them. | 350 | $8.50 | $0.00298 |
| One successful callThe four rows above, added up. | 5,950 | – | $0.00920 |
| Retries and failures5% of calls run again. A schema violation, a timeout, a refusal you re-prompt around. All of them bill. | – | – | $0.00046 |
| Cost per model call | – | – | $0.00966 |
Rates are the blend of Claude Sonnet 5 at 70% and Claude Haiku 4.5 at 30%. Cost is linear in every rate, so blending the rate card and blending two separate call costs give the same answer. One table instead of two, with nothing approximated.
- Per session$0.00966 × 6 calls
- $0.0580
- Per active AI user, per month× 20 sessions
- $1.16
- Users on the feature5,000 × 60%
- 3,000
- Monthly LLM spendLow: everyone behaves like the model. High: a tenth of them behave like the 5x user and the rest behave like the model. The gap is the whole risk.
- $3,479 – $4,871
Margin, and where it breaks even
Gross margin here is tokens only. It’s the ceiling on the feature’s real margin rather than the figure itself. Hosting, the vector store, evaluation runs, support and the engineers all sit underneath it, and none of them are modelled.
- Gross margin on a user who uses it$25.00 of revenue less $1.16 of tokens. The strict view, and the one to design against.
- 95.4%
- Gross margin across every subscriber$0.70 of tokens per subscriber once the 40% who never open the feature are counted. The flattering view. Useful for the P&L, dangerous for a design decision.
- 97.2%
- Gross margin on the 5x user$5.80 of tokens against the same $25.00 seat. If this is negative and the first row is positive, you have a design problem rather than a monitoring problem.
- 76.8%
- Break-even price per userWhere tokens alone consume the entire seat price. A floor to price above, not a price. The 5x user breaks even at $5.80.
- $1.16
The price table, and its date
Dollars per one million tokens, read off each provider’s own published pricing page on 24 August 2026. These are list prices and nothing else: no committed-throughput agreement, no negotiated enterprise rate, no batch discount, no free tier. One row below already carries a scheduled increase, which is the shortest possible reason to distrust any pricing table that carries no date at all.
| Model | Input | Cached | Cache write | Output |
|---|---|---|---|---|
| AnthropicClaude Opus 5Anthropic prices a cache hit at 0.1x base input and a five-minute cache write at 1.25x, so a miss on a cacheable prefix costs more than plain input. | $5.00 | $0.500 | $6.25 | $25.00 |
| AnthropicClaude Sonnet 5The $2 / $10 launch pricing is now the standard price; the increase that had been scheduled for September 2026 was cancelled. | $2.00 | $0.200 | $2.50 | $10.00 |
| AnthropicClaude Haiku 4.5Same 0.1x cache-hit and 1.25x five-minute-write multipliers as the rest of the family. | $1.00 | $0.100 | $1.25 | $5.00 |
| GoogleGemini 3.1 Pro PreviewPrompts up to 200k tokens. Above that Google lists $4 input and $18 output, which this tool does not switch to automatically. Context-cache storage is billed per hour on top and is not modelled here. | $2.00 | $0.200 | $2.00 | $12.00 |
| GoogleGemini 3.7 FlashPublished through 31 December 2026. Google lists $1.50 input and $7.50 output from 1 January 2027, which is the clearest illustration on this page of why a price table needs a date. | $0.750 | $0.075 | $0.750 | $3.75 |
| GoogleGemini 3.5 Flash-LiteText, image and video input. Audio input is priced separately and is not modelled here. | $0.300 | $0.030 | $0.300 | $2.50 |
| OpenAIGPT-5.6 SolOpenAI caches automatically and bills a cache write at the standard input rate, so the write column equals the input column. | $4.00 | $0.400 | $4.00 | $20.00 |
| OpenAIGPT-5.6 TerraCached input at a tenth of the input rate, and no separate write premium. | $2.00 | $0.200 | $2.00 | $12.00 |
| OpenAIGPT-5.6 LunaSmall enough that on most request paths the output line dominates the bill entirely. | $0.200 | $0.020 | $0.200 | $1.20 |
| OpenAIGPT-5.4 miniA common routing target for classification, query rewriting and title generation. | $0.750 | $0.075 | $0.750 | $4.50 |
Sources, each of which is the provider’s own page rather than an aggregator: Anthropic pricing documentation, Google Gemini API pricing, OpenAI API pricing. If you’re reading this long after 24 August 2026, check them again and use the custom rate card rather than trusting the table.
How to read the output
Read the four token rows before you read the total. One of them is almost always two-thirds of the bill, and which one it is decides what you do next. If the output row dominates, the lever is verbosity and max-tokens, and no amount of prompt trimming will help. If the history row dominates, the lever is how much transcript you replay. If the cache-write row dominates, your prefix is churning and something volatile is sitting at the front of it. Only once you know which row is heavy is there any point arguing about the total.
The three margins are not interchangeable
The tool reports margin three times on purpose. The margin across every subscriber is the flattering one, because the people who never open the feature pay full price and cost nothing. It belongs in the P&L and nowhere near a design decision, since adoption rising from 40% to 80% is a success that halves it. The margin on a user who actually uses the feature is the one to design against. The margin on the heavy user is the one that decides whether the business survives its own growth, and it’s the number a pilot cohort will never show you, because pilot cohorts are picked for enthusiasm rather than volume.
Break-even price is a floor rather than a price. It’s the point at which tokens alone consume the entire seat, with nothing left for infrastructure, support, or the people who built the thing. If your actual price is within about 3x of break-even, you don’t have a pricing problem yet. You have one scheduled.
The mistakes people make with this number
Forecasting per message instead of per call. An agent that plans, calls a tool, reads the result and re-plans issues four or five model calls for one visible response. Every one of them replays the transcript. Count calls, and count the retries separately, because a schema violation that triggers a re-run has just doubled that turn at full price.
Believing the cache hit rate you assumed. Caches key on an exact prefix, so a timestamp, a user name or a randomised few-shot example at the top of a system prompt takes the hit rate to zero without producing a single error. Check the cached-token field your provider returns in the usage object. If it reads zero across repeated calls, something in your prefix is moving.
Letting non-user traffic in.Evaluation suites, CI runs and load tests bill to the same account and, untagged, land inside your cost-per-user metric. We’ve seen this account for a double-digit share of a monthly bill before anyone noticed, and it’s a tagging fix rather than an engineering one.
Treating a pre-launch number as a forecast. Sessions per user per month is behavioural. It depends on where the feature sits in the interface, whether it’s opt-in, and whether it’s fast enough to feel free, and a pre-launch guess can be wrong by 5x. Being wrong by 5x on the dominant term means the output isn’t a prediction. Treat it as a sensitivity model instead, and ask it one question: is there any plausible usage level at which this feature is margin-negative at our intended price? If the answer is no across a 10x range of session counts, ship and instrument. If the answer is yes at 3x, fix the design before launch.
The fix is usually a hard per-user ceiling metered in your own database rather than the provider dashboard: a soft alert at 3x your modelled average, a degradation step at 5x, a hard stop with an honest message at 10x. It converts an unbounded liability into a known one, which is the thing that makes seat pricing survivable at all. The reasoning behind that, and the four levers that move the number before launch, are in the companion article.
Keep reading
- What an AI feature costs to run per userThe request-path reasoning behind every default in this calculator, at length.
- AI architecture and readinessCache-friendly prompt ordering, routing and per-user metering are cheaper to design in than to add.
- MVP cost estimatorWhat the feature costs to build, as opposed to what it costs to run. The other half of the question.
Design it in, or pay to add it.
Prompt ordering, a routing layer and per-user metering are cheap on day one and expensive in month nine, because reordering a prompt means re-running an evaluation set you may not have. Tell us what the feature does and we’ll tell you which of those you actually need.