Pricing AI Agents: Six Meters in Use, Three Designs Worth Testing

A follow-up to How Observability Vendors Price AI Agents. This piece widens the lens to customer service, CRM, workplace automation and coding agents, sets out the factors that matter to the vendor and to the buyer, proposes three pricing designs, and scores them against the models already on the market. Public sources only, retrieved October 5, 2026.

The September analysis found three meters in observability (credits, tokens and executions) and one consistent gap: no vendor tells a buyer what a task will cost before it runs. Outside observability the picture has more variety. Customer service vendors charge per resolved conversation, Salesforce sells both per-conversation and per-action pricing, Microsoft prices each type of agent step in credits, and the large coding-agent vendors have moved to token pass-through at API rates. Each choice moves risk between the vendor and the buyer in a different way, and that allocation of risk is the clearest way to compare them.

Key Findings

• Six meters are in use across industries. Vendor credits, tokens at API rates, executions or conversations, bundling into an existing platform meter, seats or active users, and outcomes such as a resolved conversation. Observability uses the first five. Outcome pricing appears mainly in customer service.
• Coding agents converged on token pass-through. GitHub moved every Copilot plan to token-based billing at API rates on June 1, 2026, Cursor made the same shift in June 2025, and Devin's pricing page now sells extra usage "consumed at API pricing."
• Outcome pricing is visible but rare. Intercom charges $0.99 per Fin outcome and Zendesk $1.50 to $2.00 per automated resolution, yet a sample of 80 AI agent companies published by billing vendor Orb puts outcome-based pricing at 3.8%, against 91.3% using some usage component.
• The same workload can cost 15 times more under one meter than another. At list price, 1,000 support conversations range from about $130 to $2,000 depending on whether the vendor counts generative steps, actions, conversations or resolutions (worked example below). Seat and platform fees come on top in every case.
• The missing piece is the same everywhere. Caps, budgets and usage estimators exist (Microsoft publishes an agent usage estimator, GitHub ran a preview bill before its switch), but no vendor reviewed commits to a price for a single task before it runs.

The Six Meters in Use

Observability prices sit as reported in the September 24 analysis. Other prices come from vendor pages retrieved October 5, 2026. All are list prices and many are "from" values.

What changed outside observability

Coding agents. GitHub announced on April 27, 2026 that all Copilot plans would move to usage-based billing on June 1. Each plan now includes a monthly allotment of AI Credits equal in dollars to the plan price ($10 on Pro, $39 on Pro+, $19 per user on Business, $39 on Enterprise), and usage is calculated from input, output and cached tokens at each model's API rate. GitHub's stated reason was that a quick chat question and a multi-hour autonomous session could cost the user the same amount, which it called "no longer sustainable." Cursor made a similar move in June 2025 and published an apology on July 4, 2025, offering refunds for unexpected charges between June 16 and July 4 because it had not communicated the change clearly. GitHub's rollout included a preview bill and admin budgets at enterprise, cost center and user level.

CRM and workplace automation. Salesforce runs three parallel options for Agentforce: $2 per conversation for customer-facing agents, Flex Credits at $0.10 per standard action ($0.15 for voice actions), and per-user add-ons from $125 per month with unmetered use for employee-facing scenarios. Microsoft prices each kind of agent step separately: 1 Copilot Credit for a classic answer, 2 for a generative answer, 5 for an agent action, 10 for tenant graph grounding, with token-based surcharges for reasoning models. When prepaid capacity reaches 125%, Microsoft disables custom agents until capacity is added, and admins can set monthly limits per agent.

Customer service. Intercom counts an outcome when a customer confirms the issue is resolved, when the customer does not ask for more help after Fin responds, or when Fin completes a defined workflow. Zendesk includes 5 to 10 automated resolutions per agent seat per month depending on plan and charges for additional resolutions. Sierra's December 2024 explanation of its model says escalated cases are, in most cases, not charged. In all three, seats or a platform subscription are billed separately.

Worked Example: 1,000 Support Conversations

The table applies list prices to one hypothetical month: 1,000 customer conversations, of which the agent resolves 600 without a human. Each conversation averages three agent actions, or four generative answers plus one action where the vendor meters by step type. The assumptions are illustrative, and the totals exclude seat and platform fees, which differ by vendor and plan.

The spread runs from $130 to $2,000, a factor of about 15. Two points follow. First, the unit price on its own predicts very little: the cheapest unit ($0.01 per credit) and the most expensive unit ($2 per conversation) bill different objects. Second, the outcome meters charge nothing for the 400 unresolved conversations, so the buyer's bill rises when the agent performs better, while the activity meters charge for every attempt regardless of result. A buyer whose resolution rate is low pays relatively less under outcome pricing, and one whose rate is high may pay less under action pricing. The break-even depends on the resolution rate, the number of steps per conversation and the seat fees that sit outside this table.

What Matters to the Vendor

1. Inference cost variance. Agent tasks vary widely in tokens, tool calls and retries. A flat price exposes the vendor's gross margin to the heaviest users, the problem GitHub named when it retired request-based pricing.
2. Seat cannibalization. When an agent does work that a licensed user used to do, seat revenue falls as the product succeeds. Gartner's George Brocklehurst said agentic AI "breaks the link between user growth and revenue growth," in a July 2026 release estimating up to $234 billion of application software spend at risk by 2030.
3. Revenue predictability. Commits, prepaid packs and non-rolling monthly pools (Datadog, Microsoft) stabilize revenue. Pure consumption and pure outcome models make it harder to forecast.
4. Model price deflation. When per-token model prices fall, a vendor-defined credit lets the vendor keep the difference, while token pass-through hands it to the buyer.
5. Measurement and billing cost. Counting tokens is cheap. Verifying an outcome needs a definition, telemetry and a dispute process, and the measurement method itself can become contested.
6. Sales friction and trust. A unit buyers cannot predict slows procurement. Cursor's 2025 refund episode shows the cost of a change buyers did not anticipate.
7. Runaway and abuse protection. Autonomous triggers and loops can generate large volumes of work. Hard caps protect both sides, though Microsoft's 125% enforcement shows that a cap can also switch a production agent off.

What Matters to the Buyer

1. Predictability. Finance needs a number at budget time, and engineering needs to know whether running a task is affordable before running it.
2. Value alignment. Whether the bill tracks something the business values (a resolved ticket, a merged fix, a shorter incident) or only activity.
3. Failure risk. Who pays when the agent fails, retries or is abandoned halfway. Under every activity meter in this review, the buyer does.
4. Control. Caps per user, team, agent and automation, with a documented behavior at the cap: stop, degrade or bill on demand.
5. Comparability. The ability to compare vendors and to explain the bill internally. Vendor-defined credits score lowest here, because a credit means something different at each vendor.
6. Auditability. Whether the buyer can verify the count independently. Outcome definitions measured by the vendor's own systems, such as Intercom counting silence after an answer as an outcome, need checking against the buyer's own data.
7. Double charging. In observability the AI meter sits on top of the telemetry meter, so the total cost of an investigation includes both the agent's charge and the data it reads.
8. Effect on internal adoption. Whether the pricing model lets teams use agents freely within a budget, or pushes the organization toward approval steps before each run. The next section looks at this in more detail.

Effect on Organizational Culture and Shadow AI

The way a vendor prices agent work shapes how the buyer's organization governs it. When token or credit consumption is hard to predict, a common response is internal control: approval chains for who may start an agent, pools held centrally by finance or a platform team, and rules that restrict agents to a small group of users. Each of these protects the budget, and each slows adoption.

Two effects follow. The first is pace: if running an investigation agent requires a ticket or a manager's sign-off, engineers use it for fewer incidents, which lowers both the cost and the value the organization gets from the purchase. The second is shadow AI: when the sanctioned agent is gated, some employees turn to tools outside the organization's control, such as personal subscriptions or free tiers of general-purpose assistants. That moves spend outside procurement's view and can move company data to services without a data processing agreement. Spend-tracking products have started to cover this ground. Datadog's AI Costs, for example, tracks spend on outside providers including GitHub Copilot and Cursor, as noted in the September analysis.

The models differ in how much internal control they invite:

• Tokens and credits tend to produce the most gating, because the cost of a single run is unknown in advance and a monthly pool can be exhausted by a few heavy users.
• Executions or conversations are easier to budget per run, though volume still needs watching.
• Seats and bundles remove per-run decisions for licensed users, and move the restriction to who gets a license.
• Outcomes reduce the fear of paying for failed runs, though the total still grows with use.
• Design A can replace per-run approval with a policy that auto-approves tasks below a ceiling threshold, so only expensive tasks need a decision.
• Design B removes per-run decisions inside the reservation entirely.

No public data reviewed for this analysis measures how pricing models affect internal adoption rates or shadow AI use. Buyers can measure it themselves: track agent runs per engineer, the share of incidents where an agent was used, time from request to approval, and spend on AI tools outside the sanctioned contract, before and after a pricing or policy change.

Three Pricing Designs

The three designs below are proposals, each built from mechanisms that already exist in some form on the market. None is offered in full by any vendor reviewed.

Design A: Quoted-ceiling task pricing

Before a task starts, the agent returns an estimate and a ceiling in the vendor's existing unit, for example "this investigation is likely to use 4 to 6 credits, ceiling 8." The buyer approves it, or a policy approves it automatically below a threshold set per team. The bill is actual consumption, never above the ceiling. Retries inside the same task count against the same ceiling, and consumption above it is absorbed by the vendor. Underneath, the meter stays as it is today (credits or tokens), so the design adds a pricing commitment without introducing a new unit.

Building blocks already exist: Datadog publishes average credits per action type, Microsoft publishes an agent usage estimator and per-agent monthly limits, and GitHub ran a preview bill before switching to tokens.

• Pros: predictability per task, which is the gap identified in September; the vendor carries the cost of runaway loops and repeated attempts; it works on top of any existing meter; ceilings in currency are comparable across vendors for similar tasks.
• Cons: the vendor needs an accurate cost estimator, and estimation errors land on its margin; vendors have an incentive to pad ceilings, so buyers need data on actual against ceiling; open-ended work such as a novel incident investigation will produce wide ranges; an approval step adds latency unless policies handle it; activity is still what gets billed, rather than value.

Design B: Reserved agent capacity

The buyer reserves a number of agent lanes, each with a monthly throughput allowance (for example, a number of task-hours or concurrent runs), for a fixed annual fee. Work inside the reservation is unmetered. Bursts above it are billed at a published on-demand rate, or queued if the buyer prefers. The model resembles reserved cloud capacity.

• Pros: the most budget-friendly option, a fixed line item that finance can plan around; no incentive to ration use inside the reservation, which supports adoption; revenue predictability for the vendor; the throughput allowance bounds the vendor's inference cost better than an unmetered seat.
• Cons: buyers pay for idle capacity, the same waste as unused seats or non-rolling credits; sizing the reservation needs usage history most buyers do not have yet; a "lane" is defined by the vendor and hard to compare across vendors; heavy tasks inside the allowance still erode vendor margin unless the allowance is measured in compute rather than time.

Design C: Verified-outcome hybrid

Three components: a small platform fee, a per-attempt floor priced near the vendor's inference cost, and an outcome fee charged only when a contract-defined result is verified with the buyer's own data. Examples of definitions: a support ticket closed and not reopened within 7 days; a pull request merged and not reverted within 14 days; an incident closed with a root cause the on-call engineer accepted. A dispute window lets the buyer contest outcomes before invoicing.

• Pros: the closest alignment between bill and value; failed attempts cost only the floor, so most of the failure risk moves to the vendor; outcome prices are comparable across vendors when definitions match; the floor protects the vendor from paying for failures out of margin, the main weakness of pure outcome pricing.
• Cons: outcomes must be discrete, attributable and verifiable, which suits support tickets far better than incident response, where resolution has many contributors; three components are harder to explain than one meter; verification needs integration with the buyer's ticketing or source control; the buyer's bill rises with the agent's success, which can surprise a budget; revenue is the least predictable of the three designs.

How the Designs Compare with Existing Models

The ratings below are the author's qualitative assessment of each model's public mechanics against the factors above, independent of any single vendor's implementation. Caps, estimators or contract terms can move a given vendor up or down.

Buyer view

Vendor view

No row scores well on every factor. The pattern in both tables is a trade between the two sides: the models that protect the vendor's margin best (tokens, credits) leave the buyer with the failure risk and the least predictability, and the models that align best with buyer value (outcomes) put the vendor's margin and revenue forecast at risk. Each of the three designs targets one part of that gap.

Recommendation

As a default for agent platforms, including observability, Design A, quoted-ceiling task pricing on top of an existing credit or token meter, offers the best balance on the evidence available. The reasons:

• It addresses the gap recorded in both analyses: buyers can cap and alert today, but cannot see a task's price before it runs.
• It keeps the vendor's cost coverage. The underlying meter still tracks inference cost, which is the concern behind the coding-agent moves to token pricing.
• It needs no new unit, no outcome definitions and no integration with the buyer's systems, so it can be added to the credit and token models observability vendors already run.
• It moves the cost of runaway loops and repeated attempts to the party that controls the agent's behavior.
• With an auto-approval threshold, it lets teams run routine tasks without an approval step, which limits the internal gating that unpredictable meters tend to produce.

The recommendation has limits. Design A depends on cost estimators that vendors have not shown publicly at task level, and its value to buyers depends on ceilings being reasonably tight. It also keeps billing tied to activity. Where outcomes are discrete and the buyer can verify them independently, as with support tickets, Design C aligns better with value and the customer service market already shows buyers will accept per-outcome prices. Where usage is steady and high, such as scheduled internal automation, Design B gives finance the simplest number. A buyer evaluating any of the three should ask for 90 days of actual consumption data on comparable workloads before committing.

Questions to Ask Under Each Model

• Credits, tokens or executions: what is the distribution of units per task, including the 95th percentile, and do failed or abandoned runs consume units?
• Outcomes: who measures the outcome, with which data, can the buyer audit it, and what is the dispute window?
• Seats and bundles: what fair-use limits apply, and what happens to price at renewal once usage data exists?
• Any model: what happens at the cap, and does the agent stop mid-task, finish the task, or switch to on-demand billing?
• Internally, before signing: who will be allowed to start an agent, what approval will a run need, and how will the organization notice if teams move to unsanctioned AI tools instead?

Method and Limits

Vendor prices were taken from the vendors' own pricing pages and documentation on October 5, 2026: Salesforce, Intercom, Zendesk, Microsoft Learn, GitHub Docs and the GitHub blog, Devin and Sierra. Observability prices are as reported in the September 24 analysis and were not re-checked. Several third-party pricing guides surfaced in search were stale (one still described Devin's pricing in agent compute units, which no longer appear on Devin's pricing page) and were not used for prices. The Gartner figures come from CIO Dive's July 6, 2026 coverage of a July 1 Gartner release, because the Gartner page could not be retrieved directly. The 3.8% outcome-pricing share comes from Orb, a usage-billing software vendor, based on a sample of 80 companies; its method is only partly described. ServiceNow's assist-based model is mentioned without prices, because no public ServiceNow price page was found. The section on organizational culture and shadow AI describes likely mechanisms; no public study measuring them was found. The worked example uses list prices and illustrative assumptions and excludes seat and platform fees. The three designs are analytical proposals, and the ratings are qualitative judgments.

Sources

1. Earlier analysis: How Observability Vendors Price AI Agents, September 2026, with its observability vendor sources.
2. Salesforce: Agentforce pricing.
3. Microsoft: Copilot Studio billing rates and management, Copilot Studio pricing.
4. GitHub: GitHub Copilot is moving to usage-based billing, April 27, 2026, Copilot requests documentation.
5. Cursor: pricing update and apology, July 4, 2025.
6. Devin: pricing.
7. Intercom: pricing.
8. Zendesk: pricing.
9. Sierra: Outcome-based pricing for AI agents, December 10, 2024.
10. Gartner via CIO Dive: coverage of Gartner's July 1 release, July 6, 2026.
11. Orb: AI agent pricing trends.