There’s a sentence buried in a Bain & Company report on AI pricing that should be tattooed on the forearm of every founder building in this space: “The specific meter is the strategy.”[2] Not the headline. Not the press release. Not whether you call it “usage-based” or “outcome-based” or “AI-native.” The actual unit you bill on — the meter — is where your business model lives or dies.
Most founders get this backwards. They pick a pricing philosophy first (“we’re outcome-based!”) and then scramble to find a metric that fits the narrative. What you should be doing is the opposite: start from what you can measure, what your customer actually values, and what your cost structure looks like — then build the meter that bridges all three. Everything else is branding.
The Three-Model Confusion
Let’s clear up a terminology problem that’s causing real strategic damage. When people say “usage-based pricing” for AI, they’re usually conflating three genuinely distinct things:[2]
Effort-based pricing charges for what the AI consumes — tokens, compute hours, GPU cycles, agent runtime. This is the infrastructure layer. It’s honest about costs, but it punishes customers for complexity. A user who asks your agent to do something hard pays more than one who asks something easy, even if both get equivalent business value. Worse, it actively discourages the deep, high-context reasoning tasks that make your product actually useful.
Output-based pricing charges for what the AI produces — summaries generated, records updated, leads scored, emails drafted. The vendor gets paid regardless of whether the output creates value. You ship a draft; customer pays. Whether the draft converts or gets deleted is their problem. This is where most of the market actually lives right now — roughly 55% of AI-native and seat-based SaaS companies using a non-seat meter are billing on outputs.[2]
Outcome-based pricing charges for a business result — a customer issue resolved, a fraud case recovered, a deal closed. The vendor assumes execution risk. Payment depends on whether the thing actually worked. Only about 10% of companies are here yet.[2]
These are not points on a spectrum. They’re fundamentally different risk allocations between you and your customer. Calling all three “usage-based” is like calling a taxi, a bus pass, and a moving company all “transportation pricing.” Technically true, practically useless.
Why Effort-Based Pricing Is Eroding
Inference with a large model like GPT-4 or Claude can run $0.10–$0.20 per query.[4] That’s before you layer in data transfer, storage, orchestration overhead, and the cost of the agent retrying when it fails. If you’re billing customers on tokens and your backend costs are also token-denominated, you’ve essentially become a compute reseller with a thin margin and zero pricing power.
The deeper problem is what I’d call the complexity penalty. Effort-based meters charge more when the problem is harder. But from a customer’s perspective, harder problems are exactly where they need AI most — and where they’re most willing to pay. You’ve inverted the value curve. The customer doing a trivial extraction task pays pennies; the customer running a multi-step reasoning chain that replaces an analyst pays dollars. But the analyst-replacement customer is the one with real willingness to pay, and you’ve accidentally priced them out of deep engagement.[6]
This is what I’ve been calling the token tax — the hidden cost of a pricing model that punishes the exact behavior that creates the most value.
The Output Model: More Honest, Still Incomplete
Output-based pricing is a real improvement over effort-based in one crucial way: it decouples your price from your cost. You’re no longer a compute reseller. You’re charging for something the customer can point to and count.
But the gap between output and outcome is where the trust problem lives. If I pay per summary generated, I have no incentive to care whether the summary was accurate, useful, or acted upon. My incentive is to generate summaries. Your incentive is to generate summaries. Neither of us is incentivized to care about whether the summaries actually helped.
For enterprise buyers — the ones with real budgets and real procurement scrutiny — this is increasingly a problem. CFOs can approve a defined commitment more easily than an open-ended variable model,[2] but they’re also getting smarter about the difference between outputs and outcomes. Paying for 10,000 AI-generated summaries that nobody read is the new “paying for 50 seats that nobody logged into.”
The Outcome Model: Right Idea, Hard Execution
Outcome-based pricing is the intellectually honest answer. It aligns your incentives perfectly with your customer’s. You get paid when they win. But it comes with three hard problems that most founders underestimate.
Attribution is brutal. When Klarna’s AI resolves a customer service query in under 2 minutes with satisfaction scores equivalent to a human agent,[3] that’s a clean outcome. But most enterprise workflows aren’t that clean. Did the AI close the deal, or did the sales rep? Did the AI prevent the churn, or did the customer success team? The more complex the workflow, the harder it is to isolate the AI’s contribution — and the harder it is to bill for it without a contractual dispute.
Measurement latency kills cash flow. If you’re billing on resolved customer issues, you need to wait for resolution. If you’re billing on revenue influenced, you might wait 90 days for a deal to close. You’re essentially extending credit to your customers while your inference costs hit immediately. This is a working capital problem that pure outcome models create and that most early-stage companies can’t absorb.
Customers may game the definition. Whatever outcome you agree to measure, your customer has an incentive to define it narrowly. “Resolved” means different things to different people. Contracts get complicated. Sales cycles get longer.
The Practical Answer: Hybrid Architecture with a Clear Primary Meter
The market is converging on a structure that I think of as “platform plus outcome” — and it’s the most defensible architecture for most AI-native products right now.
The mechanics look like this: charge a monthly platform fee (think $500–$2,000 for mid-market, $5,000–$20,000 for enterprise) that covers access, integrations, analytics, and a base allocation of outcomes. Beyond that allocation, charge per outcome.[3]
This structure solves several problems simultaneously. The platform fee covers your fixed costs — infrastructure, support, account management — regardless of usage. Without it, a low-volume customer doing 50 resolutions at $0.99 each generates $49.50 in revenue, which doesn’t cover the cost of serving the account. The per-outcome overage captures upside from heavy users without penalizing them for the complexity of their work. And the combined structure gives enterprise procurement teams the budget predictability they need to get a deal approved.
The key insight is that the platform fee isn’t just a revenue floor — it’s a commitment signal. Customers who pay a meaningful platform fee have skin in the game. They’ll actually use the product. Pure consumption models with no floor attract tire-kickers who sign up, generate 50 events, and churn before you’ve recouped acquisition cost.
You Can’t Bill for What You Don’t Track
None of this works without data infrastructure that’s built for pricing flexibility. The principle here is simple: capture more dimensions than your current pricing model requires.[1]
For every interaction your AI agent takes, you should be recording: which endpoint was accessed, what resources were consumed, what the intermediate outputs were, and — critically — what business outcome resulted (or didn’t). You don’t have to bill on all of these today. But if you don’t capture them, you can’t pivot your pricing model without a full instrumentation rewrite.
This is the mistake I see most often in early-stage AI companies. They instrument for their current pricing model, not for the pricing model they’ll need in 18 months. Then when the market signals that outcome-based is where enterprise buyers are going, they’re stuck. The data to support the billing doesn’t exist. They have to choose between a multi-quarter engineering project and leaving money on the table.[1]
Build the data layer for the model you want, not the model you have.
Know Your Unit Economics Before You Set Any Price
This is non-negotiable regardless of which meter you choose: you need to know your AI and cloud infrastructure costs down to the penny.[4] Every API call, every inference, every database query, every retry when the agent fails. You need to know how much each model costs per query, how storage and data transfer fees compound at scale, and how your costs change as task complexity increases.
Without this, any pricing strategy is guesswork. You’ll either underprice and bleed margin at scale, or overprice and lose deals to a competitor who did the math. Neither outcome is recoverable without significant pain.
The companies that will win the AI pricing wars aren’t the ones with the cleverest pricing page. They’re the ones who understand their cost structure well enough to price with confidence, instrument their product well enough to bill on what actually matters, and choose a meter that aligns with how their customers experience value — not how their engineers think about compute.
The meter is the strategy. Build it deliberately.
References
- From Seats to Success: Building Flexible SaaS Pricing for AI Products — The New Stack — https://thenewstack.io/from-seats-to-success-rethinking-saas-pricing-in-the-age-of-ai
- AI Pricing: A Reality Check on Effort, Usage, and Outcomes — Bain & Company — https://www.bain.com/insights/ai-pricing-a-reality-check-on-effort-usage-and-outcomes
- Outcome-Based Pricing for AI SaaS: Models That Work in 2026 — Kanopy — https://kanopylabs.com/blog/outcome-based-pricing-ai-saas
- How SaaS Companies Can Profitably Price AI Agents — CloudZero — https://www.cloudzero.com/blog/ai-agent-pricing-models
- How do outcome based AI pricing strategies work for modern software platforms? — withtai.com — https://withtai.com/knowledge/how_do_outcome_based_ai_pricing_strategies_work_for_modern_software_platforms.php
Leave a Reply