Token vs. outcome pricing
I've been thinking about why some AI tasks are priced per token while others are priced per outcome. The difference comes down to task structure.
When outcome pricing works
A support ticket lands in the queue. Someone or something needs to handle it - answer a question, process a return, update an account. The ticket is either resolved or it isn't. You can verify that with automation: check the conversation, confirm the account was updated, ask the customer.
These tasks are repeatable, high volume, and independently verifiable. Intercom prices Fin AI per resolution. It's a natural fit.
When outcome pricing breaks
"Resolved" is a proxy. What you actually want is a satisfied customer. A resolved ticket and a satisfied customer aren't the same thing, and the gap between them is where the money leaks. A support agent can resolve a ticket without solving the customer's problem - close it after a single canned response, mark it as duplicate, hand it off to another queue. If your verification is weak, you're paying for tickets to be closed, regardless of whether the customer's problem got solved.
This is the core tension. Strong outcome pricing needs strong verification. The verification itself has a cost, and for some tasks it's nearly as hard as the task itself. Document classification against a known taxonomy? Verification is cheap - the output is machine-checkable. "Did the support agent actually help the customer?" You can survey for that, but the signal is noisy. Response rates are low, and a bad score might mean the product is broken, not that the agent failed. You're solving a subset of the original problem, just with a different proxy.
The second tension is that outcomes compound. A data extraction job can have hundreds of fields. If the model gets 98% right, you still have to decide what counts as a completed outcome - per field, per record, or something else. The granularity of the outcome matters, and it's rarely as clean as the pricing page suggests.
When token pricing fits
Exploratory work doesn't have a finish line. I'm writing this post - there's no test for whether it's done. I iterate until I'm satisfied. A developer exploring a codebase, a researcher digging through papers, someone drafting a proposal - the iteration is the work. You're changing direction, figuring things out as you go.
Token pricing is the honest model here because the cost is proportional to the time spent, which matches the reality of the work. There's no outcome to price against, and trying to invent one just adds overhead.
A useful heuristic
If an independent system can verify success at low cost, outcome pricing fits. If verification is expensive or impossible, token pricing does.
Some tasks fall between. You can verify that a form was submitted, but not that it was filled out correctly. You can verify that a translation was produced, but not that it preserved the meaning. In those cases, a hybrid makes sense: token pricing with an outcome-based adjustment, or outcome pricing with a manual review layer.
Where this is going
Support, data extraction, and booking automation are moving toward outcome pricing. The task structures fit, and verification is getting cheaper.
Open-ended work won't follow. Without a finish line, there's nothing to verify - so there's nothing to price against except the compute. Token pricing stays.