Credit Systems for AI Products: How to Design One

A credit system exists to solve one problem: your costs are denominated in tokens, and nobody wants to buy tokens. Credits are a translation layer between a unit you cannot control and a unit your customer can reason about. Design it well and you can change models, absorb a price rise, and let heavy users pay more without renegotiating anything. Design it badly and you have invented a currency you cannot devalue, which is a worse position than flat pricing.

The whole job is picking what one credit means, and then defending that meaning.

Step one: find your cost per unit of work

Do not start from tokens. Start from the thing the customer asks for, which might be a document summarised, an image generated, a support ticket triaged. Measure the real token cost of that job across a sample of at least a few dozen real inputs, not your test file.

You will get a distribution, not a number. Say summarising a document costs you between 0.4 and 3.1 cents depending on length, with a median around 0.9. Three numbers matter from that:

• The median, because it sets your average margin

• The 95th percentile, because it sets your worst realistic case

• The ratio between them, because if it is more than about five to one, one credit cannot honestly mean one job

That ratio is the first real design decision. A tight distribution means you can price per action, which customers find far easier to understand. A wide one means you have to price per unit of input, usually per page, per thousand words, or per minute of audio.

Step two: pick a credit that means something

The best credit unit is one a customer can predict before they spend it. Ranked roughly by how well they hold up:

Resist the last one. A credit defined as an abstract compute unit shifts all forecasting risk onto the customer, and the predictable result is that they stop buying in bulk because they cannot tell what they are getting.

Then choose a number that leaves you room. If a job costs you 0.9 cents at the median, do not set one credit equal to one job and sell credits at one cent. Set one credit to a smaller slice, say a tenth of a job, and price the pack so the arithmetic still works when your cost doubles. Granularity is the cheapest insurance you can buy here.

Step three: set margin where the variance is

Flat percentage markup on the median is the common mistake, because it prices your worst cases at a loss. A more durable approach is to price the pack against something between the median and the 95th percentile, closer to the median when your distribution is tight and closer to the tail when it is not.

Then cap the tail explicitly. A hard limit on input size per action, stated in the product, converts an unbounded liability into a support conversation. That is a much better trade than absorbing one customer's 400 page PDF forever. The same discipline applies upstream to your own bill, which is where reducing your ai api costs does more for margin than any pricing page edit.

The three ways credit systems break

Credits that expire in a way customers notice

Expiry protects you from a cost base that keeps rising against credits bought at last year's prices. It also generates more support anger per euro than almost anything else in software. If you must expire, expire slowly, warn twice, and never expire credits inside the billing period the customer paid for. Rolling twelve months is defensible. Thirty days reads as a trick.

Credits that no longer map to value after a model change

You switch to a cheaper model, a job now costs a third of what it did, and your customer is still paying one credit for it. Or the reverse, and you are losing money on every call. This is not hypothetical, it is what happens every time you decide to upgrade to a newer ai model. The fix is to define credits against the job, not the model, and to accept that your margin per credit will float. Publish the job definition, keep the model an implementation detail, and you can change engines without a pricing announcement.

Credits customers cannot forecast

If a customer cannot answer "how many credits will this month cost me" before they commit, they will buy the smallest pack, watch the meter, and churn the first time they get surprised. A usage estimator on the pricing page, even a rough one, is worth more than another pricing tier. This is the same failure that makes usage-based and flat-rate ai pricing feel so different to buyers who are otherwise spending the same money.

Showing the balance without causing anxiety

A credit system is a meter, and meters change behaviour. Customers who can see a balance draining will use the product less, which is the opposite of what you want from the feature you charge for. Three choices decide whether the meter helps or hurts.

Where you show it. A persistent counter in the header makes every action feel like a purchase. A balance on the billing page, plus a warning when it drops below a threshold, gives people the information without the running commentary.

What you show it in. Show remaining work, not remaining units. "About 180 documents left" is actionable. "1,800 credits" requires the customer to do arithmetic they will get wrong.

What happens at zero. Decide in advance whether the product hard stops, degrades to a slower path, or auto-tops-up. Silent failure at zero is the version that generates support tickets, and an auto-top-up nobody consented to generates worse ones. Stripe's usage-based billing documentation is a reasonable reference for the mechanics if you are wiring metering into an existing subscription rather than building the ledger yourself.

The ledger itself is unglamorous and worth doing properly the first time: every deduction recorded with what it was for, every top-up recorded with what was paid, and a balance derived from that history rather than stored as a mutable number. When a customer disputes usage, and one will, the ledger is the entire answer.

When not to use credits at all

Credits are overhead. They need a balance, a ledger, top-ups, refunds, an expiry policy, and a support team who can explain all of it. If your cost per customer is fairly flat, or your heaviest user costs you twice your lightest rather than fifty times, a plain subscription is a better product and a much smaller build.

Reach for credits when usage genuinely spans an order of magnitude between customers, when your marginal cost is large enough to notice, or when customers want to buy capacity in advance. Otherwise you are adding a currency to solve a problem you do not have. The wider decision sits inside ai monetization strategies, and the specific comparison against a straightforward subscription is covered in how to price an ai product.

Not every metering model needs a credit balance, how to add usage-based pricing to an AI app covers the broader set of units worth metering and how to price them.

FAQ

Should credits roll over between months?

Rolling over is the friendlier default and reduces churn. Protect yourself with a cap on accumulated balance rather than aggressive expiry, so a customer cannot bank two years of credits at old prices.

How do I handle a failed request, does it consume a credit?

No, and say so in the product. Charging for a failure is the fastest way to make usage-based pricing feel unfair. Deduct on successful completion, and refund automatically on a timeout or provider error.

What happens when my provider raises prices mid-year?

Existing balances are a liability at the old rate, which is exactly why granular credits and a balance cap matter. What to do when your ai provider raises prices covers the wider decision, but the credit-specific answer is to change the price of new packs, not the value of credits already sold.

Can I give free credits for signups?

Yes, and it is one of the better uses of the system. Free credits let someone experience the real product without a trial timer. Give enough for a genuine job to complete end to end, because a free allowance that runs out halfway through teaches the wrong lesson.