Your Usage Meter Is Not a Pricing Strategy

Usage-based pricing is having one of those moments where everyone is suddenly fluent in the vocabulary and still dangerously underprepared for the work.

Founders now know the nouns: meters, events, credits, entitlements, overages, thresholds, graduated tiers. They know the examples: Twilio charges by message or call, Slack layers per-user pricing into tiered plans, Microsoft Copilot combines a per-user base with credits for spikes, and Zendesk and Salesforce Agentforce are experimenting with AI pricing tied to resolutions or conversations.^[1] They have heard that hybrid pricing is where the market is going. They have probably been told by an investor, advisor, or board member that “AI should be usage-based.”

All of that may be true. It is also not enough.

The mistake I see most often is treating the meter as the pricing strategy. It is not. The meter is the instrumentation. The strategy is what you choose to make the customer believe, predict, compare, approve, and expand.

That distinction matters more now because usage pricing is no longer an edge-case motion for API companies. It is moving into mainstream B2B software. One recent SaaS pricing guide notes that usage-based pricing is one of the fastest-growing SaaS models heading into 2027, while another reports that 67% of SaaS companies now use some form of usage-based component, up from 52% in 2022.^[1][2] Hybrid models—subscription plus usage—also reportedly show the highest median growth rate at 21%, outperforming pure subscription and pure usage approaches.^[2]

That growth statistic is seductive. But if you copy the shape without understanding the psychology, you can end up with the worst of both worlds: unpredictable bills for customers and unpredictable revenue for you.

Metering is infrastructure. Pricing is a promise.

Let’s clean up the language first.

Usage-based pricing is the strategic decision to charge based on consumption. Metered billing is the system that measures that consumption accurately enough to invoice against it.^[6] If you charge $0.002 per API request, the pricing model is usage-based; the metering system is the machinery that counts requests, applies the rate, handles thresholds, and produces a bill.

This sounds obvious until a pricing meeting turns into a billing architecture meeting.

A founder will say, “We can track tokens, runs, storage, projects, automations, documents, and seats. Which should we price on?” That is a measurement question masquerading as a monetization question. The better question is: which unit does the customer already associate with value, control, and fairness?

A good value metric does three jobs at once:

1. It grows as customer value grows.
2. It is easy for the buyer to understand before they buy.
3. It is hard for the customer to resent after they succeed.

Miss any one of those and the model starts to wobble.

Tokens, for example, are often measurable but not meaningful. A customer does not wake up wanting 80 million tokens. They want resolved tickets, completed analyses, qualified leads, signed contracts, clean invoices, or fewer human hours spent on repetitive work. That is why the move toward per-resolution or per-conversation pricing in AI support tools is strategically interesting: it shifts the discussion closer to a business outcome rather than an invisible compute input.^[1]

But outcome-adjacent pricing has its own danger. The closer you price to value, the more you invite scrutiny about causality. Did your product really resolve the issue? Did the agent really create the opportunity? Would the customer have achieved the outcome anyway? This is where pricing design and product telemetry have to meet.

The hybrid model won because pure usage scared both sides

Pure usage pricing is elegant in a spreadsheet. Customers start small. Usage expands with value. Revenue grows without a renewal fight. In theory, everyone wins.

In practice, pure usage often creates anxiety.

The customer wonders: “What will this cost if we actually roll it out?”

Finance wonders: “How do we forecast this vendor?”

Your CFO wonders: “How do we forecast revenue?”

That is why so many companies land on hybrid pricing after flirting with pure consumption. Event-based billing guides describe the common pattern clearly: a base subscription provides revenue predictability, while the usage component captures upside as consumption grows.^[3] The hybrid model is not popular because it is theoretically pure. It is popular because it gives both sides a handrail.

The base fee says: “You have access, support, security, administration, and a committed relationship.”

The usage fee says: “If you get more value, we participate in that upside.”

The trick is deciding what belongs in the base and what belongs in the meter.

I like to use a simple test:

• Put table-stakes adoption features in the base.
• Put scale-sensitive value in the meter.
• Put enterprise control and risk reduction in higher packages.

Do not meter the thing that creates the habit too early. If every exploratory action feels like it has a tax attached, customers will ration the very behavior you need them to adopt. Meter what scales after the product has become useful.

This is especially true in AI products. If you meter every prompt, run, or agent action from day one, the customer starts managing anxiety instead of discovering value. A better structure may be a committed monthly allowance, a clear included usage band, and overages only after the customer has crossed into meaningful production volume.

That is not just nicer packaging. It is expansion design.

The best meter is usually not the most precise meter

Technical teams tend to love precise meters. Pricing teams should be more suspicious.

Precision is not the same as perceived fairness. A beautifully accurate meter can still feel absurd if it charges for something the buyer experiences as internal plumbing.

Consider AI workflow software. You might be able to meter:

• tokens consumed
• model calls
• agent steps
• workflow runs
• documents processed
• seats
• active projects
• successful outputs
• connected systems
• human hours saved

Some of these are cost drivers. Some are value indicators. Some are merely implementation details wearing a pricing costume.

The customer does not care that one workflow took 47 agent steps and another took 12 unless they have been trained to believe steps equal value. In many cases, charging per agent step is like a restaurant charging per turn of the oven fan. It may reflect cost. It does not reflect how the buyer thinks.

This is where founders need to separate three concepts:

Cost metric: what drives your gross margin.

Usage metric: what customers consume.

Value metric: what customers believe they are paying for.

Sometimes one metric can do all three jobs. API calls can work because they are often both the product experience and the cost driver. Payment volume can work because it scales with customer activity and value. Storage can work when storage is the thing being bought.

But in AI SaaS, the cost metric and the value metric often diverge. Model calls, tokens, and compute seconds may drive cost, while the customer values completed work. If you expose only the cost metric, you train the buyer to audit your inputs. If you expose only the value metric, you may absorb too much cost volatility. The model needs shock absorbers.

Those shock absorbers can be commitments, credits, fair-use bands, throttles, overage caps, or package-level entitlements. The point is not to hide usage. The point is to make success feel safe.

Billing complexity is now a strategic constraint

The Stripe-Metronome deal was a useful flare in the sky. Stripe reportedly paid $1 billion for Metronome, the usage-based billing infrastructure behind companies including OpenAI, Anthropic, Confluent, and NVIDIA, and described usage-based models as a defining feature of the next decade.^[8]

That is not just a billing story. It is a pricing strategy story.

When billing infrastructure becomes acquisition-worthy at that scale, it tells you something about where the pain has moved. The hard part is no longer only “Can we charge a subscription?” The hard part is:

• Can we meter events correctly?
• Can we rate them in real time?
• Can we combine subscriptions, usage, discounts, credits, and one-time fees on one invoice?
• Can sales explain the contract?
• Can finance forecast the revenue?
• Can customers verify the bill?
• Can customer success intervene before bill shock becomes churn?

Hybrid pricing can produce stronger growth, but it can also make forecasting and cash-flow planning harder when every customer effectively has a different price curve.^[2] That complexity is not a back-office nuisance. It changes what sales can sell, what customers will approve, and what expansion looks like.

A pricing page that says “custom usage-based pricing” may be accurate. It may also be a conversion graveyard.

The buyer needs to know the shape of the bill before they trust the meter.

The pricing page has to teach the customer how to buy

A usage or hybrid pricing page has a heavier job than a traditional three-tier SaaS page. It has to answer four questions quickly:

1. What do I pay to get started?
2. What is included before variable charges begin?
3. What makes the bill go up?
4. How do I control it?

Most weak usage pricing pages answer only the third question. They list the meter. They do not explain the guardrails.

A better page shows the customer the operating model. For example:

• “Plans start with a monthly platform fee.”
• “Each plan includes X units of usage.”
• “Additional usage is billed at Y rate.”
• “Admins can set alerts and hard caps.”
• “Volume discounts apply automatically after Z.”
• “Enterprise plans include custom commitments and governance.”

This is not hand-holding. This is conversion architecture.

Remember: the customer is not only evaluating your price. They are evaluating whether they can defend your price internally. A simple per-seat model gives them an easy story: 100 people times $40. Usage pricing requires a different story: expected consumption, likely variance, budget controls, and the business reason consumption will grow.

If you do not provide that story, your champion has to invent it. Most champions are busy. Do not make them become your pricing strategist.

Beware parity pricing when your risk profile is different

One of the more useful pricing observations from the AI infrastructure world is that “cheaper but riskier” only works if it is actually cheaper. In a SaaStr discussion of Kimi K3 pricing at roughly Claude Sonnet parity, the point was blunt: if an open-weight option carries more perceived risk but prices at parity, the buyer is taking extra risk for free—and serious CIOs do not love that trade.^[5]

This applies beyond model providers.

If your product is newer, less integrated, less compliant, less proven, or more operationally demanding, parity pricing with the incumbent is not automatically bold. It may be incoherent. Premium pricing requires a premium reason. Parity pricing requires parity in risk, trust, and adoption cost.

Founders often compare feature grids and conclude they deserve the same price. Buyers compare blame surfaces. If the project fails, who gets blamed? If the invoice spikes, who explains it? If the AI output is wrong, who owns the risk? If procurement asks for auditability, who does the work?

There was a line in that same discussion worth carrying into every AI pricing room: “You can inspect it” only counts as an answer if someone can do it at a cost someone would pay.^[5]

Pricing has to reflect not just technical capability, but the customer’s cost to trust you.

A practical framework for choosing your usage metric

When I work with founders on usage or hybrid pricing, I usually force the team through five questions before we touch the pricing page.

1. What behavior do we want to encourage?

Pricing is behavioral design. If you charge per seat, you may discourage broad adoption. If you charge per workflow, you may encourage consolidation. If you charge per successful output, you may encourage experimentation but invite disputes over attribution.

Write down the behavior your model rewards. Then ask if that behavior matches retention and expansion.

2. Does the customer understand the unit before using the product?

A buyer can estimate seats. They can often estimate transactions. They may estimate documents, contacts, messages, or GB processed. They probably cannot estimate “agentic reasoning steps.”

If the buyer cannot forecast the unit, you need a package, allowance, calculator, benchmark, or onboarding estimate.

3. Does the unit scale with value or merely activity?

Bad usage metrics punish busyness. Good usage metrics monetize progress.

If a customer has to run the same task five times because your product failed four times, should they pay five times? Probably not. If your AI agent takes more steps because the task is complex, is that more valuable or just more expensive? It depends. Do not let your internal architecture answer a customer-value question by accident.

4. Where does gross margin break?

You cannot ignore cost. AI has made that obvious. A charming pricing model that explodes at high usage is not customer-centric; it is just delayed panic.

Model your heaviest users. Model abuse cases. Model customers who use only the expensive features. Then decide where you need throttles, committed spend, volume discounts, or enterprise terms.

5. What does the customer need to feel in control?

This is the question teams skip.

Usage pricing without controls feels like handing a vendor your credit card and hoping their product succeeds politely. Controls are part of the offer. Alerts, caps, admin permissions, dashboards, prepaid credits, and approval workflows all increase willingness to pay because they reduce perceived risk.

A customer who feels in control will use more. A customer who fears surprise will ration.

The winner is not pure subscription or pure usage

The market is not marching toward one perfect SaaS pricing model. It is marching toward better alignment between price, value, cost, and trust.

Flat-rate pricing still works when simplicity is the differentiator. Basecamp’s unlimited plan remains a famous example, though even Basecamp has added a per-user Plus plan—proof that even simplicity-first companies sometimes evolve toward more segmented structures.^[2] Per-seat pricing still works when human access is the main value driver. Tiered pricing still works when packaging differences are obvious. Usage-based pricing works when consumption tracks value and customers can forecast it. Hybrid pricing works when you need a floor, upside, and customer confidence.

The model is not the point. The fit is the point.

If you are adding usage pricing this year, do not start with, “What can we meter?” Start with, “What promise are we making, and what should happen to price when the customer realizes that promise?”

Then build the meter.

Because a meter can count consumption. It cannot, by itself, create willingness to pay.

References

1. SaaS Pricing Models: The Complete Guide for Businesses — https://vinzotechblog.com/saas-pricing-models
2. SaaS Pricing Models & Strategies: The Complete Guide (2026) — https://www.cloudzero.com/blog/saas-pricing
3. Event-Based Billing Explained: Examples & How to Build It | Lago — https://getlago.com/blog/events-based-billing
4. Jason’s Takes on This Week’s 20VC: The Toggle Is a Permission Grant, The Blame Test Decides the Deal, and Why Five Years of Price Increases Is a Countdown | SaaStrAI — https://www.saastr.com/jasons-takes-on-this-weeks-20vc-the-toggle-is-a-permission-grant-the-blame-test-decides-the-deal-and-why-five-years-of-price-increases-is-a-countdown
5. What Is Metered Billing? How It Works | Lago — https://getlago.com/blog/what-is-metered-billing
6. 5 Interesting Learnings from Stripe at $6.8 Billion in Revenue — https://www.saastr.com/5-interesting-learnings-from-stripe-at-6-8-billion-in-revenue-33-growth-47-free-cash-flow-margins-and-a-53b-bid-for-paypal

Generated by AI · OpenAI · gpt-5.5