Every AI pricing conversation eventually comes down to four practical variants: per-token, per-outcome, per-agent, and per-seat with a credit pool. Vendors pitch them as fundamentally different philosophies. In practice, they solve for different combinations of predictability, margin protection, and buyer comprehension. The right choice is not necessarily the most sophisticated one. It’s the one that survives contact with your unit economics and your customer’s buying pattern.
This is an AI pricing model comparison, not a ranking. Each model works in some scenarios and breaks in others. Read on to learn where each one fits, what it costs you when it doesn’t, and how to think about the hybrid combinations most enterprise AI products end up using.
Per-Token Pricing
With per-token pricing, the customer pays a rate per token processed, usually with separate rates for input and output tokens. This is the simplest model to explain to a technical buyer. Direct link to infrastructure cost. Standard for developer-facing AI APIs. OpenAI, Anthropic, Cohere, and every other major LLM provider uses some variant of it.
The tradeoff is buyer comprehension. Business buyers don’t know what a token is and can’t forecast their spend against a token-priced product. That’s fine when the buyer is a developer building against your API. It’s a problem when the buyer is a finance team trying to budget for the year.
Per-token works when: your buyer is technical, your product is an API or a developer tool, and your customer instrumentation is good enough that they can measure their own consumption. Per-token breaks when: you’re selling to non-technical business buyers who want a predictable annual number, or when your inference costs move month-to-month and you don’t have a mechanism to reprice without renegotiating contracts.
Per-Outcome Pricing
The customer pays only when the AI successfully completes a defined task. Ticket deflected, deal qualified, fraud event caught. Strongest value alignment of any pricing model. Highest willingness to pay when the outcome is measurable and clearly attributable.
The operational reality is harder than the pitch. Success has to be defined precisely enough to be audited. Attribution has to survive a customer dispute. The billing system has to rate variable outcomes and hold revenue until the outcome is confirmed. Public examples that make it work: Intercom Fin (per ticket resolution), Riskified (per approved transaction), and Decagon (per conversation resolution). What they share is a clean success signal that the AI system itself generates and the customer can verify.
Per-outcome works when: the outcome is discrete, measurable at event granularity, and generated by a system rather than by human judgment. Per-outcome breaks when: the outcome definition can’t survive an attribution argument, when customers dispute what counts as success, or when your platform doesn’t support holding revenue against pending outcomes. Revenue recognition for outcome-based pricing runs on ASC 606 variable consideration with reversal risk on unconfirmed outcomes, which is one of the more accounting-intensive treatments in the guidance.
Per-Agent Pricing
The customer pays per agent instance or per agent task, usually with a monthly minimum. The model works when the agent is a discrete unit of value that the customer can attribute to a specific process. It sits somewhere between per-outcome (which requires success) and per-seat (which decouples from usage) in operational complexity.
The practical variant that has traction is per-agent-task: charge for each unit of work the agent completes, with a defined scope of what constitutes a task. Different agents can consume different rates depending on their function. Sales development agent, customer support agent, procurement agent. Each has its own unit cost and its own price.
Per-agent works when: the agents perform discrete units of work that map to identifiable customer processes, and the customer can attribute usage to specific outcomes without needing a per-outcome billing structure. Per-agent breaks when: the agents work in loops or asynchronous cycles that don’t map cleanly to a countable unit, or when the customer’s consumption spikes in ways they can’t forecast. Some vendors are also using per-agent as an entry price with a per-outcome overlay on top, which combines the predictability of a subscription base with the value alignment of outcome-based.
Per-Seat with a Credit Pool
Each licensed seat contributes to a shared pool of AI usage credits. The pool is drawn down as any user runs an AI action. Auto top-ups or tier upgrades fire when the pool is exhausted. GitHub Copilot Business, Notion AI, Miro AI, and Figma AI all use variants of this.
The commercial logic is that it preserves the seat-based buying motion the enterprise is used to while introducing a consumption component that scales with actual AI adoption. It solves the “we sold seats to a company where half the users never touch the AI” problem, because the credit pool absorbs the variance across users.
Per-seat with a credit pool works when you have an existing seat-based commercial motion you want to preserve and when usage varies significantly across users so a pooled model produces a fair average. It breaks when your buyer is a small team where usage is concentrated in a handful of users (the pool doesn’t protect margins because most seats don’t consume), or when credit accounting complexity exceeds what your billing platform can handle without manual reconciliation. The accounting sits on deferred revenue for the credit issuance and consumption-based recognition for the drawdown, which is well-established under ASC 606 but requires the credit-to-cost mapping to be documented and consistent.
Where the Hybrids Actually Land
Most enterprise AI products end up hybrid. The two most common combinations are:
- Subscription plus usage overage. The customer pays a monthly subscription that includes a base allotment of AI usage. Overage is billed at a rate per unit. Predictable base revenue, upside on adoption. This is the default enterprise SaaS packaging pattern applied to AI.
- Seat plus credit pool plus outcome-based components. A seat-based subscription for the base product, a shared credit pool that governs AI feature usage, and an outcome-based charge for a discrete set of high-value AI tasks. Complex to configure. Also, this model survives the widest range of customer buying patterns, which is why enterprise AI products end up here.
The platform decision underneath is the constraint that determines whether the hybrid is possible. A billing engine that cannot rate multiple models on the same invoice forces the business to pick a simpler model than the market rewards. That platform limitation is one of the most common reasons AI monetization strategies get watered down between the pricing design and the customer contract.
How to Pick an AI Pricing Model
The choice is not “which of these is best.” It’s “which of these fits our unit economics and our customer’s buying pattern.” Three questions get you most of the way there.
First, what does the unit cost look like? Per-transaction unit economics determine which model can be priced without eroding margin. If your unit cost is high and variable, per-outcome or per-agent-task give you the tightest link between price and cost. If your unit cost is low and predictable, per-seat with a credit pool absorbs the variance without requiring you to price each event.
Second, who is your buyer? Technical buyers can forecast per-token spend. Business buyers can’t. If the buyer is finance or procurement, the model needs to produce a number they can budget against.
Third, what does your platform actually support? The most defensible pricing model your platform can’t rate is worth less than the second-best model it can rate cleanly. Push on the platform question before you commit to the pricing question.
For the complete framework covering all nine AI monetization models and how to build the strategy upstream of the model choice, see billingplatform.com/ai-monetization.
BillingPlatform rates every model above on a single engine, without integration code between subscription, usage, credit, and outcome billing. See how it works at billingplatform.com.
