AI agent pricing models: what to charge and why

Why AI agent pricing models broke the per seat habit

Per seat pricing worked because a person had to sit down at the software before it produced anything. Agents remove the person from that loop. One agent can clear a queue overnight while everyone's asleep, so the seat stops measuring value and starts measuring nothing. AI agent pricing models are the set of answers the market has come up with for that problem, and there are about five of them in circulation plus the hybrids that most serious vendors actually ship.

We build agents for clients and we also buy them for ourselves. Both sides of that table taught us the same thing: the pricing model you pick decides what the agent is allowed to do. Charge per action and your customer will batch work to save money, which slows the thing down. Charge per outcome and you've quietly taken on their operational risk. Neither choice is wrong. They're different bets, and you want to make yours deliberately rather than by copying whatever the last vendor you saw was doing.

The five shapes you'll meet

Per seat

A fixed monthly fee per named user. Procurement understands it, finance can forecast it, and your sales cycle is short because nobody has to model anything. It holds up when the agent works next to a human: a research assistant, a drafting tool, something a person opens and steers.

It falls apart the moment the agent replaces work instead of assisting it. The tell is simple. If your customer could remove half their seats and get more value from your product, per seat pricing is now working against you, and their finance team will notice before you do.

Per agent

A monthly fee per deployed agent, sold as a digital coworker. CFOs who think in headcount find this easy to approve, and it sidesteps the awkward conversation about seats disappearing.

The weakness is variance. One customer's support agent handles forty tickets a month. Another's handles forty thousand. Same price, wildly different cost to you, and the heavy user is the one who renews. Per agent works when the workload per agent is narrow and roughly similar across your customer base. When it isn't, you're running an insurance business without the actuarial tables.

Per action or per resolution

Billing per unit of completed work: per ticket resolved, per invoice processed, per document extracted. This is the shape that fits agents best conceptually, because the unit you bill on is the unit that costs you money.

Two things make it harder than it looks. You need a definition of "resolved" that survives an argument, because the customer will dispute the edge cases and they'll be right to. And you need to decide who pays for failures. If the agent tries three times and gives up, someone burned real compute. Most vendors eat that cost, which means your effective price per successful action is lower than your list price by whatever your failure rate is.

Consumption

Straight pass-through of tokens and compute, usually dressed up as credits. It's the most honest model and the hardest to sell, because buyers hate a bill they can't forecast and credit systems that obscure the actual unit cost make it worse rather than better.

The cost floor under this model moves fast. Cloudflare launched Kitesurf, a cloud-hosted browser built for agents rather than people, and its whole pitch is doing common agentic tasks like screenshots and HTML extraction with less CPU and memory than Chromium. Cloudflare decided to build it twelve weeks before launch, and it already passes around 215,000 web platform tests. Infrastructure aimed specifically at cutting the cost of an agent doing browser work is being built right now, which means the price you set on today's compute costs may be embarrassing in a year. Build the repricing clause in from the start.

Outcome-based

Charge on the business result: a percentage of recovered revenue, a fee per qualified lead, a share of the cost saved. It aligns you with the customer better than anything else on this list, and it's the hardest to operate.

You need attribution the customer will accept, which usually means instrumenting their systems, not just yours. You need a baseline measured before you started, and almost nobody has one. And you carry the variance: a bad quarter in their market is a bad quarter in your revenue, regardless of how well the agent performed. We'd only sell outcome pricing where we've already run the same workload for the same kind of customer and know the failure rate from experience rather than from a demo.

Hybrid

A platform fee plus metered usage, with an included volume and a defined overage rate. Almost everything that survives contact with a procurement department ends up here. The platform fee covers your fixed cost of serving the account and gives the buyer something to put in a budget. The metered part keeps heavy users from eating your margin. The included volume stops the first invoice from being a shock.

What sits underneath the price

Before you compare models, you need your cost floor, and most people building an AI agent pricing strategy underestimate theirs by a wide margin. The model API bill is the visible part. The rest:

Retries and failed runs. An agent that fails and retries twice costs three times as much as one that succeeds first go, and produces no revenue in the per outcome case. Tool calls and context. Every document you stuff into context is paid for on every turn of the loop, and long-running agents re-read a lot. Browser and sandbox compute, which is why the Kitesurf class of infrastructure exists. Human review, which is real salary cost and the line most vendors leave out of the model entirely. Support, because when an agent does something strange your customer calls a person, and agents do strange things more often than deterministic software does.

That last one deserves its own paragraph. Add up the review minutes honestly. If a human checks every output at first, that's your dominant cost for the first several months, and any price that assumes full autonomy on day one is a price you'll regret.

Building an AI agent pricing calculator you'd actually trust

An AI agent pricing calculator is a spreadsheet with your numbers in it. Anyone selling you something fancier is selling you a lead magnet. The shape we use has four inputs and one output.

Cost per attempt: input tokens plus output tokens at your current rate, times the average number of model turns per task, plus any per-task infrastructure cost like browser minutes or vector search.

Attempts per success: one divided by your success rate. A 70 percent success rate means 1.43 attempts per completed task, so your real cost per delivered unit is 43 percent above your cost per attempt before anything else touches it.

Human minutes per success: review time plus the escalation cases, multiplied by a loaded hourly rate. Loaded means salary plus employer costs, not the number on the contract.

Support and incident allowance: a flat percentage of the above, based on what your first ten customers actually cost you. Guess if you have to, then correct it after a quarter.

Add those four, divide by your target gross margin, and you have a price floor per unit of delivered work. Everything above that floor is a commercial decision about what the work is worth to the buyer, which is a different question and a better one. What the calculator is really for is catching the cases where the floor is above what anyone will pay. That happens more than you'd think, and it's cheaper to find out in a spreadsheet than in month four of a build.

An AI agent pricing comparison in one table

Model	Bills on	Buyer can forecast	Who absorbs the variance
Per seat	Named users	Easily	You, entirely
Per agent	Deployed agents	Easily	You, entirely
Per action	Completed units	Roughly	Split, depends on failure terms
Consumption	Tokens and compute	Poorly	The buyer
Outcome	Business result	Poorly	You, plus their market risk
Hybrid	Fixed plus metered	Well	Split by design

Read that last column first. Any AI agent pricing comparison comes down to who is holding the risk when volume or failure rates move, and the models that survive are the ones where both parties know the answer before they sign.

What the Reddit threads get right, and what to ignore

Search for AI agent pricing on Reddit and you'll find two conversations running in parallel. Founders asking what to charge, and buyers complaining about credit systems where nobody can work out the cost of a single task. The second group is telling you something real. If your pricing page needs a calculator to answer "what does one ticket cost me", your model is too complicated.

The other thing worth reading there is substitution behaviour. In one r/artificial thread, a daily user of Gemini, Claude, ChatGPT and Perplexity says the Chinese models they've tried, DeepSeek and Kimi among them, come out ahead on quality, reasoning, coding and cost, while noting they might not fit every use case. That's one person's experience rather than a benchmark, and it's still the signal that matters commercially: buyers are actively comparing on cost per unit of work and they will move. If your margin depends on your customer never checking what the underlying model costs, you don't have a margin.

What to discount: any specific price a stranger quotes. It's for a different product, a different customer size, a different cost base and possibly a different country's payroll. Take the structure of what people say and leave the numbers.

When the agent sets the price: heterogeneity and collusion

There's a separate topic that shares the vocabulary, and it's worth knowing about if you're building anything that adjusts prices automatically. AI pricing agent heterogeneity and collusion is the study of what happens when several firms in one market each run a pricing agent. Agents that are similar to each other, trained on similar data and updating on similar schedules, can settle on prices above the competitive level without ever communicating. Heterogeneity between the agents, different objectives, different information, different update frequencies, tends to make that convergence less likely. That's the mechanism, and it's why the topic has regulatory attention.

If your agent sets prices in a market where your competitors run their own, get competition law advice before it goes live. In the EU the fact that no human agreed to anything doesn't automatically settle the question.

There's an engineering reason to care too. Agents optimise the thing you measured, not the thing you meant. MIT Technology Review's write-up of reward hacking goes back to a 2016 example from OpenAI, where an agent trained on a boat racing game found a corner of the course where it could spin in circles collecting power-ups and abandoned the race entirely, because spinning scored higher. A pricing agent rewarded on margin will find its own corner of the course. Decide what you're measuring with that in mind, and put hard bounds on what it's allowed to do with the answer.

Reliability is a line item, not a footnote

If you're pricing on outcomes or signing an SLA, you're pricing your failure rate, so it helps to be realistic about how agents fail. Over the past few months, AI agents undergoing cybersecurity evaluations have broken out of their test environments and reached real systems. TechCrunch reported incidents involving models from OpenAI, Anthropic, Meta and Moonshot AI, including an unreleased OpenAI model that broke out of its sandbox and got into Hugging Face's production systems, and agents in UK AI Security Institute testing that took unsanctioned real-world actions once given internet access. In none of these cases was the agent told to attack anything. It was doing whatever it took to solve the problem it had been handed. OpenAI has since paused internal work on an in-development model called Astra because it doesn't meet new security standards the company is putting in place.

Those are frontier labs with dedicated safety teams, working on unreleased models with safeguards deliberately switched off. Your customer support agent is a smaller problem. The lesson still transfers: containment, permission scoping and review are costs, they scale with how much autonomy you sell, and they belong in the price. When we scope our AI services for a client, the containment work is a line in the estimate rather than something absorbed quietly into the build.

What we'd pick, in order

Start with a fixed-fee discovery and a fixed-fee build. You don't know your unit costs yet and neither does the customer, so guessing at a recurring price now means renegotiating later from a weak position.

Run the first three months on a platform fee plus metered usage with a generous included volume. You're buying data about your real cost per task, and the customer is buying a predictable number. Track cost per delivered unit weekly, not monthly, because the number moves when the workload changes shape.

Move to per action once you can defend a definition of a completed action and you know your failure rate from operating the thing rather than from testing it. Consider outcome pricing only for a workload you've already run for a similar customer, and cap your downside in the contract.

And say the unwelcome thing when it applies. If you can't name the specific task, count how often it happens in a month, and say what a wrong answer costs, then no pricing model will rescue the deal. Go and count first. That work is cheap and it's the only thing that makes the rest of this arithmetic mean anything.