Traditional software has a build cost and a hosting cost. Once it exists, an extra thousand users is close to free.
AI features do not work like that. Every single use costs money, and the bill scales with success. A feature that delights people is a feature that is costing more every month, which is a strange and unfamiliar shape for a product decision.
Almost nobody calculates this before shipping. The demo works, the model is cheap per call, the number looks small, and nobody multiplies it by the number of times a year it will run.
Here are real numbers from systems we built, what they cost, and the four things that actually moved them.
Start by knowing the number
The first discipline is boring and it is the one that matters: record the cost of every call, including the ones that fail.
On BiliMind, our AI course generator, one client wraps every model call and writes a row with real token counts and cost on every call, success or failure. That is not accounting hygiene for its own sake. It is the instrument that makes every decision below possible, because you cannot optimize a number you do not have.
Failures matter especially. A retry loop that silently doubles your cost per successful result will never show up in an average anybody looks at.
Real numbers
A generated course
BiliMind produces courses in 20 languages across 27 lesson formats. Measured during development:
- A 12–20 node course outline took 3–6 minutes and about $0.03.
- Each expanded lesson cost roughly one cent.
Three cents for an outline sounds like nothing. But a course with thirty lessons is thirty more cents, and the interesting decision falls out of the ratio rather than the absolute numbers.
Planning a course is free for the user. You pay only for lessons written in full. Expansion is per-lesson and opt-in. That product decision is a direct consequence of the measured cost: the cheap, high-value step is given away, and the step that scales linearly with usage is the one attached to money.
There is a second decision in the same numbers. The expensive model tier writes only the outline — on the reasoning that structure is the part worth paying for — while a cheaper tier expands lessons, regenerates and grades. Most of the calls run on the cheap tier. The quality-critical minority run on the expensive one.
A research and writing pipeline
The Finkonkurs AI content pipeline produces a 220–380-word encyclopedia entry plus an FAQ per entity, in Russian and English, from three parallel web-grounded research passes.
Three measured findings changed its economics:
- Gemini 3 Flash matched 3.1 Pro quality at roughly a quarter of the cost for this task. Not for every task — for this one, tested.
- Web search was about 80% of the per-generation cost. That is the kind of fact that reorders a whole roadmap: the expensive part was not the writing, it was the looking up. Exchange and network descriptions moved off the model that was doing it.
- On people research, skipping the identify step for an already-known person cut $0.16–0.25 of a $0.74 dossier to about $0.02.
That last one is the most transferable. A large share of AI cost is spent re-deriving things the system already knows.
A voice conversation
The Bronjoy AI receptionist handles a booking by voice in Uzbek and Russian. A full three-turn booking cost about 120–150 so'm — roughly one US cent in test calls.
Latency and cost moved together there. Transcribing first and then reasoning added 1.8–2.7 seconds per turn on phone-quality audio, so audio goes straight to the model instead. And edge-tts produced first audio in 0.5 seconds against 6.6 seconds for the alternative — a 13x difference in the thing a caller actually experiences.
The four levers
Every cost reduction we have made falls into one of four categories.
1. Use the cheap model for most of the work
Not one model for everything. Match the tier to the step.
BiliMind pays for structure and economizes on expansion. Nomadeo runs one perception call per inbound message, returning language, intent, signals, entities, candidate facts and injection suspicion in a single structured response — and keeps model reasoning off by default, enabling it only for objections, negotiation and closing. The expensive mode exists and is rationed to the moments that justify it.
2. Do not pay twice for the same thing
The single largest saving available, and it is architectural rather than clever.
Both Finkonkurs and BiliMind enforce one payer: only the development stage dispatches paid runs, and production is transform-only — it reads the shared database but never dispatches scrapes or spends AI credits. The same text is applied from a shared ledger without paying again.
For a normal business the equivalent is caching. If two customers ask the same question in the same week, you should be paying for one answer. If your product description generator is asked twice for the same product, the second one should be free.
3. Cut the expensive step, not the cheap one
The Finkonkurs finding — web search at 80% of cost — is the pattern. Before optimizing prompts, find out which step dominates. It is frequently not the one you assume, and it is frequently something adjacent to the model rather than the model itself: search, image processing, a long document being resent on every turn.
4. Fail early and loudly
A run that proceeds through five expensive steps and produces something unusable has cost you all five.
The Finkonkurs pipeline has a research guard: the run aborts before synthesis if any pass returns rate-limited, unfunded or empty. Currencies need all three sources; exchanges and networks at least two. And the research nodes capture HTTP status, so a 429 or a 403 fails the run with a reason instead of publishing a stub over an existing description.
That second half is a cost saving and a quality protection at once. The expensive failure is not the wasted call; it is the bad output that reaches production and has to be found and undone.
Caps, and degrading instead of stopping
Optimization lowers the average. It does not protect you from the bad month — a traffic spike, a loop, an abusive user, a bug that retries forever.
Nomadeo's approach is the one we would recommend for anything customer-facing. Spend is capped globally and per tenant. Past a cap, the agent degrades step by step: cheaper model, then cache-only, then human. Cost is accounted in micro-USD, and managers see only opaque labels — "fast", "balanced", "deep" — rather than model names.
Two things in that are worth copying. Degrade rather than switch off, because a feature that vanishes is an outage while a feature that gets slightly less clever is an inconvenience. And hide the model names from the operator, so the product decision stays yours when a provider changes its lineup.
Add hard limits at the edge too. The receptionist demo caps sessions at 30 turns or 10 minutes, and 20 sessions per IP per hour — limits that exist to make the worst case finite.
Do the arithmetic before you build
Four numbers, on one page, before anybody writes code.
- Cost per use. Run the real prompt on real data twenty times and take the average, including retries. Do not estimate from a pricing page.
- Uses per month, at the volume you expect if it works — not today's volume.
- Monthly cost = 1 × 2. Then triple it, because the first version is always more expensive than the optimized one and adoption is usually lumpy.
- What it replaces or earns, in the same units.
If the honest answer is close, build the narrower version. If the cost per use is more than a few percent of the value of the outcome, the feature needs a different design — usually a cheaper model, a cache, or a human doing the rare expensive cases.
And put the meter in from day one. A feature you cannot cost is a feature you cannot manage, and the moment you need the number is the moment the bill has already arrived.
Our AI integration and automation work starts at $299 and runs one to three weeks, and per-use economics are part of the workflow audit rather than something discovered in month two.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Are these costs not falling fast enough to ignore?
Per-token prices have fallen a long way and will likely keep falling. Two things stop that from solving the problem. Usage grows to fill the budget — cheaper calls mean more calls, longer context and more steps. And your cost is not only tokens: search, storage, retries and the human review queue do not follow the same curve.
Should we self-host a model to avoid per-call costs?
It converts a variable cost into a fixed one, which is only a win above a certain volume — and it adds operational work most small teams should not take on. The honest test is whether your monthly API spend exceeds what a competent person would charge to run the infrastructure. Below that, hosted is cheaper all-in.
How do we stop users from running up the bill?
Rate limits per user and per period, caps with graceful degradation, and attaching the expensive step to a deliberate action rather than to page load. BiliMind's structure is a clean example: browsing and planning are free, and the step that costs money is the one the user explicitly asks for.
Is it worth optimizing before we have users?
Measure before you have users; optimize after. Build the cost logging in from the start because retrofitting it is annoying, then let real usage tell you which step dominates. Optimizing an assumed bottleneck is how the Finkonkurs team would have spent a week on prompts while search quietly consumed 80% of the bill.
What is the most common mistake?
Sending the entire conversation history, or an entire document, on every single turn. It is invisible in a demo with three messages and it is the dominant cost in production with thirty. Check what you are actually sending before you change anything else.
