The Exchange Rate Problem: Why AI Pricing Pages Don't Translate

A recent essay in Lenny's Newsletter, written by Lovable's head of growth, asked what should be the easiest question in software. If I pay $20 a month for an AI product, what do I get?

The author could not answer it. That is the real finding.

Consider the evidence. Grok sells "4x more usage" without saying what the starting amount is. Muse offers 500 million tokens a week on a monthly bill. Anthropic and OpenAI move you from "More" to "Expanded" to "Maximum." Lovable, the author's own company, sells 100 credits for $25. What a credit buys becomes clear only once you start building. These pages are not all wrong in the same way. They are just as hard to read as each other.

The unit is not the problem

The easy conclusion is that credits and tokens are the villains. They are not. As billing units they work well enough. They track cost, they meter cleanly, and finance teams can reconcile them. The failure is one of translation. A credit describes what the vendor spends. It says nothing about what the buyer gets.

The inconsistency compounds across vendors. A Salesforce credit costs half a cent. A Lovable credit costs a quarter. A buyer comparing the two has no way to convert one into the other. Every vendor has its own currency. None publishes an exchange rate.

Early adopters tolerate this. The wider market will not. A recent Benchmarkit survey of 296 software buyers found that 55% find credit and token pricing harder to evaluate for AI than for traditional SaaS. Small companies and large enterprises say so at much the same rate. More telling is what buyers want instead. Sixty-eight percent rank predictable total cost among their top three priorities. Only 19% say the same of the lowest entry price. Half would pay a higher fixed price for an essential product if it made their spend predictable.

Buyers will pay more for a bill they can forecast. Most AI pricing pages offer the reverse. A low entry price. No forecast.

Each page solved one problem and created another

Choosing what to charge for comes before choosing a price. I test that choice with three questions, which I shorthand as ACE. Can the customer audit what they pay for? Does revenue rise when cost rises? Is it easy to bill and easy to predict?

Tokens and abstract credits pass the second test and fail the other two. Seats pass the third and fail the second. A simple support ticket might cost three cents in model spend, and a messy one a dollar fifty. A seat charges both the same. Each pricing page answered one of the three questions by giving up another. That is why each one confuses buyers in its own way.

The vendor side is harder than most teams model. An agent makes dozens of inference calls per task, and each call carries more context than the one before, so cost rises as the work goes on. Teams estimate cost per task in testing and then watch margins thin in production. Most of the leakage sits in a small share of tasks that loop, retry and escalate. When cost scales with context and price does not, light customers end up paying for heavy ones.

Outcomes are the destination, not the starting point

Outcome-based pricing is often proposed as the cure. On paper it is the most elegant answer. In practice it needs a measurable result both sides trust, an agreed baseline, an attribution rule written before the work begins, and a cost floor that holds when model prices move. Few AI products have all four.

It also needs the customer to stop prompting, reviewing and correcting the AI every day. While a person still does that work, the price pays for their effort as much as for the result. Buyers have noticed. In the same survey, pure outcome pricing scored worst of every model tested.

Translation is the work

None of this calls for a pricing revolution. It calls for a pricing page that speaks the buyer's language.

The structure comes first. Every top-rated model in the survey carried a fixed base fee, and every bottom-rated one lacked it. The sequence I recommend has three layers: a base subscription for predictability, a usage metric the buyer already understands, such as workflow runs or documents processed, and an outcome component added only once measurement and trust exist.

Then comes the translation itself. "100 credits" means nothing. "A simple landing page takes 15 to 30 credits, median 20, measured across 25 test builds, last checked October 2026" means a great deal. A single number breaks the first time an agent retries. A range with its conditions does not. At a quarter per credit, that landing page costs about $5, and the buyer can count how many fit in a plan.

Control matters as much as clarity. Nearly nine in ten buyers have overrun their initial AI budget, and only one in ten blames the vendor for changing terms. Most simply used more than they planned. What they ask for is a soft cap with an alert and an approval step. Prepaid credit pools ranked last of all the controls tested, and that is roughly how most AI subscriptions work today.

The invoice is the last place to translate. For ELDA, a procurement agent, I designed a monthly bill that sets an unbilled value report beside the charges: 236 reconciliation runs, 142 purchase orders approved, and the agent's autonomy rate. Overage was capped at €150, so the customer always knew the worst case. A buyer who can see what the credits produced stops asking what a credit is.

The question worth answering

The first step is small. Pick the three tasks customers run most often. Measure what each one costs in credits at the median and at the 80th percentile, and publish those ranges, dated, on the pricing page. Add a soft cap before the next billing cycle.

Lenny's essay asked what $20 buys. The vendors that win the next phase of AI will not be the ones with the cheapest credit. They will be the ones that told their customers what it was worth.