An AI agent pricing model is the rule that converts what an agent does into what a buyer owes: per person using it, per unit of computation consumed, per action taken, per agent running, or per result delivered. The choice is not a billing detail. It decides who absorbs the variance when a month goes badly, and it determines which behaviours the vendor is quietly incentivised to encourage.
Published prices in this category move faster than almost anything else in software. This page is re-checked every quarter and describes models rather than numbers; the “last reviewed” date at the top is the one to trust, and any figure you need should come from the vendor’s own pricing page on the day you need it.
The five models
Per human seat. The oldest model, priced per person with access. It is predictable, easy to forecast, and structurally awkward for agents, because the entire premise of an agent product is that work happens without a person present. A per-seat agent product bills you for observers.
Per unit of usage. Tokens, minutes, runs, gigabytes. This is how the model providers themselves price — OpenAI and Anthropic both publish per-token rates — and it passes cost through with near-perfect fidelity. The failure mode is that nobody can forecast it, and a buyer who cannot forecast a line item will cap it, usually by using the product less.
Per action. A price per ticket triaged, per document processed, per message sent. More legible than tokens, because a business person can count actions without a calculator. It creates an obvious incentive problem in the other direction: the vendor’s revenue rises with the number of actions, including the redundant ones.
Per agent. A recurring price for each agent that exists, in the way a company pays for each worker it employs. It maps cleanly onto how buyers already think about headcount and capacity, and its weakness is that agents are cheap to create, so the model only stays honest if the count reflects something real rather than every scaffold anybody ever tried.
Per outcome. A price per result the buyer would otherwise have paid a person to produce. Customer support is where this has gone furthest: Intercom’s Fin and Zendesk both price around automated resolutions rather than seats, and Salesforce’s Agentforce has moved through several variants of consumption-and-conversation pricing. It is the most aligned model on paper and the most contested in practice, because “resolved” is a definition, and definitions get argued about at renewal.
What the model is really allocating
Underneath the taxonomy there is one question: who carries the variance.
An agent’s cost per run is genuinely variable. Two runs of the same duty against different inputs can differ by an order of magnitude in tokens consumed, and a retry loop that goes wrong can differ by two. Somebody absorbs that. A pure per-seat vendor absorbs it and prices in a margin for the worst case, which means the disciplined buyer subsidises the careless one. A pure usage vendor pushes it entirely onto the buyer, who now has an unbounded liability attached to a system that runs unattended. Hybrid pricing — a floor plus a metered component — is the market’s compromise, and it is popular for the ordinary reason that both sides find it survivable.
The second allocation is failure. When an agent attempts something and gets it wrong, somebody has paid for that attempt: in tokens certainly, in an action count possibly, in an outcome fee only if the contract says so. Ask this early. A vendor whose answer is vague is a vendor whose answer is “you do”.
Questions to ask before signing
What happens in a bad month? Not the median month — the one where an integration breaks and a loop runs for three days. Is there a ceiling, and does the ceiling refuse or merely warn? A budget that sends an email while spending continues is a notification, not a control.
Who pays for retries and failures? Get the answer in writing, per model. Under outcome pricing, establish who decides whether an outcome occurred, and what the appeal is when the two sides disagree.
Is inference being resold, and at what markup? If a vendor buys tokens and sells them inside a bundle, the markup is real even when it is invisible. Bringing your own engine accounts removes it entirely, at the cost of managing those accounts yourself.
What is the unit’s definition, exactly? “Per agent” means little until you know whether a paused agent bills, whether a candidate that was never activated bills, and what happens on the day you offboard one mid-cycle. Proration policy is not a footnote — Stripe’s own documentation on prorations exists because mid-cycle quantity changes are where billing disputes are born.
What does the price do when the product is failing? A platform that keeps charging full freight while a runner is offline is charging for availability it is not providing. A platform that goes read-only but keeps your data legible is behaving reasonably. Find out which one you are buying.
Budgets belong in the product, not the invoice
A pricing model tells you what things cost. It does not stop them from costing that.
The control that actually bounds spend lives in the system: a ceiling declared where a reviewer can see it, enforced at the moment of action, that refuses rather than warns. In Klingbar those ceilings are declared in an org chart written as code — per unit and per role — and the one class of command that spends real money carries a maximum as an approved parameter, so the person saying yes is approving “at most this much” rather than “go ahead”. The general shape is covered in human approval workflows.
This is worth insisting on regardless of which vendor you choose, because the alternative is discovering your pricing model’s failure mode from an invoice. A ceiling that fires is a cheap incident. A ceiling that does not exist is an expensive one.
How Klingbar prices, and why
Klingbar bills seats through Stripe: one organization seat, plus one bot seat for each bot in a probationary, active, or suspended state. Candidates and offboarded bots are not billed. Quantities follow the signed state the runner reports rather than anything a browser claims, and they reconcile with proration when the count changes.
Two properties follow from that choice. First, reading costs nothing — the whole management surface, including pairing, snapshots, and the trail, stays available in every billing state, and only count-increasing actions are gated when payment needs attention. Second, Klingbar never resells inference. The bots run on your machine using your own engine accounts, so the model provider bills you directly at the rate you negotiated, and this product’s price does not move when a token price does. That is the same architectural decision described in self-hosted agents, showing up on the invoice.
The honest limitation of a seat model is the one stated above: seats are a proxy for value, not a measure of it. A bot that produces nothing costs the same as one that carries a unit. The counterweight is that the count is derived from state a machine signed rather than from a number typed into a form, so at least the proxy is accurate.
Modelling your own costs
Take one duty. Run it twenty times against real inputs and record the spread, not the average. Multiply the ninetieth percentile by the schedule to get a monthly ceiling per bot, then add the platform’s own fee. Compare that number to the fully-loaded cost of the human hours it displaces — and if the comparison only works at the average rather than at the ninetieth percentile, the case is thinner than it looks.
Then set the ceiling slightly above your model and watch what hits it. A budget that never fires taught you nothing. A budget that fires occasionally is a working instrument, and the pattern of what trips it is the most useful pricing data you will get, because it is about your own workload rather than about a vendor’s rate card.
Prices in this market will have changed by the time you read this; the models above change much more slowly, which is why this page describes them and re-checks the rest each quarter.