AI workloads make flat pricing bad for both sides. Margin compresses when a customer's demand spikes, and the customer who barely used the product paid for capacity that sat idle. The vendor absorbs the variance either way.
Usage-based pricing moves that variance to where it belongs. Revenue tracks consumption, and infrastructure cost becomes a variable with a known relationship to what you charge. Getting there is seven concrete steps, and most of the difficulty is in the first two.
Short answer
Choose one dominant billable unit tied to customer value, instrument event-level metering that is auditable, package the unit with credits and entitlements rather than metering everything without limits, set tiers and guardrails as configuration, show live usage in the product, track cost per unit against margin, then run pricing as an ongoing experiment.
Step 1: choose the billable unit
The unit has to align with two things at once: your cost base and the customer's perception of value. Candidates include API calls, tokens processed, GPU seconds, images generated, and transcription minutes.
One dominant unit beats several obscure ones. Multiple metrics create confusion, need more tracking, and produce more disputes. If you cannot explain the unit in one sentence, the invoice will not explain itself either.
Then define the exchange rate: how many units make one credit or one dollar. That mapping has to stay stable, or evolve slowly and visibly, because customers build their own cost models on it and a silent change reads as a price rise.
Step 2: instrument metering properly
Capture at the event layer: who used what, when, how many units, under which plan. The data has to be clean, near real time, and auditable, because every one of those properties is load-bearing when a charge is questioned.
{
"event_id": "evt_7c31d9",
"event_name": "tokens_processed",
"external_customer_id": "acct_5581",
"timestamp": "2026-09-11T11:04:12Z",
"properties": {
"model": "claude-sonnet",
"input_tokens": 2210,
"output_tokens": 738,
"feature": "summarize"
}
}
Two properties earn their place here. model is what lets one meter price several models at different rates without duplicating plans. feature is what lets a customer answer which part of the product drove the bill.
Weak metering produces overcharging, revenue leakage, or a support queue, and usually all three in sequence. Keep a ledger of every event so usage can be audited and a billed amount defended. Flexprice ingests these streams and applies plan rates, thresholds, and caps per customer, documented in event ingestion.
Step 3: package with credits and entitlements
Usage-based pricing does not mean metering everything with no limits. Packaging helps both sides.
A workable shape is a base subscription that includes a fixed allowance, say 10M tokens, plus access to core features, with per-unit charges above the allowance. Entitlements handle the access side: which features a plan unlocks, which models are available, what the quota is.
This produces predictable recurring revenue with upside as usage grows, which is easier to forecast than pure pay as you go and easier to sell than a pure subscription.
Flexprice supports credit wallets with automatic drawdown against usage and entitlement grants tied to plans, so a package like a token bundle plus a feature unlock is configuration rather than application logic.
Step 4: set pricing rules and guardrails
The rules layer covers minimum commitments for a revenue floor, volume tiers, overage rates, caps, and discounts.
Guardrails protect both sides from the same event. Alerts when a customer passes 80% of their credits. Soft limits that notify and keep serving. Hard caps that block until the customer moves up a tier or tops up.
Which one to use depends on what breaks when consumption stops. Blocking a production integration to enforce a quota is usually worse for you than the overage. Blocking a runaway batch job usually is not.
Flexprice handles tiered rate structures, minimums, and caps through configuration, with spend alerts at the subscription and line item level.
Step 5: expose usage inside the product
Usage pricing requires the customer to be able to see the meter. That means live consumption, remaining credits, forecast spend for the current cycle, and any upcoming change such as the next tier rate or rollover behaviour.
The critical property is that the number in your UI matches the number on the invoice exactly, because a small discrepancy costs more trust than a large charge. When the bill is a black box, customers either churn or negotiate hard, and both cost more than building the dashboard.
Flexprice provides exportable usage widgets that read the same data the invoice is computed from.
Step 6: monitor unit economics
Usage pricing is dynamic in both directions. When inference cost moves, price has to move with it or margin quietly erodes.
Compute cost per unit, target margin, break-even, and the growth multiplier. Then segment: by customer size, by usage shape, and by feature mix. A burst customer who consumes 90% of their allocation in one week and nothing afterwards has a different cost profile from a steady customer with the same monthly total, because peak capacity is what you pay for.
The signals to watch are margin erosion per cohort, the ratio between allowance and actual consumption, and which features carry negative margin at current prices. Flexprice exposes usage analytics per customer and plan, and cost sheets hold what each unit costs to serve so margin is computed rather than estimated.
Step 7: iterate with experiments
Pricing is not set once. Test structures against each other: base pack with overage against fully pay as you go, token bundles with rollover against bundles without it.
Track churn, average revenue per user, cost per user, margin, and upgrade rate. A structure that raises revenue and raises churn is not a win, and only tracking both catches that.
The infrastructure requirement is running multiple price books and plan versions at once, then migrating customers between them without losing wallet state or usage history. Flexprice supports plan cloning and per-customer price overrides for exactly this.
What holds it together
Alignment is the point: revenue scales when the customer gets more value, and light users are not subsidising heavy ones. That only holds if the telemetry is accurate, the unit is legible, the invoice is transparent, and the economics get reviewed rather than assumed.
Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud, and all three run the same engine.
Getting started
Steps 1 and 2 are the ones worth prototyping before committing to a model, because the unit and the event schema constrain everything after them. The sending events guide covers the payload contract, and the source is on GitHub.
Top comments (0)