How to meter and bill AI feature usage without hurting margin

• A metered AI feature ties revenue to real token cost, but passing raw tokens straight to the customer creates unpredictable bills that buyers reject.
• Meter a stable business unit the customer already understands, and keep the raw token log underneath so you always know real cost per tenant.
• Run the flow as capture, aggregate, rate, then invoice, and put a hard spend cap in front of every account before you turn it on.

Token cost turns every AI feature into a variable-cost product. A search box or a settings page costs about the same whether a customer opens it once or ten thousand times. An AI summary that calls a frontier model does not: at roughly $5 per million input tokens and $30 per million output tokens on a current flagship model, a heavy account can cost more to serve than it pays you. That is why so many teams ship an AI feature, watch adoption climb, and then notice gross margin drifting the wrong way at renewal.

Why metered AI features quietly erode margin

Traditional SaaS runs at 70 to 80 percent gross margin because serving one more user is nearly free. AI features break that assumption because every request carries a marginal compute cost. Price an AI copilot as a flat seat add-on and you are effectively selling unlimited inference at a fixed price.

The distribution is the problem. In most products the top few percent of accounts by usage consume more tokens than the entire bottom half combined. Under flat pricing those accounts are subsidized by everyone else, and you cannot see it until a big customer's usage lands on the model bill. The fix is not to abandon flat plans. It is to measure usage first, so you know which accounts are underwater long before you have to negotiate a renewal. We walk through the full unit economics in our breakdown of AI feature gross margin for SaaS.

Decide what to meter before you touch code

The most common mistake is metering raw tokens and forwarding them straight to the customer. Tokens are an implementation detail. When you upgrade the model, add prompt caching, or shorten a system prompt, the token count changes and the customer's bill moves for reasons they cannot see or forecast. That erodes trust faster than a higher price would.

Pick a unit the customer can predict

Good billable units map to a job the customer actually asked for: a resolved support ticket, a generated report, an enriched contact, a document processed, a meeting summarized. These are countable, they map cleanly to value, and they stay stable when the model underneath changes. The customer can look at a plan and estimate their bill without knowing what a token is.

Keep the raw token log underneath

Even when you bill on business units, record input tokens, output tokens, model, and cache-hit status for every call. That log is what tells you real cost per unit and per tenant. Without it you cannot answer the one question that decides pricing: is this customer profitable? Charge on a clean external unit, reconcile against the raw log internally.

The metering pipeline, end to end

A working meter has four stages: capture, aggregate, rate, then invoice. Keep them separate so each can fail or be replayed on its own.

Capture: emit one usage event per call

After the model returns, write an event with tenant id, feature, unit count, input and output tokens, model, cache hit, and a timestamp. Write it to an append-only table or a stream, and never block the user-facing response on the meter. Give every event a unique id so the next stage can be idempotent.

Aggregate: roll up on a schedule

Roll events up per tenant and feature on a fixed cadence, hourly is a reasonable default. Key the rollup on the event id so a replay or a duplicate delivery cannot double-count. This is also where you compute the numbers your dashboards and alerts read from.

Rate: apply a versioned price book

Rating turns quantities into money. Keep the price book versioned and dated so an old invoice always rates at the price that was live when the usage happened. Changing a price should never silently rewrite last month's bill.

Invoice: hand off to a billing system

Push the aggregated quantities to a billing platform rather than building an invoicing ledger yourself. Stripe's acquisition of Metronome in 2026, valued at roughly a billion dollars by Sacra, is a strong signal that metering is now core billing infrastructure, not a weekend side project. Let a dedicated system own dunning, proration, and tax.

Pricing models that survive a CFO conversation

Three archetypes cover most metered AI features. Pure per-token pass-through makes revenue track cost exactly, but bills swing wildly and enterprise buyers resist the unpredictability. A prepaid credit model has the customer buy a bucket of credits that each action spends down, which is predictable for you and familiar to them. A hybrid of a flat platform fee plus a metered allowance, with overage billed above it, combines a margin floor with a usage upside.

The 2025 State of Usage-Based Pricing report found that about 85 percent of software companies now use usage-based pricing in some form, so buyers are no longer surprised by the model itself. What still surprises them is a bill they could not forecast. Give every plan a clearly included allowance and a visible in-product usage meter, and most of that friction disappears.

Guardrails before you turn it on

Metering without limits is how one runaway integration becomes a five-figure model bill overnight. Set per-tenant hard spend caps that stop inference when an account crosses its ceiling, a pattern we detail in per-tenant LLM cost caps for multi-tenant SaaS. Fire alerts at 50, 80, and 100 percent of a plan's allowance so nobody is surprised. Keep an internal cost ceiling that is independent of the customer's plan, as a backstop against your own bugs.

Cut the cost you meter in the first place, too. Caching repeat queries is the cheapest win available: our write-up on semantic caching to cut LLM cost and the companion piece on prompt caching cost savings both show meaningful reductions on real workloads. If you would rather have this metering layer built and instrumented for you, that is exactly the kind of scoped work our subscription pricing covers.

Frequently asked questions

Should I bill customers per token?

Usually no. Tokens are an internal cost signal, not a customer-facing unit. Bill on a business unit the customer understands, such as a report or a resolved ticket, and reconcile against per-call token cost behind the scenes.

What is the simplest metering unit to start with?

Pick the single action your feature exists to perform and count it: one summary, one enrichment, one generated draft. Start with one unit, get the capture and aggregation right, and add units later only if the pricing genuinely needs them.

Do I need a tool like Stripe or Metronome?

For invoicing, dunning, proration, and tax, yes, use a dedicated billing system. You still own the metering pipeline that captures and aggregates usage; the billing tool takes the final quantities and turns them into money.

How do I stop a customer from running up a huge bill?

Set a per-tenant hard cap that halts inference at a spend or usage ceiling, alert well before the limit, and keep an internal cost ceiling as a second backstop. Caps protect both the customer's budget and your margin.