"how much does the ai cost to run?" is the question almost every client asks, and most builders answer it vaguely. it deserves a precise answer, because the shape of the cost is not what people expect.
volume is the driver, not size
the instinct is to worry about long messages. in practice it's the number of requests that moves the bill, far more than the length of any one of them. a thousand short interactions cost more than a handful of long ones. when you're estimating what a feature will cost, count the requests you expect, not the words.
only the hard stop before the model is free
this is the part worth internalising. you can reject a request for free only if you reject it before it reaches the model. the moment a request hits the model, it costs tokens, even if the model's reply is a polite refusal. so any sensible design stops abuse and runaway loops at the edge, ahead of the model, rather than relying on the model to decline. an in-band refusal still shows up on the invoice.
what that means for pricing a chatbot
a few things follow directly. include a sensible api credit in the build so early usage is covered. set rate limits per visitor so one bad actor, or one broken script, can't run up a bill. and put the hard stops before the model, not after. these aren't optimisations to bolt on later. they're how you keep a chatbot's running cost predictable from day one.
rough, honest numbers
with the caveat that real figures depend entirely on traffic: a low-traffic site chatbot can run from pennies to a few pounds a month. a busy one costs more, scaling with the requests it serves. the exact number matters less than the principle, which is that it should always be disclosed and never buried. you should know roughly what a feature costs to run before you commit to it.
anyone who won't give you that number is either guessing or hoping you won't ask.