Per-Token, Per-Agent, Per-Outcome: How AI Companies Actually Price

Every AI company eventually asks the same question: what, exactly, are we charging for? A subscription SaaS product charges for a seat. An AI product doesn't have a clean equivalent — a single user might trigger a thousand model calls in an hour, or an autonomous agent might do a week of work with nobody watching. Three pricing models have emerged to answer that question: per-token, per-agent, and per-outcome. Each one ties the bill to a different unit of value, and each one creates a different set of operational problems once you actually have to run it.

This isn't an abstract debate. The model you pick determines what you have to meter accurately, how exposed you are to margin compression as usage scales, and how much trust you're asking customers to extend before they see a bill.

What the three models actually mean

Per-token pricing charges for the raw compute a model consumes — usually a rate per million input tokens and a separate, higher rate per million output tokens. It's the default for foundation-model API access, because tokens are the one unit every model provider can meter identically regardless of what a customer builds on top.

Per-agent pricing charges for a deployed unit of autonomous work, not the compute behind it — a flat rate per active agent per month, or a rate per action an agent takes, positioned as a fraction of what a human doing the same job would cost. The pitch is usually explicit: this agent replaces (or augments) a role, so price it against the role, not against the tokens it happens to burn to do the job.

Per-outcome pricing charges only when the agent actually accomplishes something defined in advance — a resolved support ticket, a qualified lead, a completed workflow step. Nothing is billed for a conversation that goes nowhere. It's the model closest to a services contract: you pay for the result, and the vendor absorbs the cost of every attempt that didn't land.

The three aren't mutually exclusive, and in practice most companies blend at least two of them. But understanding them as distinct primitives first makes it easier to see why teams keep reaching for hybrids.

How real AI companies price today

The clearest per-token pricing lives at the model-provider layer, where the unit of consumption is unambiguous. Anthropic's published API pricing sets Claude Sonnet 5 at $2 per million input tokens and $10 per million output tokens, with Claude Opus 5 at $5/$25 and Claude Haiku 4.5 at $1/$5 — a consistent 5x spread between the cheapest and most capable model in the same lineup on both input and output rates, which is itself a pricing lever: route routine requests to a cheaper model and reserve the expensive one for what actually needs it. OpenAI's API pricing follows the same per-token structure across its GPT model lineup, with equally wide spreads between its smallest and largest models.

Both providers layer real discount mechanisms on top of the base per-token rate, and the discounts themselves are structural, not promotional. Anthropic's Batch API processes requests asynchronously at a 50% discount on both input and output tokens — the tradeoff is latency, not quality, which makes it a natural fit for anything that doesn't need a synchronous response. Prompt caching goes further: a cached read costs roughly 10% of the standard input rate, so a system prompt or a large document that gets reused across many requests gets dramatically cheaper after the first call pays the (slightly higher) cache-write cost. OpenAI publishes an equivalent structure — batch processing at a 50% discount, and cached input tokens priced around 90% below standard input. Neither of these is a workaround; they're pricing designed around the actual cost shape of running a model, where the marginal cost of serving cached or asynchronous work is genuinely lower than a fresh, synchronous call.

Per-outcome pricing looks completely different in practice, and Intercom's Fin is one of the clearest public examples. Fin's own pricing page sets a flat $0.99 per billable outcome — a resolution, a handoff to a human under a configured procedure, or a disqualification — with a separate $9.99 rate for a qualified lead. The definition of "outcome" is deliberately narrow and stated up front: a resolution counts when a customer either confirms the answer helped or simply doesn't ask a follow-up question after Fin's last reply. Critically, Fin bills exactly one outcome per conversation no matter how many actions the agent took internally to get there — a ticket that requires five tool calls and three retrieval lookups costs the same $0.99 as one that resolves in a single reply. That detail matters more than it looks: it means the vendor, not the customer, absorbs the variance in how much compute a given resolution actually took.

Per-agent pricing is the least standardized of the three, and vendors describe it in genuinely different ways — a flat monthly rate per deployed agent, a rate per action an agent completes, or a hybrid seat-like license priced against the human role the agent is meant to augment or replace. The common thread across implementations is positioning, not a single metering unit: the price is set relative to the cost of a person doing the same job, which makes per-agent pricing more of a psychological anchor than a metering strategy. That's also its biggest limitation — a monthly flat rate doesn't naturally scale with how much work the agent actually does, which pushes vendors toward usage caps, tiers, or overage charges layered on top of what was pitched as a simple number.

Where each model creates operational problems

Per-token pricing's problem is margin visibility, not metering. The metering itself is straightforward — every model provider returns exact token counts with every response. The problem shows up one layer up: if you're building a product on top of a foundation model and charging your own customers a flat or tiered rate, your cost per customer is a moving target that depends on prompt length, output verbosity, retry behavior, and which model a given request routed to. A customer who writes verbose prompts or triggers more retries costs meaningfully more to serve than one with the identical plan who doesn't — and without per-request cost tracking tied back to a specific customer and feature, you don't find out which customers are unprofitable until the bill from your model provider arrives at the end of the month.

Per-agent pricing's problem is that a flat rate doesn't track actual usage. An agent priced at a flat monthly rate can be nearly idle for one customer and running thousands of actions a day for another, and the vendor eats that spread — or has to introduce caps, tiers, and overage logic to protect margin, at which point the pricing has quietly become usage-based anyway, just with an extra layer of obfuscation on top. The customers who most want the simplicity of a flat number are usually the ones whose actual usage will eventually force a renegotiation.

Per-outcome pricing's problem is defining "outcome" precisely enough that it can't be gamed from either direction. Too loose, and an agent can be tuned to declare success early — Fin's own definition anticipates this by treating "customer didn't ask a follow-up" as an assumed resolution, which is defensible but also inherently softer than an explicit confirmation. Too strict, and legitimate work goes unbilled because the customer never explicitly confirms, even though the problem is actually solved. Every outcome-based pricing model is a bet on a definition, and that definition has to survive contact with edge cases: partial resolutions, outcomes that unwind after billing (a "resolved" ticket that reopens a week later), and multi-step workflows where "the outcome" isn't a single clean event.

All three models share a downstream problem: refunds and credits. A per-token model has to handle a request that failed mid-generation — did the customer consume the tokens or not? A per-agent model has to handle a month where the agent was down for a day — does the flat rate get prorated? A per-outcome model has to handle an outcome that gets disputed or reversed after the invoice already went out. None of these are edge cases in practice; they're a predictable fraction of every billing period, and a pricing model that doesn't have a first-class answer for reversal and credit handling will end up handling it manually, in a support queue, indefinitely.

Why hybrid models are winning

Almost no company that started with a pure version of one model stays there. The two hybrid patterns that show up repeatedly are a base subscription plus metered overage, and a committed volume plus overage above the commitment — and both exist to solve the same underlying tension: pure usage-based pricing is unpredictable for the customer's finance team, and a pure flat rate is unpredictable for the vendor's margin.

A seat-plus-usage hybrid gives a customer a predictable floor — a base fee that covers a bundle of usage — with metered charges only once they exceed it. This is the shape Salesforce's Agentforce pricing has moved toward over its public evolution: rather than a single metering unit, it now offers multiple consumption models side by side (a per-conversation rate, a prepaid credit pool, and per-user licensing), letting a customer pick the shape that fits how they'll actually use it — a signal, on its own, that no single metering unit cleanly fits every AI product's usage pattern.

A commit-plus-overage hybrid runs the same logic from the vendor's side: a customer commits to a minimum spend in exchange for a lower effective rate, and anything above the commitment bills at a standard (often higher) overage rate. This is standard practice in usage-based infrastructure pricing generally, not unique to AI products, but it maps particularly well onto agent and token consumption, where usage genuinely does grow with a customer's own business rather than staying flat like a seat count would.

The pattern underneath both hybrids is the same: predictability for the part of usage that's forecastable, and metering for the part that isn't. Pure per-token, pure per-agent, and pure per-outcome pricing each optimize for one side of that tradeoff and ignore the other — which is exactly why real pricing keeps drifting toward something that blends them.

What pricing infrastructure actually needs to support this

None of the three models — or their hybrids — are hard to describe. They're hard to run, because running them well means solving the same handful of infrastructure problems regardless of which model a company picks.

Metering has to be exact, not approximate, and it has to survive real-world failure conditions. A duplicate event from a retried request, an event that arrives hours late because a batch job was slow, a clock that's skewed by a few seconds between services — any of these can silently double-bill or under-bill a customer if the underlying ledger isn't built to be idempotent and tolerant of out-of-order delivery. Kribana's metering is built on an append-only, idempotent ledger for exactly this reason: aggregation is a query over immutable events, not a mutable counter, so a duplicate delivery is a no-op and a late event lands in its correct billing period retroactively instead of corrupting whatever period it happened to arrive in.

Pricing logic has to be something Finance and RevOps can change without an engineering ticket. Whether a company is pricing per-token, per-agent, per-outcome, or some hybrid of the three, the actual rates, tiers, and commitment structures are business decisions that change as the market and the product mature — and a pricing model hard-coded into application logic turns every rate change into a deploy. A pricing engine that treats tiers, commitments, and overage rates as configuration rather than code is what makes it possible to actually run the hybrid models described above without redeploying the product every time a plan changes.

Prepaid and credit-based billing needs a real wallet primitive, not a workaround bolted onto invoicing. Per-outcome and per-agent pricing both tend toward prepaid credit models — buy a bundle of outcomes, buy a bundle of agent-actions — and that only works cleanly if credits, top-ups, and low-balance alerts are first-class objects rather than something simulated on top of a generic ledger. Kribana's wallets exist as a dedicated primitive for exactly this pattern, distinguishing paid credits from promotional grants so they can behave differently at expiry and refund time while still presenting as a single balance to the customer.

Every model eventually needs entitlement checks that run before the work happens, not just billing after it. An agent that's about to burn a customer's remaining balance, or a token-metered feature a customer's plan doesn't include, needs a real-time answer to "can this run" — not a reconciliation days later that discovers it shouldn't have. Entitlements checked at request time, not batch-reconciled after the fact, are what keep a usage-based or outcome-based product from either blocking work it shouldn't or running work it can't bill for.

And when a charge fails, the response needs to be reason-aware, not a blind retry schedule. This applies to every pricing model equally — a failed charge on a per-token overage bill, a failed charge on a per-agent subscription renewal, a failed charge on a per-outcome invoice all fail for the same handful of underlying reasons (an expired card, insufficient funds, a bank block), and treating all three identically with a fixed retry schedule recovers less of that revenue than diagnosing the actual decline reason and responding to it specifically. That's the whole premise behind Kribana's agent: it watches every account continuously and runs the recovery playbook that actually fits the failure, instead of repeating the same retry regardless of cause.

Which model actually fits your product

None of the three models is universally correct, and the honest answer to "which one should we use" depends on a handful of questions specific to what's actually being sold.

How variable is the cost of doing the work? If every unit of work costs roughly the same to deliver — a fixed number of model calls per conversation, a predictable retrieval pattern — per-outcome pricing is viable, because the vendor can absorb that variance without it compounding into a margin problem. If the cost of doing the work swings wildly depending on how hard the problem is (a support ticket that resolves in one reply versus one that needs deep troubleshooting across five systems), per-outcome pricing means eating that swing on every single request, and it only works at scale if the easy cases subsidize the hard ones reliably enough to average out.

Can the customer verify what they're being charged for? Per-token pricing is the easiest of the three to audit — a customer can, in principle, count their own tokens and check the math. Per-outcome pricing requires trusting the vendor's definition of "outcome," which is exactly why a vendor publishing that definition in plain language, the way Fin does, matters more for per-outcome pricing than it does for the other two models. Per-agent pricing is the hardest to audit from the outside, because a flat rate doesn't expose the underlying unit economics at all — the customer is trusting that the price reflects the value, not verifying it against a meter.

Does usage grow with the customer's own business, or stay flat? A support-ticket volume that scales with a company's own customer base is a natural fit for usage-based pricing, because the vendor's revenue grows in step with the value being delivered. A single deployed agent doing a fixed job — monitoring one pipeline, running one nightly reconciliation — doesn't really change in scope even as the company around it grows, which is a much better fit for a flat per-agent rate than for metered billing that will just sit flat regardless of the metric chosen.

What's the buyer's actual risk tolerance? A finance team evaluating a new AI vendor for a large contract usually wants a number they can put in a budget line before the year starts, which is what pushes vendors toward the hybrid seat-plus-usage or commit-plus-overage shapes described above rather than a pure usage model with no floor or ceiling. A self-serve buyer testing a product with a credit card, on the other hand, often prefers paying only for what they use in the first month, with no minimum commitment — the same product frequently ends up needing both options represented under one pricing engine, not a single metering unit imposed on every buyer regardless of how they actually want to transact.

None of these questions has a single right answer across all AI products — they're closer to a checklist for justifying whichever model a team lands on, and for catching the case where a company picked per-outcome pricing because it sounded appealing in a sales deck without checking whether the cost of delivering the outcome is actually predictable enough to price that way.

The pattern underneath the pricing model

Per-token, per-agent, and per-outcome aren't really three different problems — they're three different answers to the same question of what unit of value a customer will actually pay for without feeling nickel-and-dimed or over-committed. The model a company lands on says more about their buyer's risk tolerance and their own margin structure than it does about the underlying technology, which is why hybrids keep winning: real customers want the predictability of a floor and the fairness of metering for what happens above it.

What doesn't change across any of these models is the infrastructure underneath them. Whatever unit ends up on the invoice, it has to be metered exactly, priced in a way the business can actually change, wrapped in prepaid primitives when the pricing calls for them, checked against entitlements before the work happens rather than after, and recovered intelligently when a charge fails. Teams evaluating how to price an AI product are usually comparing per-token against per-agent against per-outcome. The more durable question is whether the billing infrastructure underneath any of those choices can actually support it — and most of the pricing models that fail in practice don't fail because the pricing logic was wrong. They fail because nobody built the metering, the wallet, the entitlement check, or the recovery layer that the pricing model quietly assumed would exist.

If you're weighing which of these models — or which hybrid — fits your own product, Kribana's platform is built to support all three without re-platforming when the pricing changes, and the pricing page has more on how that works in practice. For teams specifically migrating off a per-token-only setup, it's also worth comparing how Orb, Lago, Chargebee, and Stripe Billing each handle the transition to a hybrid model — the glossary has definitions for the underlying primitives (commits, proration, top-ups) if any of the terminology here needs unpacking.