How to Price an AI Product When You Have Real Usage Costs

Most software advice assumes a comfortable fact: once the product is built, serving one more customer costs you almost nothing. That is why software companies can offer generous free tiers and flat monthly prices without much worry. The tenth user and the ten-thousandth user cost about the same to serve, which is close to zero. AI products break that assumption, and builders who do not notice end up growing their way into losses.

When your product sends work to a model, every action has a real cost. A long conversation, a big document, a heavy workflow: each one hands you a bill measured in tokens. That cost scales directly with how much your customers use the product, which means the more successful you are, the more you spend. This guide is about pricing for that world, where the goal is not just to charge a number that sounds fair but to make sure the price covers what each customer actually costs you to serve and still leaves profit on top.

Where does the money actually come from?#

Profit on an AI product is the gap between the price a customer pays and the model cost of serving that customer. That gap is the whole game. If it is positive and stays positive as people use more, you make money by growing. If it turns negative for heavy users, growth quietly drains you.

Here is the flow, and notice where a flat price with no cap goes wrong:

Customer pays you a price (say, a monthly fee)
        |
        v
Customer uses the product, which sends work to a model
        |
        v
The model bills you per use  <-- this scales with usage, not with the fee
        |
        v
Your profit on that customer = price paid  -  model cost incurred
        |
        v
If a heavy user's model cost climbs past the flat fee,
that customer now loses you money
        |
        v
More such customers  =  faster losses, not faster profit

Ordinary software does not have that third box in any meaningful size, which is why flat pricing works fine there. AI products do, so the flat fee that looks profitable on an average user can be deeply unprofitable on a heavy one. The money comes from keeping the gap positive across the whole range of usage, not just at the average. If the underlying difference between money coming in and money kept is still fuzzy, revenue vs profit lays out why a big top-line number can hide a business that loses on every sale.

How it actually works#

Start by knowing your cost per unit of work, because you cannot price around a number you have not measured. Pick the unit that matters for your product: a message, a generated document, a run of a workflow, a processed file. Then measure what that unit actually costs you at the model, including the fact that longer inputs and outputs cost more. You do not need perfect precision. You need to know whether a typical action costs you a fraction of a cent, a few cents, or something larger, because the right pricing structure is completely different in each case.

Once you know your unit cost, you can see why a flat unlimited price is dangerous. Under a flat fee, your revenue per customer is fixed but your cost per customer is not. Light users subsidize the plan and heavy users blow through it. On average it might look fine. Averages hide the problem, because a small number of very heavy users can consume enough to erase the profit from everyone else. The fix is to make sure that heavier usage carries a higher price, so the customer who costs you more also pays you more.

There are a few standard ways to do that, and they combine well. Usage caps set a ceiling: a plan includes up to some amount of use, and beyond that the customer either upgrades or pays for more. This alone stops the worst case, which is one unlimited user running your model bill to the moon. Tiers group customers by how much they use, so a light user gets a cheap plan and a power user pays for a bigger one. Credits turn usage into a visible currency: a customer buys or is granted a bucket of credits, each action spends some, and when the bucket runs low they top up. Credits are especially honest, because the customer can see that heavy use costs more, which makes the pricing feel fair rather than punitive.

The larger choice underneath all of this is whether to charge by seat or by usage. Per-seat pricing is simple and predictable but disconnects price from cost, which is risky when cost scales with use. Usage-based pricing tracks cost closely but is less predictable for the customer. Most AI products end up blending the two: a base fee for access plus a usage component that protects the margin. Usage-based vs per-seat pricing works through when each one fits, and the general groundwork in how to price your SaaS applies here too, with the added constraint that your floor is set by real costs, not just by what the market will bear.

A clearly hypothetical example#

Let me make this concrete with invented numbers. Everything here is hypothetical and only meant to show the shape of the math. Your real costs and prices will differ.

Say your product runs a workflow that costs you, hypothetically, 10 cents in model usage each time it runs. You charge a flat $30 a month for unlimited runs.

A light customer runs it 20 times a month. That costs you $2, they pay $30, so you keep $28. Wonderful. If every customer looked like this, you would have an excellent business.

A heavy customer runs it 500 times a month. That costs you $50, they still pay $30, so you lose $20 on them every month. The harder they lean on the product, the more they cost you, and the flat fee never moves. Sign up a hundred customers like this and you have grown yourself into a serious hole.

Now restructure. Suppose you offer a plan that includes 100 runs for $30, then charges, hypothetically, 20 cents per run beyond that. The light customer at 20 runs still pays $30 and costs you $2, so nothing changes for them. The heavy customer at 500 runs pays $30 plus 400 extra runs at 20 cents, which is $80, for $110 total, against a cost of $50. Now the heavy user pays you $60 in profit instead of losing you $20. Same product, same customers. The only thing that changed is that price now follows cost, so more usage means more profit instead of more loss. That is the entire reason usage caps and overage pricing exist on AI products.

What you need (required vs optional)#

Required:

• A measured cost per unit of work, however rough. You cannot price safely without knowing what an action costs you at the model.
• A defined billable unit: a message, a run, a document, a file. Pick the one customers can understand and you can meter.
• A pricing structure that makes heavy usage cost the customer more, whether through caps, tiers, credits, or overage. This is what protects the margin.
• A way to see your gross margin, meaning revenue minus serving cost, so you notice trouble before the bill does.

Optional but helpful:

• Alerts when a single customer's usage crosses a threshold, so a runaway account gets attention early.
• A generous but capped free trial rather than an open-ended free tier, so you can attract signups without funding strangers to lose you money.
• A cheaper fallback model for low-stakes actions, so you spend heavily only where quality genuinely matters.

What it costs#

The direct cost of pricing this way is mostly your attention. You have to measure unit costs, build metering into the product, and check margins regularly rather than setting a price once and forgetting it.

The larger cost is the discipline to resist "unlimited." Unlimited plans convert well and feel generous, and they are exactly the trap. On ordinary software, unlimited is close to free to offer. On an AI product, unlimited is a blank check written against your model bill, and the customers most attracted to it are the heaviest users, which is precisely the group that turns unprofitable first. Saying no to unlimited costs you a little conversion and saves you the business.

How long it takes#

Setting an initial structure is fast once you have measured your unit cost, which is an afternoon of testing typical actions and reading your model bill. Getting the numbers right takes longer, because you only learn how customers actually use the product after they start using it. Expect to adjust caps and prices as real usage patterns show up, especially the heavy tail you did not predict. Do not treat pricing as a one-time decision. Treat it as something you revisit as usage data comes in, because the gap between average and heavy use is where the surprises live.

What beginners usually get wrong#

The first mistake is pricing like ordinary software: a flat monthly fee with no usage limit, because that is what every SaaS pricing article recommends. Those articles assume near-zero marginal cost. You do not have that, so their advice can quietly sink you.

The second mistake is pricing off the average user. Averages hide heavy users, and heavy users are where the losses hide. You have to look at the range of usage, not the middle of it, because a small number of extreme accounts can erase the profit from everyone else.

The third mistake is ignoring gross margin entirely and watching only revenue. Revenue going up feels like winning. If each new customer costs more to serve than they pay, revenue going up is the problem, not the win. Watch the gap, not the top line.

The fourth mistake is confusing lifetime value with price and forgetting the serving cost that eats into it. A customer's real value to you is what they pay minus what they cost you to serve, over their whole time as a customer. Customer lifetime value explained covers the concept, and on an AI product you must subtract model cost from it, or the number is fiction.

How I would start#

If I were pricing an AI product with real usage costs from scratch, here is the order I would work in.

1. Measure what a typical action costs me at the model, including that longer inputs and outputs cost more. Get a real number, not a guess.
2. Pick a billable unit a customer can understand and I can meter: a run, a message, a document.
3. Set a base plan that includes a capped amount of usage at a price that comfortably covers the cost of that included usage plus margin.
4. Add overage or credits above the cap, priced so that heavier use always earns me more, not less.
5. Replace any "unlimited" language with a clear cap, and make a free trial generous but bounded.
6. Build in visibility: track gross margin overall and watch individual accounts that spike.
7. Revisit the numbers once real usage arrives, and adjust the cap and overage so the margin holds across light and heavy users alike.

What I would not do#

I would not offer an unlimited plan on a product with real per-use costs, because the heaviest users, the exact ones unlimited attracts, are the ones who turn it into a loss. I would not run an open-ended free tier before I understood my unit economics, because that funds strangers to burn my model budget. I would not price purely off what competitors charge, because their cost structure and mine may be different, and their number could be a floor below my actual cost. I would not set the price once and stop looking, because usage patterns shift and the heavy tail shows up later. And I would not celebrate rising revenue without checking the margin underneath it, because on an AI product, growth at a negative margin is just a faster way to lose money.

The bottom line#

The rule that software costs nothing to serve one more user does not hold for AI products. Every action sends work to a model and hands you a bill that scales with usage, so your price has to cover that cost and still leave a margin, on light users and heavy users both. Measure your cost per action, pick a billable unit, cap usage or charge for it above a threshold, and watch your gross margin like it is the vital sign it is. Do that and growth adds profit. Skip it, price flat and unlimited, and growth quietly does the opposite. If you are building the product this pricing wraps around, how to build an AI chatbot product covers making it worth paying for in the first place, which is the other half of the same problem.