Metering AI is a product decision, not a billing one

Traditional software has an unusual economic property: once it is built, one more user costs almost nothing. AI features break that. Every generation, every answer, every analysis has a real, variable cost. Heavy users are not just more valuable — they are more expensive.

That changes how the product has to be designed. And the teams that treat metering as a billing detail, to be handled after launch, tend to discover it as a margin problem.

The tension

An AI learning or training product is a good illustration. The experience is best when learners interact freely: asking follow-up questions, retrying, exploring. That is what makes it adaptive. It is also what makes it costly.

Uncapped, the most engaged users can cost more than they pay. Tightly capped, the product feels stingy exactly when the user is most engaged. Neither extreme works, so the metering model is not a finance choice — it is part of the user experience.

Metering levers, from the product side

There are more options than "a monthly quota".

• Tiers with different allowances. Match usage limits to plan price, so heavy users have a natural path to a plan that supports them.
• Token or credit budgets. Give users a visible balance. It makes cost legible and turns an invisible limit into a resource people can manage.
• Tiered models. Use a smaller, cheaper model for the common path and reserve the most capable model for where it genuinely matters.
• Caching and reuse. Many requests are near-duplicates. Serving them from a cache is both faster and cheaper.
• Soft limits before hard ones. Warn early, degrade gracefully, and only stop entirely at a limit the user saw coming.

Design principles I use

Make cost visible to the right person. An administrator running a programme needs to see and control consumption across their learners. The learner mostly needs to not be surprised.

Never fail silently. When a limit is reached, say so, say why, and say what the options are. A feature that quietly stops working reads as broken.

Meter at the boundary, not everywhere. Put metering in one place in the architecture — the layer that calls the model — so it cannot be bypassed by a new feature that forgot to check.

Record usage as data, not just as a bill. Usage per feature, per user and per model tells you where value is being created and where cost is being wasted. It is some of the most useful product data you will have.

The takeaway

Decide how usage is metered, capped and priced at the same time you design the feature, not after. It changes what you build: which model you call, when you call it, what you cache and what the user sees.

With AI, the unit economics and the user experience are the same design problem. Treating them separately is how good features become unaffordable ones.