4 min read
The token pricing trap bites builders, not just end users
AI's credit and token pricing models obscure value for end customers, but the confusion flows upstream too—hurting every team that builds on top of AI APIs.
By intermac
The AI industry has a pricing problem, and it is not just a marketing failure. It is a structural one that runs all the way down the stack.
Elena Verna's thorough breakdown of AI pricing pages documents what anyone who has recently shopped an AI subscription already knows: credits obscure real value, "5x more" usage means five times an undisclosed baseline, and even well-funded companies treat a pricing page as optional. Her framing is from a growth and monetization angle, aimed at AI companies selling to consumers. But the same dysfunction hits builders directly.
The downstream problem
When you build a product on top of an AI API, you face two layers of pricing opacity at once. The API provider charges you in tokens or compute units whose real cost per user action is hard to predict in advance. You then have to design your own pricing on top of that uncertainty. You are essentially quoting a fixed price for work whose cost you cannot fully estimate. That is not a growth strategy problem—it is a margin problem.
Verna identifies why this is structurally hard: general-purpose AI agents can take wildly different amounts of compute to complete what look like identical tasks. Two users asking an agent to "write a sales email" might consume ten-to-one resources depending on how the model reasons through it, what tools it calls, and how many retries it takes. You cannot predict that at plan design time. So you either over-price to protect yourself or under-price and absorb the variance.
Credits are not the villain
It is worth defending the credit model a little, because the reflex to abolish it entirely is wrong. As Verna notes, when a product uses multiple models and tools with different underlying costs, a common internal currency is a reasonable way to package that into something subscription-shaped. The alternative—exposing raw API economics to your users—is worse. Nobody wants a miniature AWS bill for asking a question.
The real failure is not inventing the currency. It is failing to anchor it to anything a customer can reason about. Saying "100 credits" means nothing. Saying "100 credits builds roughly three complete landing pages" means something. The number is still approximate, but it gives the buyer a reference point. That is the gap most products refuse to close, because closing it requires committing to a claim the product team is not confident making.
What we think builders should do
If you are designing pricing for an AI-powered product right now, a few principles hold even in an uncertain environment:
- Anchor to outcomes, not quantities. Even rough anchors—"enough to process about 50 documents a month"—are better than raw credit counts. You will be wrong sometimes. That is fine.
- Make the worst case visible. If a single action can consume a large chunk of a user's allowance, say so before they start, not after. Surprise limits destroy trust faster than high prices do.
- Watch your cost variance, not just your average. Average inference cost per user tells you less than the distribution. A small number of heavy sessions can wreck the economics of a tier that looks fine in aggregate.
Verna's conclusion is that the company that makes AI pricing understandable and predictable—without going bankrupt doing it—will have a real competitive advantage. We agree. But that advantage starts at the API layer and compounds at every product built on top of it. Builders who solve this for their own users will find it much easier to grow past the early-adopter segment that currently tolerates the confusion.
Sources
- What on earth is going on with AI pricing and packaging? (original)
- Found via the TLDR newsletter