Seats, tokens or outcomes: AI broke the old pricing metrics
On 16 June 2025 Cursor, the AI code editor, changed its $20-a-month Pro plan. Before, the plan included 500 fast requests a month. After, it came with $20 of usage credit billed at the underlying model providers' rates. The company's chief executive explained that new models can spend many more tokens per request on long tasks, and that Cursor had been absorbing those costs under the old plan. Many users found their allowance gone in days, some were billed for overages they had not expected, and on 4 July chief executive Michael Truell apologized in a blog post, saying the company had not handled the rollout well and promising refunds to users who had been charged unexpectedly.
It was a case where a sound economic instinct met a poor execution. The instinct was right: a plan whose price does not move with the cost it creates will, sooner or later, be priced out of line with its heaviest users. The execution was wrong because the new metric was unclear to customers, who could not predict what they would be charged. Between those two failures lies the whole problem of pricing AI products, and it is harder than pricing the software that came before it.
My argument is that the traditional pricing metrics each fail in a particular way for AI, that the better metrics fail differently, and that a short set of tests can help a seller choose and a buyer evaluate. The framework applies to buyers as much as to sellers, since a company that buys AI under the wrong metric will pay for it too.
Why seats stopped working
Per-seat pricing was the default for business software because a seat tracked two things at once. It tracked the value the customer got, which grew with the number of people using the product, and the cost to the vendor, which was small and roughly flat per user. Both links break with AI.
The first link breaks because AI substitutes for people. If an AI agent resolves a large share of support tickets, the customer needs fewer human agents, and a vendor that charges per human seat sees its revenue fall as its product succeeds. Seat pricing punishes the vendor for being good at automation. This is why companies that sell to support teams have moved toward charging for work done.
The second link breaks because the cost per user is no longer flat. A person who sends a few prompts a day and a person who runs agents continuously can differ in inference cost by a factor of ten or more. OpenAI's chief executive said in January 2025 that the company was losing money on its $200-a-month Pro subscriptions because people used them more than expected. A flat price on a variable cost produces an unprofitable tail of heavy users, and the usual remedies are limits, throttling and surprise changes, which customers resent.
The alternatives, and how each can fail
Usage pricing, in tokens or requests, tracks the vendor's cost closely. It fails the customer's need to predict a bill and, usually, the link to value: a customer cannot tell what a million tokens will accomplish. It also exposes the customer to the vendor's design choices. If the vendor's agent loops five times, the customer pays for five loops. Cursor's experience shows how badly an unclear usage metric can land.
Action-based pricing is a middle form. Salesforce launched Agentforce in 2024 at $2 per conversation. In May 2025 it added Flex Credits, at $500 per 100,000 credits, where one agent action consumes 20 credits, or $0.10. The metric is closer to what the agent does than a token is, and it is predictable at the level of a workflow. An analysis cited in secondary coverage shows the sensitivity: a service interaction that takes five actions costs $0.50 under Flex Credits against $2.00 per conversation, and one that takes thirty costs $3.00. The customer's bill depends on how many steps the agent takes, which the customer does not control.
Outcome pricing charges when the job is done. Intercom prices its Fin support agent at $0.99 per resolution, and Fin's documentation, as described in several reviews, counts as a resolution a conversation where the customer confirms the answer helped, and also one where the customer simply stops asking for help. The appeal is plain. The customer pays only for results, the price is tied to value, and the vendor is rewarded for making the product work.
An example of outcome economics
A made-up numerical example shows both the appeal and the risk. Suppose a human-handled ticket costs the company $3.00 in loaded labor. An AI agent costs its vendor $0.10 per conversation in inference and infrastructure, whether or not it resolves the case, and the vendor charges $0.99 per resolution. If the agent resolves 60% of conversations, the vendor earns 0.6 × $0.99 = $0.59 per conversation, a gross margin of 83%. The customer saves 0.6 × $3.00 = $1.80 in labor and pays $0.59, for a net saving of $1.21 per conversation. If the resolution rate falls to 30%, the vendor's revenue per conversation falls to $0.30, its margin to 66%, and the customer's net saving to $0.60. The vendor breaks even at a resolution rate of about 10%, and the customer gains whenever the price per resolution is below the cost of a human resolution.
The arrangement is attractive to both sides, and it is exposed at a single point: the definition of "resolved."
Where outcome pricing goes wrong
A metric that earns money creates an incentive to move it. If a conversation counts as resolved when the customer stops replying, then a bot that is slow to escalate, hard to argue with and easy to give up on will produce more billable resolutions without solving more problems. This is Goodhart's law in a contract. Reviews of Intercom's pricing, some of them written by competitors, raise exactly this concern, and sources disagree on the rule's details, such as how long the customer must stay silent. The concern applies to any outcome metric that the vendor's product can influence without delivering the underlying value.
Guardrails are available. Count only confirmed resolutions, or discount assumed ones. Credit the customer for a case that reopens within a set number of days. Audit a random sample of billed resolutions by hand every month, with the right to dispute. Define the outcome in the contract with the same care as a service level, including examples of what does not count.
A second problem is attribution. The outcome depends on factors the vendor does not control: the quality of the customer's knowledge base, its policies, the product defects that generate tickets. A vendor with great technology can look poor because the customer's documentation is thin, and a customer can attribute to the AI a result that the new knowledge base produced. Outcome contracts work best where the vendor controls most of the variables.
A third is volatility. Revenue that moves with outcomes is harder to forecast and finance. Enterprise buyers dislike open-ended bills and often ask for a cap. Sellers need a floor.
The outcome example has a second lesson, about how to set the price. The ceiling on what a buyer will pay is the value it gets, and the value of a resolved ticket here is the $3.00 of labor it replaces, plus whatever benefits come from faster service. The floor is the vendor's cost. Between them, a price of $0.99 captures about a third of the labor saving, leaving $2.01 with the buyer. A seller can capture more by raising the price, with diminishing appeal to the buyer, or less by lowering it, with a thinner margin. The point is that the price should be placed deliberately in that interval and not derived from cost plus a markup, which would price the same product at $0.15 and give away most of the value, or from a competitor's list, which carries no information about this customer's alternative. The customer's alternative, what it pays today for the same result, is the anchor that matters.
Flat rates remain popular with buyers for reasons that are not purely rational. Anja Lambrecht and Bernd Skiera showed in a 2006 study of consumers' choices of tariffs that many people choose a flat rate even when a per-use price would cost them less, and they identified several biases behind it, including the preference for insurance against a high bill and the pleasure of not counting. For a seller that means a switch from flat to metered pricing meets resistance that the arithmetic does not explain. For a buyer it is a reason to check, before signing a flat plan, whether the actual usage would have cost less under a metered one, and whether the vendor's flat plan has a fair-use clause that will bite.
Changing prices without a revolt
The Cursor episode contains most of the lessons on how to make a transition. Customers were unhappy about the change, and they were angrier about not being able to see it coming or to monitor it afterward. A better practice runs as follows. Announce the change well ahead of the date. Compute each customer's bill under the new metric using their last three months of actual usage and show it to them, so nobody finds out on the invoice. Offer a period in which existing customers keep the old terms, or a cap on the increase, while they adapt. Provide a usage meter inside the product that updates in real time, and alerts at thresholds the customer sets. Provide a clear route to a refund when the meter or the documentation was at fault. A pricing change is a change in the relationship with the customer, and it should be handled with the care of a product release.
A hybrid is usually the answer
Most durable pricing models for AI products combine elements. A platform fee covers fixed costs and the base relationship, giving the vendor a predictable floor. A committed volume of outcomes or actions at a discounted rate gives the buyer predictability. Overage above the commitment is priced per unit. Salesforce's later offerings, which add per-user licenses on top of consumption credits, are an example of the same drift toward hybrids, as are the plans of consumer AI products that combine a monthly price with usage limits and paid top-ups.
For the seller, the combination hedges against both failure modes: a floor against unprofitable light use, and a link to usage or outcomes against unprofitable heavy use. For the buyer, the structure allows a budget with a ceiling and a mechanism for paying for additional value when it arrives.
Four tests for a value metric
A metric should pass four tests, and a pricing proposal can be scored against them.
- Does it track the value the customer receives? A metric the customer cannot connect to a benefit will feel like a tax.
- Does it track the cost the vendor incurs? If cost and price drift apart, one side will eventually pay.
- Can the customer predict and control it? Surprise bills destroy trust faster than high prices do.
- Can both sides measure it without dispute? A metric that needs an argument every month is a legal expense.
| Metric | Tracks value | Tracks vendor cost | Predictable and controllable | Easy to verify |
|---|---|---|---|---|
| Seat | Weakly, and less each year | Poorly | Yes | Yes |
| Tokens | Weakly | Closely | Poor | Yes |
| Actions or requests | Moderately | Moderately | Moderate | Yes |
| Outcomes | Closely | Moderately | Moderate | Hard |
| Hybrid | Depends on mix | Depends on mix | Good | Moderate |
No metric scores well across the row. The design problem is to choose the one whose weakness you can manage: the outcome metric's weakness in verification can be managed with audits, the token metric's weakness in prediction with budgets and caps.
What buyers should do
Buyers can use the same tests. Ask the vendor for the definition of the metric in writing, with examples. Ask what the bill would have been for the last three months of your actual usage. Ask for caps and alerts. Build a model of your own volume and the vendor's price, and run the pessimistic cases, including the one where the agent takes three times the steps. And compare the vendor's outcome price with your own cost of the same outcome, which is the number that determines whether the arrangement is a bargain.
Two clauses deserve attention in negotiation. The first is price protection: since the cost of serving a given level of capability has been falling quickly, a contract that fixes the price for two or three years should include a mechanism, such as a review at fixed intervals or a most-favored-customer clause, to share the savings. The second is the right to audit and dispute the metric. A buyer that cannot check how resolutions, actions or tokens were counted is trusting the vendor's meter. For a company billed in a foreign currency, the invoice currency is also a pricing term, since a price fixed in dollars carries the exchange risk to the buyer, and some vendors will quote in the local currency for a modest premium.
Sources
- TechCrunch (7 July 2025). Cursor apologizes for unclear pricing changes that upset users; Truell, M. (4 July 2025). Blog post on Cursor pricing; additional coverage of the change of 16 June 2025.
- Altman, S. (January 2025). Post on losses from ChatGPT Pro subscriptions, as reported by the press.
- Salesforce (May 2025). Salesforce Introduces New Flexible Agentforce Pricing; Agentforce launch pricing of $2 per conversation (2024).
- Intercom. Fin pricing documentation ($0.99 per resolution), and reviews of its resolution definitions by third parties.
- Goodhart, C. A. E. (1975). Problems of Monetary Management: The U.K. Experience. Papers in Monetary Economics, Reserve Bank of Australia.
- Illustrative support economics: $3.00 labor per ticket, $0.10 vendor cost per conversation, $0.99 per resolution, resolution rates of 60% and 30%, as stated in the text.
- Lambrecht, A., Skiera, B. (2006). Paying Too Much and Being Happy About It: Existence, Causes, and Consequences of Tariff-Choice Biases. Journal of Marketing Research 43(2).