Most billing conversations treat these three terms as synonyms. They are not. Metered billing describes how you measure consumption. Usage-based billing describes how you price it. Time-based billing describes what you are measuring in the first place: not discrete events, not seats, but time.
What metered billing actually is
Metered billing is the measurement layer. It is infrastructure, not pricing strategy.
When a customer sends an API request, your system has to count it. When they process a file, your system records it. Metered billing is the system that captures those events, deduplicates them, aggregates them over a billing window, and makes them available for downstream pricing.
The meter is the hard part. Events get dropped under load. Duplicate events inflate invoices. Out-of-order events break aggregation windows. The $0.05 per API call is easy to price. Reliably counting those API calls at scale is a different problem entirely.
This is why metered billing discussions in engineering teams are fundamentally about infrastructure: event ingestion pipelines, idempotency keys, windowed aggregations, and storage that can reconstruct usage history for any billing period. Pricing decisions sit upstream; the meter is what makes those decisions real.
Metered billing is not a pricing model. It says nothing about what you charge per unit, whether you use tiers, or what triggers an invoice. It only counts.
Common metered units in SaaS and AI in 2026:
API calls
LLM tokens processed
Messages sent
Files or records processed
Compute minutes consumed
Active storage used (GB)
What usage-based billing actually is
Usage-based billing (UBB) is the pricing layer that sits on top of metering. If metered billing answers how much did they use, usage-based billing answers what do we charge for that.
UBB aligns cost directly to consumption. Customers who use more pay more. Customers who use less pay less. There is no flat monthly fee that asks a low-volume customer to subsidize a high-volume one.
The most common UBB models:
Per-unit pricing. A flat rate per event. OpenAI charges per thousand tokens. Twilio charges per SMS. Simple to explain and predict at low volumes, but customers feel every spike in usage.
Tiered pricing. The per-unit rate changes based on total volume in a period. The first 10,000 API calls cost $0.05 each; the next 90,000 cost $0.03 each. Rewards high-volume customers but makes it harder for them to estimate invoices in advance.
Volume pricing. All units in a period get repriced at the rate that matches total volume. Once you cross 10,000 calls, all of them reprice at the lower rate. Creates pricing cliffs that need careful handling.
Credits and prepaid consumption. The customer buys a block of credits upfront and depletes it against usage. Common across AI tooling. Anthropic and most major LLM providers use this structure.
UBB has grown rapidly because it lowers the barrier to onboarding. Customers do not commit to a monthly seat before they understand their usage. They start small and expand as value becomes clear. The tradeoff is revenue unpredictability for the vendor and invoice anxiety for the customer. Most hybrid models in 2026 combine a small subscription floor with usage overages to address both.
What time-based billing actually is
Time-based billing charges for time rather than discrete events. The clock is the meter.
This is a different dimension entirely. You are not counting how many things happened. You are measuring how long something ran, how long a user was active, or how long a resource was held.
That distinction shapes everything downstream: what the system tracks, how it aggregates, how it invoices.
Time-based billing fits two distinct contexts.
Professional services. Law firms, consultancies, design agencies, and freelancers have billed by the hour for decades. Time gets tracked in increments (often six-minute blocks in legal billing), applied against hourly rates, and invoiced per engagement. Platforms like Billed automate this with real-time timers, configurable rounding rules, and project-based rate tiers.
SaaS and AI products. This is where time-based billing is growing quickly. AI tutoring platforms charge per session minute. Developer tools charge per minute of compute uptime. Content platforms charge for time spent with premium material rather than a flat monthly membership. Autonomous AI agents increasingly bill per hour of operation rather than per action taken.
The technical model looks different from event-based metering. Instead of capturing discrete events, the system starts a session timer, tracks it, and charges on completion or at fixed intervals. Charges accrue smoothly rather than in discrete jumps.
Tiun models time-based billing as a native product type, distinct from subscriptions. You define the charging interval based on time spent with your content rather than selling access as a flat membership. Both product types share the same SDK, so a product offering a subscription tier and a pay-per-session tier does not need separate infrastructure for each.
How the three models relate
The simplest way to map the relationship:
What it describes | The core question it answers | |
|---|---|---|
Metered billing | The measurement system | How do we capture and count consumption? |
Usage-based billing | The pricing strategy | How do we translate consumption into charges? |
Time-based billing | The unit of measurement | Are we measuring events or time? |
Metered billing and usage-based billing are not competing models. Metered billing is the prerequisite for usage-based billing. You cannot price per event without reliably counting events first. Teams that invest heavily in pricing strategy before solving their measurement layer find that their invoices diverge from reality over time.
Time-based billing sits on a different axis. Time can be metered too, and charges for time can follow usage-based structures. What makes time-based billing distinct is the unit: the clock, not a discrete event.
A product can use all three at once. An AI coding assistant might meter session starts and command executions (metered billing), price them per-unit with volume discounts (usage-based billing), and charge separately for active session hours (time-based billing). Each layer does a different job.
When each model fits
Metered billing fits any product that generates discrete, countable events that map clearly to value. API-first products, AI inference pipelines, communication tools, and storage providers all fit here. The investment is in reliable event capture, not pricing strategy.
Usage-based billing fits when pricing should scale with the customer's success. It works best when consumption is a genuine proxy for value delivered. It lowers entry barriers and supports land-and-expand growth. It struggles when usage is volatile and customers are budget-constrained.
Time-based billing fits when value is continuous rather than event-driven. A session-based AI tutor delivers value for as long as the session runs. An autonomous AI agent creates output over time, not per discrete action. Time-based billing matches the pricing unit to the actual value unit.
The infrastructure question
Most billing platforms were built for one model and retrofitted for others. A platform designed for flat subscriptions can bolt on usage charges but treats them as edge cases. A platform built for usage-based billing often has no clean model for time-based access patterns.
This is where product teams burn engineering hours. Metering infrastructure needs to be built and maintained. Webhook sync between the billing system and the product access layer needs to be correct at every state transition: trial start, upgrade, downgrade, cancellation. Each platform adds its own DIY layer for the parts it did not build natively.
Tiun handles both subscriptions and time-based billing through the same integration. Auth, checkout, and access control are included. There is no webhook logic to write or maintain. The SDK covers both product types, and the Merchant of Record layer handles tax compliance and international payments without separate configuration.
The cost of getting this wrong is not just engineering time. It shows up in customer trust. An invoice that does not match what a customer experienced, whether because a timer drifted, an event was double-counted, or a billing window was miscalculated, is a support ticket that becomes a churn conversation. These are not edge cases. They are predictable failure modes of billing infrastructure that was not built for the model it is running.
Three patterns appear consistently across teams that build this wrong.
Metering events when the value unit is time. An AI product that delivers value through session quality, not action count, will meter things like message exchanges or page loads and notice that high-value customers do not look like high-usage customers. The metric and the value are misaligned. Invoices end up charging active users less than passive ones.
Treating UBB as a pricing decision before solving measurement. Teams spend weeks designing tier structures and credit models before their event pipeline is reliable. When the meter is wrong, the pricing on top of it is wrong too. A well-designed tier structure running on a leaky event pipeline will still produce incorrect invoices.
Building billing infrastructure in isolation from access control. Billing and access are the same system expressed twice. When a customer upgrades, downgrades, or hits a usage threshold, both the invoice and the product access layer need to update together. Most platforms leave the sync logic to the developer. Webhook handlers that bridge billing events to access state are not complex individually, but each transition is a potential failure point under load.
What this means for your product
Start with the unit of value. What does your customer actually consume? If it is events, build metered infrastructure and design pricing on top of it. If it is time, choose a billing model with native time-based support rather than bending an event-metering system to fit.
Then ask whether your billing platform handles the model natively or as an add-on. The bolt-on versions work until they do not, and the failure mode is usually silent: events drop, timers drift, invoices diverge, and customers notice before you do.
Metered billing counts. Usage-based billing prices. Time-based billing measures the clock. Know which one fits your product, then pick infrastructure that treats it as a first-class model, not an afterthought.
Frequently asked questions
Is usage-based billing the same as metered billing?
No. Metered billing is the measurement system that counts consumption events. Usage-based billing is the pricing strategy that translates those measurements into charges. You need metered billing to implement usage-based billing, but metered billing on its own says nothing about what you charge per unit or how rates scale with volume.
When should you use time-based billing instead of event-based metering?
When the value delivered is continuous rather than discrete. If a customer gains value from how long something runs, not from a countable action inside it, a timer is a more accurate proxy for value than an event counter.
Consulting is the clearest case. A one hour advisory call has no meaningful events to count. The value is the hour. The same logic covers autonomous AI agents that produce output over a run rather than per action, session-based tutoring, and compute environments held for variable durations. Event metering on any of these produces the same failure: your highest value customers do not look like your highest usage customers, because the metric and the value have come apart.
How does time-based billing work for consulting and 1:1 sessions?
It replaces the invoice. A consultant billing a one hour call today runs the session, then writes up an invoice afterwards, sends it, and follows up on it. Time-based billing charges automatically against the time actually recorded, so no invoice gets written at all.
The larger gain is what gets captured that normally does not. Manual invoicing tends to bill the round number that was agreed, which quietly writes off three categories of real work. Preparation before the call. Overrun, when a booked hour runs to seventy minutes because the conversation was going somewhere. Post-session work, such as the write-up, the summary, or the follow-up notes. A consultant who bills the clean hour absorbs all of it. Metered time bills each segment at the agreed rate, and the client sees exactly what they are paying for rather than a lump sum they have to trust.
That transparency cuts both ways, which is the point. The client is charged for fifty minutes when the session runs short, and the consultant is paid for the preparation they actually did.
Can a product use metered billing, usage-based billing, and time-based billing at once?
Yes, and many do. A developer tool might meter discrete API calls, apply tiered per-unit pricing to those calls, and separately charge for the hours a compute environment stays running. Each layer addresses a different dimension of consumption. The requirement is that each model applies to the right part of the product, not that only one can exist.
What is the most common mistake teams make when choosing a billing model?
Choosing a pricing model before validating the measurement layer. Teams spend weeks designing tier structures, credit systems, and volume discounts before confirming that their event pipeline captures usage correctly. If the meter drops events under load or miscounts aggregation windows, the pricing built on top of it produces incorrect invoices no matter how well the pricing model was designed. Solve measurement first, then design pricing.