---
Title: "Outcome-based vs consumption AI agent pricing"
Url: "https://devrev.ai/blog/outcome-based-vs-consumption-ai-agent-pricing"
Published: "2026-10-14"
Last Updated: "2026-10-14"
Author: "DevRev Editorial"
Category: "Growth & Revenue"
Excerpt: "Compare what suppliers charge for, what your team accepts, and which obligations sit behind the quoted rate. Includes a hypothetical workload model and negotiation worksheet."
Reading Time: 9
---

# Outcome-based vs consumption AI agent pricing

Compare charging units on one workload, then use a negotiation worksheet to check what each quote includes.

One quote charges per resolved conversation. Another charges for usage. You can compare the numbers, but you still don’t know which offer fits your workload.

Outcome-based pricing charges for a defined result. Consumption-based pricing charges for metered usage, such as tokens or messages.

The difficulty with outcome-based vs consumption AI agent pricing is defining what the billable unit buys. A supplier’s resolution may not meet your completion test. And a usage rate may cover only the model, not the service around it.

Start with the charging unit, its exclusions, and its obligations. The [broader buying criteria](https://devrev.ai/blog/enterprise-ai-agent-buying-criteria) matter too, but this comparison begins with what triggers the bill.

## TLDR

- **Outcome charges:** Fin lists $0.99 per resolution for covered chat/email use; other outcome types can also count.
- **Consumption charges:** tokens, messages, or credits measure usage, not successful work.
- **Comparable scope:** raw OpenAI inference charges aren’t a complete support-agent price.
- **Commitments:** minimums, overages, reversals, and cap behavior change the invoice.
- **Buyer evidence:** reconcile billed events with the work your team actually accepts before negotiating the rate.

## What does outcome-based vs consumption AI agent pricing bill?

Outcome pricing bills a defined event; consumption pricing bills measured usage. Neither label tells you the full invoice or guarantees accepted work.

### Outcome charges depend on the supplier’s definition

Intercom’s Fin documentation, checked October 14, 2026, lists $0.99 per resolution for chat and email when used with Intercom.

A **confirmed resolution** means the customer indicates satisfaction. An **assumed resolution** means they leave after an actual answer without requesting further assistance. A greeting or unanswered clarifying question doesn’t qualify.

Fin charges at most once per conversation. If the customer returns to that conversation seeking further assistance, Fin deducts the resolution, even across billing periods.

But “outcome” is broader than “resolution.” A configured Procedure handoff, which routes work to a human or workflow, can be billable. Ordinary escalations aren’t.

Zendesk’s documentation calls its units **automated resolutions** and describes tiers introduced May 18, 2026. Under those tiers, assisted escalations and contained resolutions don’t consume the allowance; verified resolutions pass a language-model check of the conversation.

Ask which Zendesk pricing model applies to your account. Its transition guidance makes account applicability important and labels example invoice prices as placeholders.

### Consumption charges depend on the meter

A **token** is a small piece of text a model processes. Input tokens cover what you send; output tokens cover what the model generates.

OpenAI’s developer pricing separates those rates. Other meters can include messages or credits, vendor-defined units that can represent different actions.

Usage-based pricing can still include prepaid capacity and minimum commitments. Ask whether the quote is pay-as-you-go, committed, or a mixture of both. Bain’s 2026 pricing analysis distinguishes those arrangements from consumption alone.

## How do you map billing units to accepted work?

Map each supplier’s meter to the same buyer-defined service requirement. Keep billed events and accepted work separate until case evidence connects them.

For an order-status request, your acceptance test might require an accurate answer from an authorized order record and evidence that it reached the customer. A closed conversation alone doesn’t establish that result.

| Vendor billing unit | What triggers a charge | Exclusions or reversals | Caps | Commitment/PAYG treatment | Mapping to accepted work |
| --- | --- | --- | --- | --- | --- |
| Intercom Fin resolution | Confirmed or assumed resolution after an actual answer | Ordinary escalations excluded; same-conversation requests for further assistance reverse the resolution | At most one outcome charge per conversation | Confirm minimums, included usage, and account-specific terms | Match the conversation to your acceptance test; separate other billable outcome types |
| Zendesk resolution tier | Applicable tier and account pricing model; verified resolution passes a language-model check | Assisted escalations and contained resolutions don’t consume the allowance under current tier documentation | Confirm applicable rules; don’t assume Fin’s conversation cap | Confirm allowance, transition status, commitments, and overage terms | Match the verified-resolution record to your own service requirement |
| OpenAI input/output tokens | Billable model usage under the selected model and tier | No resolution-dependent exclusion established by this rate card | Token meter, not a per-conversation outcome cap | Standard rates modeled below; no purchase commitment assumed | Join usage records to case results; tokens alone don’t prove acceptance |

Your common denominator is the work you accept, not the supplier’s label for a charged event.

Bain’s analysis tests whether outcomes are observable, attributable, and possible to define contractually. Apply that test to your invoice evidence.

Require a trace from the charge to the case, then from the case to your acceptance criteria.

## Outcome-based vs consumption AI agent pricing on one workload

Run the same assumed workload through each meter, but preserve differences in service scope. The result below compares billing mechanics, not equivalent vendor offers.

**Hypothetical illustration:** one client, 1,000 conversations per month. These quantities are assumptions, not customer results or vendor performance claims.

### Define the workload before applying rates

| Workload input | Assumed value |
| --- | --- |
| Monthly conversations | 1,000 |
| Final billable resolutions | 650, or 65% |
| Ordinary escalations | 150, or 15% |
| Other unresolved conversations | 200, or 20% |
| Buyer-accepted results within supplier-labeled resolutions (Fin and Zendesk examples) | 600 of 650, assumed |
| Supplier-labeled resolutions without buyer acceptance (Fin and Zendesk examples) | 50 of 650, assumed |
| Results accepted in the model-backed application example | 600, assumed separately; not measured by tokens |
| Model calls, including repeated attempts | Average two per conversation; 2,000 total |
| Average billable input per model call | 3,000 tokens |
| Average billable output per model call | 500 tokens |
| Additional billable handoffs or sales outcomes | None |
| Outstanding resolution reversals | None in the baseline |

Hypothetical reconciliation: of the 650 supplier-labeled resolutions, assume 600 meet the buyer’s acceptance test and 50 lack the required evidence. The 150 ordinary escalations and 200 other unresolved conversations are neither billable resolutions nor accepted AI-agent-completed results.

These groups are assumptions, not measured vendor error rates. For a real quote, match each charge to its case and acceptance evidence.

Assume a separate model-backed application also delivers 600 buyer-accepted results across those 1,000 conversations. The OpenAI token charge covers inference within that hypothetical implementation, not the application that produced the result or equivalent service quality.

For Zendesk, assume 650 conversations qualify as verified resolutions under the applicable account model. Of those, 600 also pass the buyer’s separate test.

### Calculate the monthly meter charges

Fin’s published resolution rate is $0.99. OpenAI’s Standard, short-context `gpt-6.1-sol` rates are $2.00 per million input tokens and $10.00 per million output tokens.

These are official documentation rates checked October 14, 2026. Zendesk’s applicable tier rates remain quote-required.

| Charging approach | Arithmetic using the assumptions | Illustrative monthly meter charge | Scope of this figure |
| --- | --- | --- | --- |
| Fin resolution charges | 650 × $0.99 | $643.50 | Resolution charges only; no minimum, discount, included allowance, or base fee modeled |
| Zendesk applicable resolution tier | 650 × quoted applicable tier rate; then apply the account’s allowance and purchase terms | Quote required | No generic dollar total; account-specific commitments and overages require confirmation |
| OpenAI input tokens | 2,000 × 3,000 = 6,000,000 tokens; 6 × $2.00 | $12.00 | Raw inference input only |
| OpenAI output tokens | 2,000 × 500 = 1,000,000 tokens; 1 × $10.00 | $10.00 | Raw inference output only |
| OpenAI combined token subtotal | $12.00 + $10.00 | $22.00 | Input/output inference only, not a support-agent service price |

The $643.50 and $22.00 figures price different layers of service, so neither identifies a cheaper vendor.

The OpenAI subtotal excludes tool calls, storage, application development, integrations, monitoring, and human support. It assumes no caching, cache writes, or rate modifiers.

You still need the [costs beyond the quoted charging unit](https://devrev.ai/blog/ai-agent-total-cost-of-ownership) before comparing complete offers. Keep the 600 accepted results visible beside the billing counts, rather than treating 650 billed resolutions as an acceptance guarantee.

### Test the variables that could change your invoice

These are assumption sensitivities, not predictions:

- **Repeated attempts:** 500 extra model calls at the same token quantities add $3.00 input and $2.50 output. The token subtotal becomes $27.50.
- **Reopens:** if 25 of the 50 billed-but-not-accepted Fin resolutions later qualify for its same-conversation reversal, the adjusted resolution charge falls by $24.75, to $618.75. The assumed 600 buyer-accepted results remain unchanged. A deduction across billing periods may appear on a later invoice.
- **Escalations:** moving otherwise billable Fin resolutions to ordinary, nonbillable escalations can lower its resolution charge; a configured Procedure handoff may still generate a billable outcome. Zendesk treatment depends on the applicable tier and account. Token usage already incurred remains billable under the modeled rate.
- **Commitments and failures:** purchased minimums can remain payable despite lower usage. Confirm whether burst traffic, replayed requests, or technical failures receive credits.

Negotiate the rules that change the count, not just a discount on the rate.

## The negotiation worksheet

Ask suppliers to complete this worksheet against your proposed workload. Use their answers to reconcile a sample bill before committing to a larger purchase.

In the [Tokenomics Foundation’s 2026 survey](https://www.tokeneconomics.com/state-of-tokenomics/) of 472 respondents across 11 industries, 23% asked model and token providers for more transparency and granular billing data. Only 4% asked for cheaper prices. These are respondent preferences about billing clarity, not evidence that one pricing model costs less.

| Term to clarify | Buyer question | Evidence to request |
| --- | --- | --- |
| Resolution definition | Does customer confirmation matter, or can inactivity qualify? | Written definition and examples of billable and nonbillable cases |
| Escalation treatment | Which handoffs are excluded, and which configured handoffs generate charges? | Outcome taxonomy and sample handoff records |
| Reopens and attempts | When does a reopened case reverse a charge? Can a new conversation count again? | Reversal rules, conversation boundaries, and repeated-attempt records |
| Conversation cap | Is there a one-outcome-per-conversation rule? How does it handle multiple tasks? | Applicable billing rule and sample invoice treatment |
| Minimums and overages | What remains payable below commitment? Which rates apply above it? | Order form, included allowance, overage schedule, and renewal terms |
| Burst, replay, and failure | Do retries, duplicated requests, or failed actions consume billable units? | Meter rules and any available credit policy |
| Measurement and disputes | Can you trace each charge and challenge its classification? | Timestamped event export, reconciliation process, and dispute window |
| Included fees and term | Which platform, seat, storage, and service fees sit outside the quoted unit? | Itemized commercial schedule and minimum purchase term |
| Accepted work | What evidence proves your service requirement was met? | Buyer acceptance criteria and case-level evidence |

Thomas Lah’s 2026 TSIA analysis emphasizes that outcome pricing needs clearly defined, reliably measured results.

Operational controls must match the commercial answers. Decide how you’ll [attribute usage and cap retries](https://devrev.ai/blog/ai-agent-cost-management), rather than assuming a billing label controls spending.

For example, Fin’s usage guidance says hard stopping limits can be approximate. A lower limit doesn’t remove a contracted minimum. Those spending controls are separate from its one-outcome-per-conversation billing rule.

The FinOps Foundation’s 2026 guidance recommends involving procurement and legal early in provider contracts and volume commitments. Treat this worksheet as evaluation support, not legal advice.

## Where Computer fits

When procurement and support use different definitions of completed work, approving a commercial commitment becomes harder. You need a shared acceptance test before evaluating another offer.

Bring that test into an evaluation of Computer, by DevRev. Ask DevRev to demonstrate the evidence relevant to your workflow, rather than accepting a pricing label as proof.

For the order-status request above, define the permitted lookup, the evidence that the correct status reached the customer, and who would accept the result.

A useful evaluation distinguishes attempted work, completed work, and accepted work. It also identifies the boundaries on actions and the cases that need human follow-up.

This article doesn’t quote DevRev pricing or promise a billing model. Confirm capabilities and commercial terms with DevRev for your proposed scope.

Before accepting a quote, check that the answers below match the supplier’s applicable documentation and your order form.

You don’t need every supplier to use the same meter. You need each quote to explain what you’ll buy, what you’ll owe, and how you’ll verify it.

Once those answers align, you can [fund the work you can verify](https://devrev.ai/blog/cfo-guide-ai-agents). Until then, a lower unit price may simply describe a smaller part of the job.

_Market-pricing analysis: sources rechecked October 14, 2026. The workload example is hypothetical, not a quote or customer result._

[Discuss your AI-agent pricing evaluation with Computer](https://devrev.ai/request-a-demo).

## FAQ

### Is per-resolution always cheaper than per-usage?

No. Per-resolution and per-usage charges count different events, and their rates can cover different service layers. A resolution charge may cover a hosted service, while a token rate may cover model inference alone. Minimum commitments, included usage, retries, and exclusions also affect the invoice. Apply the same workload and acceptance criteria, then compare offers with equivalent service scope. Don’t infer a winner from different meter subtotals.

### What counts as a resolution?

A resolution is the event defined by the supplier’s applicable billing rules. It isn’t automatically the same as a buyer-accepted result. Intercom Fin distinguishes confirmed and assumed resolutions after an actual answer. Zendesk’s current tier documentation distinguishes assisted escalation, containment, and verified resolution. Check escalation treatment separately. Fin’s configured Procedure handoffs can be billable outcomes, unlike ordinary escalations. Ask how reopened cases and conversation boundaries affect charges.

### What should I pin down in the contract?

Pin down the charging unit, charge trigger, exclusions, conversation rules, reversal treatment, minimum commitment, and overage rate. Also confirm cap behavior, included fees, renewal terms, meter exports, and the process for disputing a charge. Define the evidence your team needs to accept the work. Have your procurement and legal teams review the applicable terms. A rate card alone doesn’t settle those obligations.