Interesting, but the example of Github copilot pro must not be forgotten. It may be said that copilot was selling access to models, but if we’re putting it on that way, then every AI app is selling access to models so let’s say they were selling code. Initially they priced per request, i.e. per feature (proxied) that the dev wanted to implement. But that totally backfired because of the unpredictability of the workflow the agent had to do. I believe that the winners will be those who are capable of reducing the marginal cost of each new / unpredicted workflow, and at that point they can price by outcome. Otherwise the customer risks paying a lot of money for nothing (as the vendor must protect from unpredictability), or the vendor will blow up like Github
Completely agree with this thesis. At Now4real (a group chat SaaS for websites), we made the deliberate choice to price our AI-based moderation per 1,000 analyzed messages, completely abstracting away the concept of tokens. Our customers care about keeping their communities safe, not about doing the math on our underlying compute costs. By pricing based on the actual unit of value delivered—the message—we eliminate friction, keep our pricing predictable, and ensure we aren't confusing our application's value with an LLM provider's cost structure.
Charging per token for an application is admitting you're still costs, not outcomes. The customer isn't buying your token bill—they're buying the brief, the implemented change, the resolved conversation. Price the thing they'd notice if it disappeared, not the thing you'd notice on your infrastructure invoice. Otherwise you're just passing your anxiety along with a markup.
Pricing-unit mistakes are a capital-allocation tell. The scarce edge is deciding which AI business models still deserve capital when demos outrun constraints.
Makes sense. A restaurant doesn't set menu prices as a fixed multiple of the price of ground beef. There are other things that go into making a meal, and pricing based on only one raw ingredient while completely ignoring other ingredients, both literal and metaphorical, is missing most of the picture.
This is the pricing shift AI actually needs. Customers don’t care how many tokens a task consumed, they care whether the task got done and what it was worth to them. The winners may be the companies that figure out how to price AI around outcomes rather than compute.
Pricing at the application layer but be a function of outcomes delivered i.e. value generated over tokens consumed. Models are but a commodity and not the be all and end all.
This is the pricing philosophy we have been following to build our foundational infrastructure of agentic commerce at AFCP AI.
at getnius.com we started with credit based model and later switched to packages and subscription. credits is a unit in which it is difficult to measure result/outcome.
I’d add one qualification: outcomes only work as a pricing unit when both sides can agree on attribution.
For many workflow SaaS companies, the cleaner model may be a platform fee + usage tied to a recognizable unit of work: a workflow completed, case processed, account researched, claim reviewed, etc.
That gives procurement something measurable and forecastable without forcing the vendor to price against an outcome it doesn’t fully control. The task/workflow may often be a better commercial unit than the ultimate outcome.
Interesting, but the example of Github copilot pro must not be forgotten. It may be said that copilot was selling access to models, but if we’re putting it on that way, then every AI app is selling access to models so let’s say they were selling code. Initially they priced per request, i.e. per feature (proxied) that the dev wanted to implement. But that totally backfired because of the unpredictability of the workflow the agent had to do. I believe that the winners will be those who are capable of reducing the marginal cost of each new / unpredicted workflow, and at that point they can price by outcome. Otherwise the customer risks paying a lot of money for nothing (as the vendor must protect from unpredictability), or the vendor will blow up like Github
I use claude all day including for writing code.
I do not understand what you are proposing.
I have no clue how I could define outcomes.
Token pricing from my perspective is good for both me and anthropic.
If I'm paying for tokens, I'm more careful on prompts and how I use agents.
Pricing on outcomes would be great. But I have no clue how it would work.
Completely agree with this thesis. At Now4real (a group chat SaaS for websites), we made the deliberate choice to price our AI-based moderation per 1,000 analyzed messages, completely abstracting away the concept of tokens. Our customers care about keeping their communities safe, not about doing the math on our underlying compute costs. By pricing based on the actual unit of value delivered—the message—we eliminate friction, keep our pricing predictable, and ensure we aren't confusing our application's value with an LLM provider's cost structure.
I am working on a SaaS now and am trying to figure out how to implement this. This comment on this article is great!
Charging per token for an application is admitting you're still costs, not outcomes. The customer isn't buying your token bill—they're buying the brief, the implemented change, the resolved conversation. Price the thing they'd notice if it disappeared, not the thing you'd notice on your infrastructure invoice. Otherwise you're just passing your anxiety along with a markup.
Pricing-unit mistakes are a capital-allocation tell. The scarce edge is deciding which AI business models still deserve capital when demos outrun constraints.
Makes sense. A restaurant doesn't set menu prices as a fixed multiple of the price of ground beef. There are other things that go into making a meal, and pricing based on only one raw ingredient while completely ignoring other ingredients, both literal and metaphorical, is missing most of the picture.
This is the pricing shift AI actually needs. Customers don’t care how many tokens a task consumed, they care whether the task got done and what it was worth to them. The winners may be the companies that figure out how to price AI around outcomes rather than compute.
You are absolutely right Sarah and Tugce!
Pricing at the application layer but be a function of outcomes delivered i.e. value generated over tokens consumed. Models are but a commodity and not the be all and end all.
This is the pricing philosophy we have been following to build our foundational infrastructure of agentic commerce at AFCP AI.
at getnius.com we started with credit based model and later switched to packages and subscription. credits is a unit in which it is difficult to measure result/outcome.
This is great but why has the dominant model in AI pricing coalesced to “all you can eat for $20/user/month”?
Though I guess I can interpret that as $20/user/month for up to N credits”.
I’d add one qualification: outcomes only work as a pricing unit when both sides can agree on attribution.
For many workflow SaaS companies, the cleaner model may be a platform fee + usage tied to a recognizable unit of work: a workflow completed, case processed, account researched, claim reviewed, etc.
That gives procurement something measurable and forecastable without forcing the vendor to price against an outcome it doesn’t fully control. The task/workflow may often be a better commercial unit than the ultimate outcome.