The bill that grows with use
An AI feature is billed by use, so its cost climbs as more people use it, while your servers, storage, and databases stay near the same figure each month. Maybe you know this already (see my post about AI-fatigue) The number that tells you whether the climb is fine is cost per request: your total AI spend for the feature, divided by how many times it ran. If the bill rises while cost per request holds steady, that is simply more people using the feature; a rising cost per request is the signal that something has changed, and that it is worth an hour this week to find out what.
Why the bill climbs while everything else holds flat
Most of your infrastructure is billed by time. A server costs about the same whether it handles one request an hour or a thousand, so once it is sized you can more or less predict the monthly figure. An AI feature is billed by the request, which changes the shape of the cost: it starts small and grows in step with use, and use tends to grow when the feature is doing its job.
There is a second reason this number surprises people. Building or tuning a model is a project with a clear start and end. Running it is open-ended. Once a feature gets real use, the day-to-day bill often passes the build cost within a few weeks and just keeps going.
The habit is to budget for the running cost from the start. Work out what a typical month of use looks like and base the number on that: if each use costs one cent and you expect 10,000 uses in a month, set aside €100, then add headroom, because use grows and there are always surprises.
Falling prices do not rescue you here. The price of a single request has dropped sharply over the past two years, and total bills have risen anyway, because usage has grown faster than prices have fallen. Ten times the traffic at half the price per request is still a bigger bill.
The one number to watch: cost per request
Cost per request is your total AI spend for the feature over a period, divided by the number of requests in that period. It tells you what the total bill cannot. A rising bill on its own is ambiguous. Cost per request separates the two things hiding inside it: more people using the feature, which is usually good, and each use costing more, which usually points to a regression.
Watch the trend, not the level, and check it weekly. A spreadsheet does the job: total AI spend and number of requests each week, and let it work out the rest. AI costs move fast, and a change that would take a quarter to show on a server bill can double a feature’s cost in a few days.
A few habits that keep it in proportion
None of these need a new tool. Each is worth checking against your own setup this week.
Switch off machines left running when nothing needs them. Development and staging environments left on overnight and at weekends are the most common quiet waste.
Batch the work that can wait. Jobs that do not need an answer this second are usually cheaper run together.
Send simple requests to a smaller model. Cheaper models handle routine work well, so keep the expensive one for the requests that need it.
Cap retries. Without a limit, one bug in a loop can turn into a large bill overnight.
Set a spend alert at 80 per cent of your budget. The major providers will not stop charging when you cross a limit you set, so the alert is your early warning: it gives you time to act before the cycle closes.
Check the maths before you scale
Before the feature grows, run its usage-driven cost at ten and a hundred times today’s traffic. A feature that costs a fraction of a cent per request under a flat subscription is a different business at several cents per request on the same plan, and the cheap moment to notice that is now, on a calculator, ahead of the invoice.
If cost per request will not fall as you grow, the pricing has to carry it. Usage-based or tiered pricing keeps revenue moving with the cost rather than trailing it. Say the feature costs you 2 cents per request and a customer uses it up to 1,000 times a month: you might price it at €25 a month for up to 1,500 requests, with 2 cents for each request beyond that. Revenue then grows with usage, and heavy users do not quietly cost you money. Running this sum before launch is what lets the price you set hold as the feature grows.
Keep an eye on cost per request, keep the habits above ticking over, and a bill that grows with success stays a number you can plan around.
