Usage Metering for AI Features in SaaS

Two jobs that people confuse

Metering in an AI SaaS product does two different things. The first is internal cost accounting: what did serving this tenant, this feature, this month actually cost us. The second is billing: how many units of value did this customer consume, according to the pricing they signed up to.

They come from the same raw data, but they are not the same number. Customers should almost never be billed in tokens; they do not understand them, and your costs change when you optimise. Your finance team, meanwhile, needs tokens and cost precisely. Designing for both from the start avoids a painful rebuild. Our guide to usage-based billing for SaaS covers the pricing and invoicing side; this post is about the metering underneath.

What to record on every call

Record cost at the time of the call using a versioned price table. Recomputing history with today's prices produces margins that never existed.

From raw events to billable units

Most AI actions involve several model calls: retrieval embeddings, a main generation, a validation pass, perhaps a retry. The customer did one thing, such as processing an invoice, and should see one unit.

1. Every model call emits a raw usage event through the model gateway
2. Events are grouped by request or job ID into an action
3. The action is assigned a billable unit, such as one document, one call analysed or a number of credits
4. Failed or abandoned actions are marked non-billable according to your policy
5. Aggregates per tenant per period feed dashboards, limits and the billing system

Keep raw events immutable and append-only. Corrections, such as crediting a customer for a bad batch, are separate adjustment records, not edits. Auditors, finance and angry customers all appreciate being able to see what happened.

Where to put the data

At modest volume, a usage events table in PostgreSQL, partitioned by month, works well. As volume grows, stream events to a warehouse or an analytical database for reporting, keeping a compact aggregate table in the application database for quotas and in-app usage displays.

• Write events asynchronously so metering never slows a user request
• Use an outbox or durable queue so events are not lost if a worker crashes
• Deduplicate on event ID, since retries can emit duplicates
• Keep aggregates per tenant, feature and day for fast queries

Dedicated usage billing platforms exist and can be worth it once pricing becomes complex. Stripe's usage-based features handle the invoicing end for many products, as covered in our Stripe billing integration guide. Either way, you still need your own raw events, because billing tools do not know your cost.

Showing usage to customers

Usage pricing creates anxiety for buyers, particularly finance teams. Good metering reduces it.

• An in-app usage page showing consumption against plan, updated at least daily
• Breakdown by team, user or feature so admins can see who is using what
• Alerts at thresholds, such as 75% and 90% of included usage
• Optional hard caps, so a customer can guarantee a maximum spend
• Exportable detail that matches the invoice line for line

If a customer cannot reconcile their invoice with the usage page, they will assume the invoice is wrong.

Using metering to run the business

Once events flow, three internal reports earn their keep: gross margin by tenant, cost per billable unit over time, and cost per feature. Together they show which customers are unprofitable on their current plan, whether optimisation work is paying off, and which features cost more than they are worth.

The same data drives per-tenant quotas and fair scheduling, which protect everyone's experience when one customer runs a huge job. The same events feed rate limiting and queue scheduling, and the margin side is covered in AI SaaS unit economics.

Common mistakes and honest trade-offs

• Metering only at the billing layer, so cost per tenant is invisible
• Billing customers in tokens, which ties their bill to your internal efficiency
• Forgetting background work such as re-indexing, evaluation runs and embeddings
• No reconciliation, so provider invoices and internal totals drift apart unnoticed
• Over-engineering for billing precision before any customer is on usage pricing

The last one matters for early products. If you are still on flat pricing, you need accurate internal cost metering, not a billing-grade pipeline. At SpiderHunts we build the raw events and cost view first as part of our SaaS development work, and add billing aggregation when pricing actually requires it.

Frequently asked questions