// ARTIFICIAL INTELLIGENCE
How many models, how much money? Costing AI
6 min readnijitech
Per-transaction cost is small and invisible in a pilot; multiplied by volume it decides the entire invoice. A practical way to measure it and bring it down.
Full post
AI cost is one of the most frequently misjudged lines in a budget. Not because the formula is complicated, but because of a simple illusion: what you pay during a pilot is so small that nobody dwells on it. Once the system reaches production, that same small number gets multiplied by volume and becomes the whole invoice.
Three numbers decide the cost
The model cost of an AI system is really the product of three numbers: calls per transaction, text processed per call, and the unit price of the chosen model. Double any one of them and the invoice doubles; double all three and it goes up eightfold.
Questions to ask while budgeting
- How many model calls does one job need — one, or five chained together?
- How much context is sent per call, and is all of it necessary?
- Does this job really want the strongest model, or does it go there out of habit?
- If volume goes up tenfold, which of the three numbers grows?
Sending every job to the strongest model
Sorting a text into one of two categories and running a multi-step analysis do not require the same capability. But if a single model name is written into the application code, both go to the same place. Simple jobs like classification typically make up the bulk of total calls; routing those to a smaller model erases a noticeable share of the invoice outright.
Latency is the invisible half of cost
Cost accumulates in waiting time as well as on the invoice. Every second a user waits for a response lowers how often that feature gets used. A smaller model is usually both cheaper and faster — which means these two improvements often come out of the same decision.
Running part of the work close to the user changes the same equation. A transaction that never reaches a central server produces neither latency nor a call charge.
Where you write the decision matters
If the knowledge of which job goes to which model is buried in application code, every price change and every new model becomes a development task. Had the same decision lived in a routing layer, it would be a configuration task. Models age; the pipeline stays.
In short
Four practical ways to lower cost
- Route simple jobs to a small model — most of the volume is there
- Trim the context you send; all of it is rarely needed
- Count latency as a cost line, not a separate topic
- Write model selection into configuration, not code
Applied together, the gain is not a few per cent but a multiple — and none of the four requires giving up accuracy.
From the glossary: Model orchestration · Edge scaling