Every product roadmap this year has an AI feature on it. Most of them are costed as though the feature is free once it is built, which is the one assumption that is definitely false.
A generated image costs you money. A generated video costs you noticeably more. Unlike a database query, the cost does not fall as you scale — it is roughly linear in how much people enjoy your feature. So the feature's success and its cost are the same curve, and if you have not designed for that, popularity is the failure mode.
How much an AI feature costs to run, and who pays for it
There are three honest options.
Free and capped. Simple, and it works when the generation is cheap and occasional. You need a hard limit per user per period, enforced on the server, and you need to know what the worst-case bill looks like if every user hits the cap on the same day.
Bundled into a subscription. The comfortable one commercially, and the dangerous one operationally: a small number of heavy users can consume the margin of a large number of light ones. Only sane with a fair-use limit underneath, which means you are metering anyway.
Metered directly. Users buy credits, generations spend them. Transparent, scales with cost by construction, and the one most people avoid because it looks like more work. It is more work. It is also the only model where a viral week is good news.
What metering actually requires
If you go metered — and for anything involving video you probably should — the credit balance becomes money, and it has to be treated with the same care as money. The same care, in fact, as the funds held between a buyer and a seller: once a number in your database can be exchanged for something, sloppiness in it is theft in one direction or the other.
Deduct atomically. Two taps on a slow connection must not spend the same credit twice. The way to guarantee that is not to read the balance, check it in your code, and then write it back — that is a race with a queue of users behind it. It is to make the deduction one statement with the condition inside it, in a transaction: subtract the cost only where the balance is at least the cost. If nothing was updated, the user could not afford it, and the transaction rolls back cleanly.
Keep a ledger, not a number. Every movement — purchase, spend, refund, manual adjustment by support — is a row. The balance is the consequence of the rows, not a field somebody edits. The first time a customer asks where their credits went, you will either have an answer or an apology.
Refund failures automatically. Generation is asynchronous: queued, processing, then done or failed. Models time out, providers rate-limit, content filters reject. When that happens the credits go back, with their own refund entry explaining why. Charging someone for something that did not happen is the fastest way to turn a paying user into a former one, and support cannot keep up with it manually.
Put the model behind an interface
This one sounds like developer housekeeping and is really a commercial decision.
If your code calls the AI provider directly, then every test run costs money, so you write fewer tests, so the credit logic — the part that touches your revenue — is the least tested part of your product. That is precisely backwards.
Putting generation behind a single interface with a mock implementation alongside the real one means the whole economy of purchases, spends, failures and refunds is exercised end to end on every commit, for free. It also means you can change provider later without touching anything else, which matters in a market where the price and quality leaders change every few months.
The abuse question
Ask it early: what does someone do with your feature if they want to be a problem?
Someone will script it. Someone will use it to generate content you do not want associated with your brand. Someone will chargeback a credit purchase after spending the credits. You need a rate limit, an appropriate content policy enforced by the provider's safety settings and your own prompt constraints, and a decision about what happens to a balance bought with a reversed payment.
None of it needs to be elaborate at launch. It does need to exist at launch, because these are not hypothetical and they arrive in the first month.
A reasonable shape
For a marketplace we built, the AI studio ended up like this: credit packages you buy, three generation types with different costs, an asynchronous job with a real status, refunds on failure, a full transaction ledger, an admin-editable system prompt, and a free discussion mode that costs nothing so that people can work out what they want before they spend anything on producing it.
That last detail did more for the numbers than any of the others. Most of what users want from an AI feature is thinking, and thinking is cheap. Charge for the expensive part, and make the cheap part generous.
The uncomfortable question worth asking first
Does the feature need a model at all, or does it need a good default?
We have talked clients out of generation more than once, because what they actually wanted was a template, a sensible preset, and a search that worked. Those cost nothing to run, never hallucinate, and do not need a refund policy.
When the answer really is a model — and for image and video it usually is — the work is the plumbing around it: the ledger, the refunds, the limits, the mock that keeps your tests honest. That plumbing is most of the invoice, and it is the part that decides whether a popular feature makes you money or costs you money.
If you are costing an AI feature right now, send us the numbers before anyone writes code. We will tell you what the plumbing around the model is likely to cost, and occasionally that you do not need the model at all.