Who controls the compute sets the price.

How AI is sold depends on who controls the compute. In June 2025 Cursor, the AI coding editor, replaced its allowance of 500 requests a month with a pool of credits priced at what the underlying models cost. Its users were furious. Around the same time, customer-service software was moving the other way. Intercom charges $0.99 for each conversation its agent, Fin, resolves, and nothing when Fin hands the customer to a human. Zendesk launched what it called outcome-based pricing for its AI agents. One company made its customers pay for compute; the others stopped charging for compute at all and charged for results.

These moves look contradictory, and they are often read as experiments: a young market trying things until something sticks. I think they follow a rule. The rule comes from asking who controls the variable cost.

What changed

For forty years, serving an extra unit of use cost a software company almost nothing. A customer who opened a spreadsheet ten times a day cost about the same as one who opened it once a week. That is why software was sold as access, by the seat and by the month. Hosting and support did grow with customers, but a seat price covered those.

Generative AI produces something new each time it is used, and each output costs compute. The new cost scales with how intensively each seat uses the product, which a seat price does not cover. Under a flat plan, heavy users are now the expensive ones. In Research Note 001 I show that flat pricing's share of attainable profit falls steadily as inference becomes costlier, and collapses once a unit of compute costs half what the first unit of use is worth. So flat pricing goes. The question is what replaces it.

A contract is a dial

Think of every AI contract as a fixed fee plus a dial. The dial sets what share of each unit of compute is passed on to the customer. At zero, the customer pays a flat fee and the vendor eats every token. At one, the customer pays the compute bill plus a margin. Call the setting the pass-through rate.

Where should the dial sit? Two forces pull on it. The first is insurance. Usage is uncertain, and someone must bear the risk of a large bill. The classic answer, due to the economist Karl Borch, is to split the risk according to how much each side dislikes it: a vendor that is large and diversified should take more of it, a fragile one less. The second force is incentives. Whoever pays at the margin has a reason to economise. Which force wins depends on who is in a position to economise, and that depends on the product.

Copilots: the customer holds the throttle

In a copilot, such as a coding assistant or a chat window, the customer decides how much to ask for. If each request is free at the margin, they will ask for more than it is worth: the longer context, the stronger model, the tenth regeneration. Passing compute through to the customer prices that waste. So in a copilot the dial sits above Borch's benchmark. The customer bears more cost risk than pure risk-sharing would assign them, because they are the one who can act on it.

That is what Cursor did. Its users' anger was real, and much of it was about how the change was announced. But the direction was the one the economics predicts for a product whose users decide how hard to push it.

Agents: the vendor holds the throttle

An agent is different. Asked to resolve a ticket or make a code change, it decides for itself how many steps to take, which model to call, how much context to read and when to check its own work. The customer sees the result, not the process. Now the party who can economise is the vendor. Engineering effort cuts the compute per task: better prompts, routing easy steps to cheaper models, caching, stopping early.

Charging such a product by usage is cost-plus pricing. Every extra step the agent takes is billed. Nothing rewards the vendor for making the agent leaner, and a less scrupulous vendor is paid to pad. Paying per outcome reverses this: the vendor keeps whatever it saves on compute, so it has every reason to save. In an agent the dial sits below Borch's benchmark, and the more engineering can cut compute, the closer it gets to zero, which is pure outcome pricing.

Move the sliders and two things hold. The copilot always sits above the risk-sharing line and the agent always below it, whatever the parameters. And a fragile vendor passes more cost through than a diversified one, in both products. That second prediction is worth noticing: large incumbents can afford to offer flat or capped plans that a startup selling the same product cannot.

An old problem in new clothes

None of this is new to economists who study procurement. Governments buying weapons, roads or software have long chosen between cost-plus contracts, which reimburse the contractor's costs plus a fee, and fixed-price contracts, which pay a set amount for delivery. Cost-plus insures the contractor and kills its incentive to control costs. Fixed price does the opposite. The theory of that choice, developed by Jean-Jacques Laffont and Jean Tirole among others, says to lean towards fixed price when the contractor's effort matters most for cost.

What is new in AI software is that product architecture decides who the contractor is. In a copilot the customer runs the production process, so the customer should face the cost. In an agent the vendor runs it, so the vendor should. As products move from assisting a person to completing a task on their own, control of compute moves from customer to vendor, and the efficient unit of sale moves with it:

seatusagetaskoutcome

The sequence is not a fad, and it does not run at the same speed everywhere. It goes as far as the product's autonomy goes.

The catch: someone has to check

Outcome pricing has a cost usage pricing does not: someone must decide whether the outcome happened. Intercom's answer is instructive. A conversation counts as resolved, and billable, if the customer does not reply within 24 hours of Fin's last message. That is a reasonable proxy, and it is a proxy. A customer who gave up in frustration looks the same as one whose problem was solved. Every outcome contract rests on a definition like this one, and someone pays to write, check and dispute it.

The paper makes the trade-off precise. Paying for outcomes beats paying for usage when verifying an outcome costs less than the efficiency gain, and that gain grows with the square of the compute bill per task. Doubling the compute a task needs roughly quadruples the case for paying by outcome. Cheap tasks are not worth the trouble of verifying; expensive ones are, if their outcomes can be checked.

This gives the move to outcomes a natural order. It comes first where three things meet: heavy compute per task, a clear definition of done and a cheap way to check it. Support tickets either reopen or they do not. Code changes pass the tests or fail them. Insurance claims are processed or rejected. Customer support, where outcome pricing has spread fastest, fits that description well. Tasks whose quality is diffuse, such as drafting a strategy memo or a piece of research, will keep being priced by usage or by seat, however autonomous the agent doing them, because no one can cheaply say whether the outcome was good.

What follows

For anyone building or buying AI software, the rule is short. Find out who decides how much compute gets spent, and make that party pay for it. If it is the user, meter usage, and accept that users will complain about it. If it is the product, price the result, and invest in defining and verifying what a result is, because that definition becomes the contract.

The rule also says something about where value goes. A vendor paid per outcome keeps what it saves on compute. The engineering that makes an agent cheaper to run is therefore not a cost centre. Under outcome pricing it is the vendor's margin, and one of the few advantages that competitors cannot simply copy.

The theory makes predictions that contract data could test. Pass-through should be higher for copilots than for agents, and higher for small vendors than for large ones. Outcome pricing should spread first to tasks that are compute-heavy and easy to check. If those patterns fail to appear, the argument is wrong.