Price a new AI feature and someone will ask what it costs before the feature exists. The cloud bill doesn’t help. It’s a total with no unit behind it, and it only shows up after the feature ships. The vendor’s pricing page times an estimated token count doesn’t help either. It’s a guess that stops being true the first time usage shifts. Finance’s spreadsheet has last quarter’s spend, not this feature’s inputs, and engineering’s back-of-envelope math has the inputs but never gets checked against real usage.
This calculator answers cost per request, cost per active user, and cost per subscriber before a line of code is written. Set the model, the input and output token split, the cache hit rate, and requests per active user, and it returns the number finance is going to ask for anyway. I built the version this is drawn from at the direct request of a CFO, CTO, and CPO who needed product teams to model an AI feature’s economics before engineering committed to an architecture.
What it calculates
- Cost per request: the base unit, broken out by model and by input/output token mix
- Cost per active user: request volume per user times cost per request, so a growth forecast has a cost line under it
- Cost per subscriber: cost per active user divided by the share of subscribers who are active, the number that actually feeds a pricing decision
- Break-even usage: the request volume where a per-seat price stops covering its own inference cost
- Cache-adjusted cost: the same numbers with a cache hit rate applied, since a cached read runs roughly a tenth of an uncached one and most feature-level estimates skip it entirely
Try the calculator
Calculator embed pending. This section holds the interactive tool: model, input/output token split, cache hit rate, and requests per active user in; cost per request, cost per active user, cost per subscriber, and break-even usage out.
What goes into the numbers
- Model and tier. Swapping a feature down a pricing tier changes the token price, not necessarily the token count. The calculator prices both.
- Token split. Output tokens typically run three to five times the input price, so a feature that generates long responses costs more per request than its input size suggests.
- Cache hit rate. A cached read costs roughly a tenth of an uncached one. A feature with repeated context, like a chat assistant reusing a system prompt, should never be priced on uncached rates alone.
- Requests per active user. The number that turns a per-request cost into a per-user one, and the one most launch estimates skip.
- Retries and eval overhead. A feature with a retry-on-low-confidence step or an automated eval pass pays for those calls too, and they belong in the estimate, not in a surprise at the first invoice.
Built from production, not list prices
The model behind this page was built for a Fortune-500 financial data company managing eight figures of annual AI and cloud spend, so product teams could price a feature before engineering committed to an architecture. The inputs, model, token split, cache hit rate, and quality benchmarks, are the same ones that decided which model shipped on production AI products there. This page runs the public, abstracted version of that model.
Use it before you build, not after
The team that skips this step ships the feature, waits for the first invoice, and learns the unit economics after the pricing page is already public. Running the numbers first turns a pricing decision into an input instead of a guess. If the calculator surfaces a number the roadmap can’t absorb, that’s worth knowing before the sprint starts, not during the postmortem.
For the model built out further, with the reporting path finance runs on its own, see FinOps consulting for AI products. The rest of that practice is on the home page.
Start
Run the numbers above. If the result changes what you’d ship or how you’d price it, email nick@nparr.com with the feature and the number the calculator gave you. I’ll reply with whether a two-week scoping makes sense.