This week someone metering LLM calls asked for help with a sentence. He has to state a usage allowance on a pricing page, and neither way of writing it works. "3 million credits" is honest and means nothing to a buyer, because no human can picture three million credits. "About 1,500 generations" is legible, and it becomes a lie the moment usage patterns change. He wanted wording that survives contact with real customers.
Better wording is not the fix. His two sentences do not differ only in how clear they are.
It is a grammar problem.
One thing first, so you can weigh the rest properly. I do not sell a metered product. I run Referralful, affiliate software for SaaS, and our pricing is flat (free until your first affiliate, then $19.99 a month). I have never had to defend a credit estimate to a customer who blew through it in nine days. What follows is reasoning about how the sentence works, not a war story. Every number below is invented for illustration.
A pricing page gets written once and read for years
You write it in an afternoon. Then it sits there through two model migrations, a feature launch that quadruples token use per action, and a slow drift in who your customers even are.
Nothing on that page knows any of this happened. There is no test that fails, no alert, no customer complaining in month one. The sentence just quietly goes from true to false while the deploy log stays empty.
Most pricing-page dishonesty is not intent. It is tense.
Refusing to translate is not the safe option
The obvious defensive move is to retreat to "3 million credits" and let the user work it out. That feels safe because it cannot be wrong.
It is not safe. It moves the estimating work onto someone with strictly less information than you, at the exact moment they are deciding whether to sign up. They cannot do the math, so they guess, and a guess about whether a plan fits usually resolves as "not yet." You did not avoid the risk. You paid for it at the top of the funnel instead of in a support ticket, and you also lost the chance to learn what a realistic month looks like for that customer.
Both sentences are bad. They are bad in different directions, which is why splitting the difference produces something that is vague and wrong.
Change what kind of sentence the number sits in
Forecast: About 1,500 generations a month.
Observation: Customers on this plan ran a median of 1,500
generations in the 30 days to 1 August.
The forecast makes a promise about the future on the user's behalf. It depends on prompt length, model pricing and feature mix, all of which move without anyone touching the page. It decays.
The observation describes something that already happened. It cannot decay, because the past does not change. It also carries more information than the estimate did: a median from real customers tells you what people like you actually do, which is what the reader wanted to know in the first place.
Same shape everywhere:
Forecast: Enough storage for roughly 50,000 photos.
Observation: Half of Pro accounts stayed under 12 GB last month.
Our median upload is 3.4 MB.
Forecast: Plenty of API calls for a small team.
Observation: The median team of five made 40,000 calls in July.
The busiest ten percent made over 300,000.
That last line matters more than the median. Publishing the top decile tells the heavy user to look at the next plan up, before they find out the hard way.
The date is what makes it honest
An observation with no period attached is just a forecast wearing better clothes. "Customers ran a median of 1,500 generations" ages into a claim about now, and then you are back where you started.
So put the window on the page. "In the 30 days to 1 August." Then set a recurring job that recomputes it and a calendar reminder for whoever owns the page. If you cannot commit to the recompute, do not publish the observation, because a stale median is worse than a rough estimate: it looks like evidence.
A number with a date on it is a claim you can defend in a support thread. You show the query.
What to do when there is nothing to observe
You launched last week. You have four customers, two of whom are friends. There is no median, and inventing one is the single worst thing you could do here.
Say so, and publish the mechanism instead. Tell people exactly what consumes a unit, in the units they think in: one credit per generation up to 1,000 output tokens, a long draft usually costs four to six, image generation costs twelve. Now the reader estimates for themselves with your actual arithmetic rather than your optimism, and nothing on the page can rot except the price list.
Then replace it with a real median the month you have one.
Unlimited is the same bug, louder
"Unlimited" is a forecast about your own tolerance. It is true right up until someone builds a business on top of your generosity, at which point you write a fair-use clause and quietly redefine the word.
That walk-back happens by email, to the one customer causing pain, while the pricing page keeps making the original promise to everyone else.
A number with a date on it is a claim. The same number with the date stripped off is a promise, and you do not get to decide when you have broken it.
Top comments (0)