AI Agent Pricing Models Compared (2026)

Ask five AI vendors to price the same agent and you will get five proposals that cannot be compared. One quotes a monthly seat price, one bills tokens, one quotes a fee per resolution, one charges a platform fee plus usage, and one offers to share the savings. They are not being evasive — they are pricing different things, and the unit that looks cheapest is usually the one carrying the most exposure. This guide covers the five models you will actually be quoted, what each one hides, how to normalize two proposals into a single cost per resolved task, and the contract clauses that decide what you pay in year two.

Why agent pricing is not software pricing

Traditional software has a unit price because the marginal cost of another user or another record is close to zero. An agent is the opposite: every task costs money to run. A single request may fan out into a retrieval call, three tool calls, a retry after a malformed response, and a second model pass to verify the answer. The same input on two different days can take a different path through the system.

Three consequences follow, and they explain most of the confusion in the market:

• Cost per task is a distribution, not a number. Median cost tells you little; the 95th percentile is where budgets break.
• Volume is not a given. An agent that resolves 40% of tickets changes your usage profile the moment you widen its scope or connect another queue.
• Human time is the biggest line item and it is rarely in the quote. Reviewing escalations, correcting wrong answers, and curating the knowledge base are costs your team pays, not the vendor.

Any proposal that does not say which of these it is charging for is not yet a proposal — it is a starting position.

The five models you will be quoted

Per-seat subscriptions

The easiest model to budget and the easiest to outgrow. You know the monthly number; what you do not know is what happens when one team triples its usage. Read the fair-use clause before you sign: in most per-seat contracts for AI products, the seat is a licence to use the product, not a commitment to absorb unlimited inference.

Seats suit broad, shallow adoption — an assistant available to a whole department where average usage is low and the value is convenience. They fit badly when the agent is doing production work for a small number of heavy users, because the seat price has to be set for the average and the average is not who is generating the cost.

Per-token consumption

The most transparent model and the hardest to forecast. You are paying the vendor's inference bill plus their margin, so the number tracks your own behaviour. That is fair, and it also means a prompt change made by a junior engineer on a Friday can move next month's bill.

Ask for three things if you accept consumption pricing: a cost dashboard you can see at the workflow level, not just the account level; a documented context and retry policy, since retries are the classic silent multiplier; and a stated routing strategy — a system that sends every request to a flagship model is passing a design decision on to your invoice.

Per-resolution or per-task

The model most enterprise buyers prefer, because the unit matches the thing they care about. A price per resolved ticket, per processed claim, per extracted invoice, per booked appointment. It converts an unpredictable inference cost into a predictable business cost, and it puts the efficiency work on the vendor.

It also moves the negotiation to a place most buyers do not examine. Resolution has to be defined in writing, with an agreed method of measurement and a dispute process. A resolution that counts a reopened ticket as closed, or that excludes human-assisted handoffs from the denominator, produces a very different unit price than one that does not.

Platform fee plus usage

Common once there is more than one workflow. A base fee covers the control plane — orchestration, evaluation, monitoring, access control — and usage is metered on top. It is a reasonable structure for a company running several agents on shared infrastructure, provided the base fee buys things you would otherwise have to build.

Two things to test before signing. First, what the base fee includes when usage is low — you should not pay for capacity you are not using. Second, how the overage tier works, because the headline unit price almost always applies to a band, and the bill at three times that band is where the model either holds or breaks.

Outcome-based or shared savings

The most attractive in a pitch and the most difficult to operate. You pay a share of the savings the agent produces, so the vendor's incentives align with yours — in theory. In practice, savings have to be attributed, measured against a baseline, and defended against every other change happening in the business at the same time.

It can work where the outcome is clean and countable: cost per claim processed, cost per invoice handled, hours of a specific team released. It works poorly where the benefit is diffuse, where the baseline is contested, or where the vendor has no control over the process the agent sits inside. If you pursue it, agree the measurement method and the baseline data before the pilot, not after.

What every quote leaves out

Whatever the model, these costs are usually missing from the number you compare:

• Retrieval and indexing. Embedding, vector storage, and re-indexing when source documents change. Small individually, growing silently.
• Tool-call spend. Agents call APIs, and some of those APIs are metered by a third party.
• Human review time. The minutes your team spends on escalations and corrections. Ask for the expected escalation rate and multiply it by your own loaded hourly cost.
• Evaluation and monitoring. Regression testing after a model or prompt change. This is not optional if the agent is doing anything that matters.
• Rework after model migrations. A provider deprecating a model version is a real, recurring event with a real cost.
• Data preparation. The agent is only as good as the retrieval corpus, and somebody has to maintain it.

Ask each vendor to fill those rows in for their proposal. The gap between two quotes often disappears — or reverses — once they do.

How to normalize two quotes

Put both on the same unit and do the arithmetic yourself. A simple example, illustrative rather than a market rate:

Vendor A proposes a flat $0.10 per resolved ticket. Vendor B proposes a $2,000 monthly platform fee plus $0.02 per resolution. Set the two equal: 0.10x = 2,000 + 0.02x, so 0.08x = 2,000, and the break-even lands at 25,000 resolutions a month. Below that volume, A is the cheaper structure; above it, B is — until B's overage tier applies, at which point its effective unit price, not its published one, sets the bill.

Now repeat the exercise with the other variables fixed. Same definition of resolution. Same escalation policy. Same model tier. Same retention requirement. Same support commitment. Only then do you have two comparable numbers, and in most evaluations the ranking changes at least once during this step.

Two practical rules. Forecast with your own volumes, not the vendor's reference customer — the customer in the case study is usually the largest deployment they have. And model the doubling case: what the bill looks like if usage doubles after the agent proves itself. That is the scenario you are actually buying into, because successful agents get expanded.

Agree the definition of the unit before you agree the price

This is the negotiation that matters more than the rate:

• What counts as a resolution? Closed, closed without reopening inside 30 days, or resolved without human touch? Each definition prices differently.
• Who measures it? Ideally both parties see the same dashboard from the same event log.
• How are handoffs treated? An agent that routes 60% of work to a human is not resolving 100% of it, and the pricing should reflect which number is being paid for.
• What is the dispute path? A monthly reconciliation meeting with a five-day correction window is normal; an annual true-up is not.

Run a measured pilot before a twelve-month commitment

The cheapest way to compare models is not a spreadsheet — it is a fixed-fee pilot on your own data, with an evaluation set agreed in advance. Sixty days is usually enough to measure four numbers that decide the whole business case: resolution rate, escalation rate, cost per resolved task, and human review minutes per task.

Ask for those four, broken out by workflow, at the end of the pilot. A vendor who cannot produce them is selling a demo, not a system. The same four numbers become your baseline for the contract, which is why they belong in writing at the start.

Contract clauses that decide your year-two cost

• Price protection on model changes. If the provider changes model versions, who absorbs the re-tuning and the token-cost difference?
• Overage caps and alerts. An uncapped overage tier is the most common surprise in consumption and hybrid contracts.
• Volume tiers on your forecast. Commit to the low end of your realistic range, not the number in the vendor's slide.
• Portability on exit. Prompts, evaluation sets, workflow configuration and the retrieval corpus should be exportable. If they are not, your switching cost is the vendor's pricing power.
• Evaluation set ownership. You should own the test data that proves the agent works.
• Data retention and training. Confirm in writing that your data is not used to train models, and how long it is retained.
• Accuracy commitments with a remedy. An SLA on availability is not an SLA on quality. Ask what happens when resolution rate falls below the agreed band.

How we price agent work

We quote builds as fixed-scope engagements after discovery, and we run a contained pilot first so the decision is based on your workflow rather than a demonstration. Production builds scale with the number of tools, integrations and approvals involved; ongoing operation is a monthly arrangement covering monitoring, evaluation and iteration. Where a client prefers consumption or per-resolution pricing for run costs, we price on the unit definitions above and report against them monthly, so the bill and the measurement come from the same event log.

Whichever model you choose, the structure of the decision does not change: define the unit, measure it on your own data, model the doubling case, and put the definition in the contract. More on scope and effort in our guide to what it costs to build an AI agent in 2026, on vendor evaluation in how to choose an AI agent development company, and on delivery in AI agent development.

Frequently asked questions

What are the main AI agent pricing models?

There are five you will commonly be quoted: a per-seat subscription, per-token consumption, a fee per resolution or task, a platform fee plus metered usage, and outcome-based pricing where the vendor takes a share of measured savings. Each prices a different unit, so two proposals using different models are not directly comparable until you convert both to a cost per resolved task.

Is per-resolution pricing cheaper than per-token?

Not inherently. Per-resolution transfers the efficiency risk to the vendor and gives you a predictable unit cost, which is usually worth a margin. Per-token gives you the lower theoretical cost and leaves you holding the variance from retries, long context and tool loops. The right choice depends on whether your team can govern prompt and context design closely.

What is outcome-based AI pricing?

Outcome-based pricing charges a share of the savings or the value the agent produces, for example a fee per verified processed claim or a percentage of measured cost reduction. It aligns incentives but requires an agreed baseline, a clean measurement method and a dispute process, all of which should be settled before the pilot begins.

What costs are usually missing from an AI agent quote?

Retrieval and re-indexing, third-party tool-call spend, human review and escalation time, evaluation and monitoring after model changes, data preparation, and the rework that follows a provider deprecating a model version. Ask each vendor to price those rows explicitly — the comparison often changes once they are included.

How should I compare two AI agent proposals?

Fix every variable except price: the same definition of resolution, the same escalation policy, the same model tier, the same support and retention terms. Then calculate the monthly cost at your own forecast volume and at double that volume, including overage tiers. A fixed-fee pilot on your own data, reporting resolution rate, escalation rate and cost per resolved task, gives you the numbers to do it properly.