How AI Companies Bill for Token Usage: Metering, Rating, and Revenue Recognition Explained

A seat is a fixed unit. A gigabyte is a fixed unit. A token is not.

When a SaaS company prices per seat, the unit economics are stable: one seat costs roughly the same to serve as the next one, and the price doesn't move based on what the customer does with it. Token-based pricing breaks that assumption completely. An input token and an output token cost different amounts to produce. A short factual answer and a long reasoning chain consume wildly different volumes of the same "unit." A single user request can silently balloon into hundreds of billable events before it produces a result the customer sees. The thing you're charging for has variable cost, variable volume, and no natural ceiling, and your billing system has to price it correctly anyway.

That's the problem this post is about: not "what is usage-based billing" in the abstract, but specifically how AI companies meter, rate, invoice, and recognize revenue on token consumption today, what the vendor landscape actually looks like, and where the real difficulty sits once you get past the pricing page.

What a Token Actually Is as a Billing Unit

A token is roughly four characters of text. That's the informal definition, and it's fine for a product page, but it hides the part that matters for billing: every major model provider charges input tokens and output tokens at different rates, often by a factor of three to five, and the ratio between the two varies enormously by use case. A summarization task might consume 2,000 input tokens and produce 50 output tokens. An open-ended reasoning task might consume 200 input tokens and produce 4,000 output tokens as the model works through a chain of intermediate steps. Two requests that look identical to the end user - "ask a question, get an answer" - can have wildly different cost profiles depending entirely on what happened inside the model.

This is the first thing that makes token billing structurally different from the usage metrics finance teams are used to. API call volume, storage consumed, seats provisioned - these are metrics where the unit is stable and the count is the only variable. With tokens, the unit itself is not fixed in cost, which means your rating logic has to track input and output separately, apply different rates to each, and often apply different rates again per model tier, since a request routed to a larger or smaller model changes the price even when the token count is identical.

The Four-Layer Stack

Token billing is not one system. It's four layers, and most companies end up assembling them from different vendors because very few products do all four well.

1. Metering (ingestion). Every billable action - an API call, a tool invocation inside an agent loop, a completion - has to be captured as a discrete, attributable event: which customer, which product, which model, how many input and output tokens, at what timestamp. This sounds trivial until volume gets real. At scale this is a streaming problem, not a database-write problem, and it's the layer most likely to silently produce bad data if it wasn't built for the traffic pattern your product actually generates. (Post 5 in this series, The Metering Architecture Problem, goes deep on exactly how this layer breaks under agentic workloads specifically - worth reading if you own this pipeline.)

2. Rating. Once a usage event exists, something has to price it: apply the input/output rate, apply any volume tiers or committed-use discounts, apply model-specific pricing, and produce a charge. This is where pricing strategy actually gets implemented in code, and it's the layer that has to change every time you launch a new plan, a new model tier, or a promotional rate.

3. Invoicing. Rated charges get aggregated into a bill: summed by billing period, reconciled against any prepaid balance or committed minimum, formatted, and sent. This layer looks the most like traditional billing and is usually the easiest of the four to buy off the shelf.

4. Revenue recognition. The accounting layer, and the one most commonly bolted on as an afterthought. Token usage is textbook variable consideration under ASC 606, prepaid token packs raise breakage questions, and committed-use contracts with overage create their own recognition timing questions. (Post 4 in this series, Revenue Recognition for AI and Token-Based Pricing Under ASC 606, covers this layer in full technical depth.)

Very few platforms are excellent at all four. Most companies end up with a metering/rating specialist feeding into a separate invoicing and payments layer, with revenue recognition handled by yet another system or, too often, a spreadsheet.

The Vendor Landscape, As It Actually Stands

The category has consolidated and specialized at the same time.

Metronome was, until early 2026, the metering layer behind OpenAI, Anthropic, Databricks, and NVIDIA - processing billions of usage events a day on Kafka-based streaming infrastructure, and best known for handling enterprise commitments and prepaid credits well. It's now part of Stripe, following an acquisition reported at roughly $1B. That deal changes the competitive picture for everyone else in this list, and it gets its own full treatment in Why Stripe Bought Metronome for $1B.

Orb and m3ter are pure metering specialists, positioned for companies that want a best-in-class metering and rating engine paired with a separate invoicing system rather than an all-in-one platform. Amberflo is pitched specifically as an "AI monetization" platform: instead of billing usage in isolation, it connects usage to the underlying compute cost, so you can see margin per customer or per request, not just revenue. Zenskar and Lago take a unified approach, covering subscription and usage billing in one product. Stripe Billing itself shipped LLM token billing in preview from March 2026, auto-syncing token prices for OpenAI, Anthropic, and Google models directly - a meaningful move given how much of the SaaS and AI market already runs payments through Stripe.

A direct, capability-by-capability comparison of the four names that come up most in actual buying decisions - Stripe Billing, Metronome, Orb, and Amberflo - is in Stripe Billing vs. Metronome vs. Orb vs. Amberflo. If you're evaluating this category right now, that's the post to read next.

Why This Category Suddenly Matters

Two data points explain why this stack has gone from a niche billing-engineering concern to a boardroom question in the space of about a year.

First, the money: Stripe's willingness to pay roughly $1B for Metronome is a strong signal that metering and rating for usage-based and token-based pricing has become infrastructure-critical, not a feature. Companies don't pay nine figures for a nice-to-have.

Second, the pain: 46% of IT leaders cite unpredictable pricing as a primary barrier to enterprise GenAI adoption. That statistic says something specific - it's not that buyers object to usage-based pricing in principle, it's that the billing infrastructure behind it hasn't reliably delivered predictability. A customer who can't forecast next month's bill within a reasonable range is a customer who hesitates to expand usage, and a vendor whose billing pipeline can't answer "why was I charged this amount" quickly is a vendor who loses trust regardless of how good the underlying model is.

Both of these point at the same underlying fact: the metering and rating layer is no longer just an accounting detail. It's a product experience, and increasingly a competitive differentiator.

Committed-Use Contracts: The Dominant Enterprise Pattern

Pure pay-as-you-go token pricing is common for self-serve and developer traffic, but it's rarely how enterprise AI deals actually get structured. The dominant pattern is committed-use: the customer commits to a minimum spend or a prepaid block of tokens up front, usually at a discount to list rate, and the vendor bills overage separately if actual usage exceeds the commitment.

This pattern exists for a reason on both sides. The customer gets budget predictability and a lower effective rate. The vendor gets revenue certainty and a strong signal of which accounts are worth investing support and account management time in. It's also precisely the capability that made Metronome's pre-acquisition infrastructure valuable enough to draw a roughly $1B price tag: commitments and credits handling, done well, is a genuinely hard billing problem, not a simple discount rule.

The difficulty shows up in a few specific places. Tracking a running balance against a commitment in near-real time, so a customer (and your own sales team) can see remaining balance rather than finding out at invoice time. Deciding what happens to unused committed tokens at the end of a term - do they roll over, expire, or get refunded, and how does that decision get reflected in revenue recognition (this is the breakage question, covered in full in the ASC 606 post linked above). Handling multi-tier commitments where a customer might have separate committed pools for different models or products, each rating and depleting independently. And handling true-ups cleanly: when a customer blows through their commitment mid-cycle, the overage needs to be metered, rated, and billed correctly without double-counting against the committed pool.

None of this is exotic, but it's exactly the kind of detail that separates a metering platform that handles enterprise AI contracts well from one that only handles simple pay-as-you-go traffic. If your sales team is already writing committed-use deals, or plans to, this capability belongs on the evaluation checklist from day one rather than being discovered as a gap after the first big renewal.

The Part Nobody's Pricing Page Mentions

Two problems sit underneath everything above, and they're both genuinely new relative to how API billing worked a few years ago.

The first is architectural. Traditional API metering assumed something close to a 1:1 relationship between a user action and a billable event. Agentic workloads break that: a single user request can trigger an agent loop that fans out into dozens or hundreds of downstream tool calls and sub-agent invocations before producing a result, and every one of those calls has its own token cost that needs to be attributed back to the right customer and invoice line. Metering pipelines that were built for steady, predictable API traffic can fall over under this pattern, or worse, silently produce duplicate or misattributed usage records. This is a deep enough problem that it gets its own post: The Metering Architecture Problem: Why AI Agent Loops Break Your Billing System.

The second is accounting. Token pricing is variable consideration under ASC 606, which means revenue recognition has to apply a constraint on how much of that variable amount you're allowed to recognize before it's "probable" the amount won't reverse. Prepaid token packs create breakage questions when customers don't use their full balance. Committed-use contracts with true-up billing create timing questions about when overage revenue gets recognized relative to the committed baseline. None of this is exotic accounting, but it is accounting that most revenue recognition workflows built for flat subscription pricing were never designed to handle. The full walkthrough is in Revenue Recognition for AI and Token-Based Pricing Under ASC 606.

How to Evaluate This Stack Today

For a finance or RevOps leader looking at this space right now, a few things are worth holding onto:

Don't evaluate metering and revenue recognition as separate purchasing decisions. They're two ends of the same pipe. A metering vendor that can't hand off clean, well-attributed usage data makes revenue recognition harder no matter how good your accounting process is. Ask any vendor you're evaluating to walk through the full path from raw event to recognized revenue, not just from event to invoice.

Ask about burst handling, not just steady-state volume. Agentic products generate usage in unpredictable spikes, not smooth traffic. A vendor's published throughput numbers under normal conditions tell you less than how their system behaves when a single customer's agent loop generates ten times their usual volume in a ten-minute window.

Treat vendor consolidation as a live risk factor, not a footnote. The Metronome acquisition is the clearest recent example: a platform your team may have selected as an independent best-of-breed vendor is now part of a much larger company with its own roadmap priorities. That's not automatically bad, but it's a question worth asking of any vendor in this category: what happens to your roadmap and pricing if this company gets acquired in 18 months?

Match the platform to your actual scale, not your ambitions. If your usage volume is still in the low millions of events a month, the enterprise-grade metering engines built for hundreds of millions of daily events (the kind of scale covered in our SAP BRIM vs. Zuora comparison) are more infrastructure than you need. Start with a platform matched to today's volume and revisit the decision at the next order of magnitude, not before.

Token-based pricing is not going away, and the companies that get the underlying billing infrastructure right - metering that survives real traffic patterns, rating that reflects true unit economics, invoicing customers can trust, and revenue recognition that holds up under audit - are the ones who'll be able to price aggressively and confidently in a market where most competitors are still treating this as a solved problem it isn't.