Pricing a taxi ride by the number of gear shifts would be measurable, auditable, and completely disconnected from the value of the ride. That is roughly what happens when an AI product defaults to token pricing. The metric is easy to instrument, and nobody checked whether it means anything to the person paying.
The deeper issue is framing. Price tokens and you have described your product as infrastructure, and infrastructure gets commoditized. What an AI agent actually sells is work completed: tickets resolved, contracts reviewed, leads qualified, documents processed. That is a different thing to put a price on, and it needs a different metering layer underneath.
This walks through the five models AI companies are actually running, what each one demands from billing, and where each one breaks.
Read the detailed piece on how to price your AI agent.
Short answer
Price the unit of work your agent completes, not the compute it burns completing it. Usage-based fits API and developer products, credits fit multi-feature products, outcome pricing fits agents with a clean success signal, subscriptions fit predictable workloads, and hybrid fits most companies at scale because it holds a revenue floor while letting heavy users pay for what they consume.
Why AI pricing breaks SaaS assumptions
Three assumptions stop holding.
Software access became work completed. Traditional tools help a user do a task. An agent does the task. A support agent resolves tickets, a sales agent runs outbound, a research agent analyzes documents. What the customer receives is finished work, not a login.
Near-zero marginal cost became real compute cost. Serving one more SaaS user costs almost nothing. Serving one more agent request triggers model inference, API calls, data processing, and orchestration. Cost now grows with usage, so a mispriced model does not just underperform. It inverts your margin as you grow.
Seats became units of work. Agent value is not tied to individual users. It is tied to documents analyzed, tickets resolved, workflows executed, conversations handled. Per-seat pricing has nothing to attach to.
Which leaves one question to answer before anything else: what unit of value should the customer pay for?
The four problems that show up once usage is real
Finding the value metric. Your product emits tokens, API calls, compute time, inference requests. None of those mean anything to a buyer. The work is translating infrastructure metrics into customer-facing ones that are both easy to understand and honestly correlated with the value delivered.
Usage unpredictability. A customer can send a few hundred requests one day and thousands the next. Customers want predictable bills, and AI workloads are inherently variable. Those two things are in direct tension, which is why credit and hybrid models exist.
Margin protection. Every request consumes inference, storage, orchestration, and compute. AI companies operate on tighter margins than classic SaaS, so heavy usage that is priced wrong does real damage rather than just leaving money on the table.
Billing infrastructure sprawl. The common starting point is Stripe for payments, usage tracking in internal scripts, entitlements behind feature flags, and pricing math in a spreadsheet. It holds until it does not, usually right when usage becomes worth billing carefully.
How to choose: four questions
What job does the agent do?
Start from the task being automated, not the stack underneath. Resolving support tickets, analyzing documents, generating outreach, executing workflows. That job is the foundation of the model.
What is the natural unit of work?
Translate the job into something countable that the customer already cares about. Conversations handled, documents processed, workflows executed, tasks completed. A legal tool charges per contract analyzed. A support agent charges per ticket resolved.
The gap between a bad metric and a good one is usually this stark:
Weak metric: $0.002 per 1k tokens
Better metric: $0.10 per document analyzed
Same underlying compute. Only the second one can be reasoned about by a buyer.
How predictable is the workload?
If usage swings hard between customers, pure subscription pricing will hurt. Usage-based and credit models absorb variance because price scales with activity.
What does the agent cost to run?
Model inference, infrastructure, orchestration complexity. A workflow that chains several model calls costs meaningfully more than a single prompt. Cost should not set your price, but it has to bound it.
Credit-based pricing
Credit pricing converts usage into a single virtual currency. Rather than exposing a dozen separate meters, you give the customer one balance and assign each action a credit cost.
{
"generate_image": 5,
"process_document": 1,
"run_workflow": 2,
"analyze_contract": 3
}
Why it works. It collapses a multi-feature product with wildly different compute costs into one number the customer can track. It enables prepaid bundles, which improves cash flow and caps exposure to heavy workloads. And it gives customers a visible budget to monitor instead of an invoice to fear.
What it needs from billing. A per-customer wallet, a mapping from product action to credit cost, and atomic deduction as events arrive. Balances have to update as usage lands, not at invoice time, or the customer-facing number is fiction.
Flexprice implements this with credit wallets and prepaid and promotional balances, with low balance alerts wired to the same ledger.
Where it breaks. Credit-to-value opacity. If nobody can explain what 50,000 credits buys them, you have reintroduced the token problem with extra steps.
Usage-based pricing
Charge on measured activity. Tokens generated, API calls, workflows executed, requests handled.
1M tokens processed $1.50
workflow executed $0.05
document processed $0.10
When it fits. Workloads vary a lot, customers want pay-as-you-go, and the product genuinely is infrastructure or an API. Model APIs price per token because developers expect price to track compute, and in that context it is the honest metric.
What it needs. Real-time metering over a high-volume event stream, pricing rules attached to metrics rather than baked into application code, and invoices generated from metered events. The path is: agent does work, backend emits an event, the meter matches it against the customer's plan, the pricing engine rates it, usage appears in the dashboard. Aggregation choice matters here, and the aggregation types page covers sum, count, unique count, and the rest.
Where it breaks. Bill shock, and a revenue floor of zero. A quiet month is a quiet invoice.
Outcome-based pricing
Charge for the result, not the activity that produced it.
support ticket resolved $0.50
qualified lead generated $3.00
contract reviewed $1.00
invoice processed $0.20
Why it appeals. Incentives line up. More value delivered means more revenue, and the customer can justify the line item internally because it maps to a business result. Paying per resolved ticket connects cost to operational value in a way that paying per token cannot.
What it needs. Custom metrics defined against outcome events, which means your product has to emit ticket.resolved rather than only llm.call. Defining those units is a metered feature concern.
Where it breaks. Attribution and disputes. You need a defensible definition of success, and a customer who disagrees that a ticket was really resolved is now arguing about the invoice.
Subscription pricing
A recurring fee for access. Starter at $29, Pro at $99, Enterprise on request. Predictable, familiar, and still the right call for AI copilots, productivity assistants, and research tools where usage clusters tightly.
Where it breaks. Margin, at the tail. Two customers pay $99. One sends 500 requests, the other sends 50,000. Without limits, the second one is funded by the first, and eventually by you.
The fix is not abandoning subscriptions. It is bounding them with included allowances, feature entitlements, and overage pricing past the limit.
Hybrid pricing
Most mature AI products land here, because it is the only structure that answers both the revenue-predictability and workload-variance problems at once. Subscription plus usage, platform fee plus credits, or subscription plus outcomes.
A typical shape:
$199/month platform fee
includes 10,000 credits
overage billed per unit beyond the allowance
That holds a revenue floor, charges heavy users proportionally, protects margin against compute spikes, and supports customers with very different workloads on the same plan structure. What it demands is a billing system where subscriptions, credit wallets, usage metering, and overage are the same object rather than four integrations. Overage behavior turns on advance versus arrear charges, which is worth understanding before you commit to a billing period.
Four mistakes that repeat
Copying API pricing blindly. Token pricing is correct for an inference provider where usage maps directly to infrastructure. It is usually wrong for an agent completing business tasks. A support agent may burn thousands of tokens on one ticket. The customer is counting tickets.
Letting token cost define price. Cost is an input, not the model. Starting from inference cost and adding margin caps your upside at whatever the model costs this quarter and hands your pricing to your vendor's roadmap.
Ignoring compute volatility. If the model has no mechanism for usage spikes, infrastructure cost climbs without matching revenue. This is the specific reason subscriptions get paired with usage or credits.
Overcomplicating the metric. If a customer has to reason about tokens and compute units and API calls simultaneously to estimate their bill, they will not estimate it. They will hesitate. Clear units of value get adopted and get scaled.
What this means for your billing layer
Every model above is a different arrangement of the same three primitives: an event stream, a rating engine, and a ledger. The reason pricing changes feel expensive is usually that those three things live in application code, spreadsheets, and a payments provider that was never designed to hold them.
Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. Flexprice offers three deployment options, and all three run the same engine.
The point of separating metering from payments is that the pricing model becomes configuration rather than a migration. Price the work, not the tokens, and keep the metric simple enough that a customer can predict their own invoice.
Start with the event ingestion docs to see what metering a unit of work looks like in practice.
