{"id":614,"date":"2026-09-09T03:00:00","date_gmt":"2026-09-08T23:00:00","guid":{"rendered":"https:\/\/neomeric.com\/blog\/?p=614"},"modified":"2026-09-07T03:08:27","modified_gmt":"2026-09-06T23:08:27","slug":"ai-product-cost-model","status":"publish","type":"post","link":"https:\/\/neomeric.com\/blog\/ai-product-cost-model\/","title":{"rendered":"How to Build an AI Product Cost Model in 6 Steps"},"content":{"rendered":"

An AI product cost model is a spreadsheet that predicts what one user, one request and one month will cost you before you have the traffic to find out the hard way. Most founders skip it, then discover that a feature which cost cents in the demo costs dollars per session at scale. Gartner warned in 2024 that leaders who don’t understand how generative AI costs scale can make a 500% to 1,000% error in their cost calculations<\/a>. This how-to builds the model in six steps, using the same structure Neomeric puts in front of every founder during a Build Sprint.<\/p>\n

Why does an AI product need a cost model before launch?<\/h2>\n

Because AI costs are variable, per-request and driven by user behaviour rather than by your headcount. Traditional SaaS cost of goods is mostly flat: a database, some compute, support staff. An AI product’s largest cost line moves with tokens, and tokens move with prompt length, retrieval depth, agent loops and how chatty your users are. Gartner has since forecast that a large share of generative AI projects could exceed their budgets by 2028<\/a>, and the cause is nearly always unmodelled usage rather than a wrong price per token. A cost model turns that unknown into a set of assumptions you can test in week one.<\/p>\n

Step 1: Define your unit of value<\/h2>\n

Pick the single thing a customer pays for and that your model will price everything against. It might be a conversation, a document processed, a call answered, a report generated or a seat per month. Everything else in the spreadsheet is expressed per unit. If you cannot name the unit, you are not ready to price the product, and the cost model will tell you that quickly.<\/p>\n

Step 2: Trace one request end to end<\/h2>\n

Write down every model call that happens when a user triggers one unit of value, in order. A typical retrieval-augmented request has a query rewrite, an embedding call, a retrieval step, a main generation call and often a validation or guardrail call. An agentic request may loop several times, each loop carrying the growing context. For each call, record the model, the expected input tokens (system prompt, retrieved context, history, user message) and the expected output tokens. Be honest about history: a chat that carries 20 turns of context costs many times more per message than a fresh one.<\/p>\n

\n

Free: The Australian AI MVP Cost Guide 2026<\/h4>\n

Honest cost benchmarks, the hidden costs vendors don’t quote, and a 10-line scoping worksheet.<\/p>\n

Get the free guide<\/a><\/div>\n

Step 3: Price each call, including caching and residency uplifts<\/h2>\n

Multiply tokens by the provider’s current list price for input and output separately, then apply the discounts and uplifts that actually apply to your topology. Two matter most. Prompt caching cuts the cost of repeated context sharply: Anthropic’s prompt caching documentation<\/a> sets cache reads at one tenth of the base input price, with a premium on the initial cache write, which means a long stable system prompt gets cheap after the first call. Residency can move the other way: OpenAI’s data controls documentation<\/a> notes a 10% uplift on data-residency endpoints for newer models. Do not hard-code prices; put them in a lookup table, because they change and because your deployment option<\/a> may change with them.<\/p>\n

Step 4: Model usage, not just price<\/h2>\n

This is the step that separates a real cost model from a pricing-page calculator. For your unit of value, estimate three usage figures: how many units an average customer consumes per month, what the 90th-percentile customer consumes, and how the average request grows over time as users learn to lean on the product. Build the spreadsheet so each of those is a single cell you can change. Then add a row for “wasted” calls: retries on errors, abandoned sessions, users who paste an entire PDF into the chat. In our experience that waste row is rarely below 10% of tokens and is often the difference between a healthy and an unhealthy margin.<\/p>\n

Step 5: Add the costs that are not tokens<\/h2>\n

Token spend is the visible line; the rest is where budgets quietly fail. Include vector database or search infrastructure, embedding refresh when documents change, observability and logging storage (prompt logs are large), evaluation runs every time you change a prompt or model, guardrail and safety calls, and the on-call engineering time for a service that fails in new ways. If you self-host any model, add GPU hours at your expected utilisation, not at 100%. We covered the levers for pulling each of these down in our guide to cutting AI API costs<\/a>.<\/p>\n

Step 6: Compute margin at three volume points and stress-test it<\/h2>\n

Now compute cost per unit and gross margin at launch volume, at your 12-month target and at ten times that. A product that is 85% gross margin at launch and 40% at ten times volume has a routing or architecture problem you want to discover now, not after a pricing announcement. Stress-test the model by doubling context length, halving cache hit rate and moving your main model one tier up in price. If the margin survives all three, ship. If it does not, the fix is usually one of: a cheaper model on the easy path, tighter context, caching, batch processing for anything that is not interactive, or changing the pricing unit so heavy users pay for heavy use. Choosing the right model tier for each path is its own decision, and we walk through it in how to choose an AI model for your app<\/a>.<\/p>\n

What does a minimal cost model spreadsheet contain?<\/h2>\n

Five tabs are enough. A Prices tab with a row per model and per token type, including cache and batch multipliers. A Request Trace tab listing each call with tokens in and out and a lookup to price. A Usage tab with units per customer per month at average and P90 plus a growth factor. A Non-Token Costs tab with infrastructure, evals and engineering time. A Summary tab that reports cost per unit, cost per customer and gross margin at three volumes. Keep every assumption in a named cell with a note on where it came from, so the model is auditable when a co-founder or investor asks how you got the number.<\/p>\n

How does Neomeric use this with clients?<\/h2>\n

Neomeric, a Melbourne-based AI product and consulting company and the team behind NeoMind, Australia’s onshore AI teammates platform, builds this model for every product in the 2-week Build Sprint, populated with measured token counts from the working prototype rather than guesses. It is one of the sprint deliverables the founder keeps regardless of whether they continue to a pilot with us. If you would like a second set of eyes on your numbers, book a free scoping call on the Neomeric contact page<\/a>.<\/p>\n

Frequently asked questions<\/h2>\n

How accurate can an AI cost model be before launch?<\/h3>\n

Accurate enough to make decisions, provided the token counts come from a working prototype rather than estimates. Measure a few dozen real requests, take the median and the 90th percentile, and use those as your base assumptions. The remaining uncertainty is in usage volume, which is why the model should be built to update as real data arrives.<\/p>\n

What is the biggest cost driver most founders miss?<\/h3>\n

Context growth. Conversation history, retrieved documents and agent loops all increase input tokens per request over the life of a session, and input tokens usually dominate total spend in retrieval-heavy products. Model the average request as it will look after ten turns, not after one.<\/p>\n

Should the cost model include engineering time?<\/h3>\n

Yes. Evaluations, prompt changes, model upgrades and on-call incidents are recurring costs that scale with product complexity. Leaving them out overstates gross margin and understates the cost of every architectural shortcut.<\/p>\n

How often should the model be updated?<\/h3>\n

Refresh prices whenever a provider changes them, and refresh usage assumptions monthly from production logs. Re-run the three-volume margin check before any pricing change, model migration or major feature launch.<\/p>\n