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.

1. Usage shape

A model call, not a user-visible message. An agent that plans, retrieves and then answers is three calls, and the calls are what bill.

The subscribers who never open it still pay you, which is why the margin is reported twice below: once on a user who uses the feature, once across the whole base.

Sessions per user is the input you know least about before launch and the one with the widest variance. It’s also the dominant term. Move it by 5x and watch what happens to everything else.

2. Token budget per call

Split into its parts, because the parts are priced differently. The first two are byte-identical across calls and therefore cacheable; the third changes every turn and therefore isn’t.

History is the average across a session, not the last turn. It starts at zero and grows, so a six-turn session doesn’t cost six times the first turn. It costs the sum of a growing prefix. Tool results join the transcript too.

Hit rate applies to the system-prompt-plus-context prefix only, not to all input tokens. A timestamp or a user name at the top of a system prompt takes it to zero, because caches key on an exact prefix.

3. Models and routing

List prices as published on 24 August 2026, linked to their sources further down this page. The order is alphabetical by provider and is not a recommendation.

Route by task, not by a difficulty score. Query rewriting, classification and title generation have knowable quality bars; the answer the customer reads doesn’t. Set this to zero if everything runs on one model.

4. What you charge

Your price, not ours. This is the input that turns a token count into a business question, and it’s the one no competing calculator asks for.

AI feature usage is a power law, so the mean describes almost nobody. The default of 5x is a modelling assumption, not a measurement: it stands in for a user who runs five times the sessions. Replace it with your own percentile the week you have one.

LLM cost per active AI user, per month

$1.16

$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.

Cost of one model call, broken into cached prefix, cache writes, conversation history, output and retries, showing tokens and the blended rate applied to each.
LineTokensRate / 1MPer 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.

Published list prices in dollars per million tokens for the models offered in this calculator, showing input, cached input, cache write and output rates by provider.
ModelInputCachedCache writeOutput
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.

What this cannot do

It prices tokens, not systems

No embeddings, no vector store, no reranker, no fine-tuning, no hosting, no observability, no evaluation runs, no engineers. On a retrieval feature the embedding and index bill is small next to the model bill and the engineering bill is not, so the number here is a component of your cost of goods rather than the whole of it.

Token counts are approximations

Tokenisers differ by model, so the same text is a different number of tokens depending on where you send it. Anthropic’s own pricing documentation notes that its newer tokeniser produces roughly 30% more tokens for the same text than the previous one. Switching models can therefore move your bill even when the rate card looks identical. Count with your provider’s own endpoint before you trust a forecast.

List prices, on one dated day

No committed-throughput agreements, no batch rates, no provisioned capacity, no negotiated enterprise pricing, and no cache storage fees where a provider charges them by the hour. Prices move in both directions and sometimes on a published schedule. The table carries its date for exactly that reason, and the custom rate card exists so the tool outlives it.

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.

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.