A customer asks what next month's bill will be. If the answer needs an explanation of input tokens, output tokens, model routing and several markups, your pricing page has a difficult job.
In a Stripe post published on 1 October 2026, Metronome founder Scott Woody argues that token metering is useful for tracking costs but often makes a poor customer-facing pricing model. He describes unified credits as a way to translate several kinds of underlying usage into one customer balance.
Start with what the customer can count
Our view is that a useful billing unit should help a customer estimate usage before they commit. An agency may understand the number of reports it runs or images it produces more readily than the model tokens used underneath.
That does not make an output-based price easy to design. You need a precise definition of what counts, when the charge happens and which operations are included.
Take a report generator as an example. Decide whether a failed report costs anything, whether rerunning an identical report creates another charge and whether a preview is billable. Those decisions will reach support as soon as the first unexpected invoice arrives.
Credits need a visible exchange rate
A credit balance can make several product operations easier to combine. It can also move the complexity into another unit if customers cannot see what their money buys.
Show realistic examples on the pricing page. Explain how many credits a typical operation consumes, what happens to unused credits and whether rates can change during a paid period.
A usage screen should use the same definitions as the invoice. If one says tasks and the other says credits without a clear connection, the customer has to do the reconciliation themselves.
Put spending controls beside the meter
Usage pricing works better when people can control it. Give customers an understandable allowance, useful alerts and a clear explanation of what happens at the limit.
Distinguish a warning from a hard stop. A customer who sets a budget may reasonably expect the product to stop charging there. If it continues running, the interface needs to make that behaviour clear before they save the setting.
Test the explanation with someone who does not work on the billing system. Ask them to estimate a sample month's cost from the pricing page alone.
Keep cost tracking detailed behind the scenes
Your internal records still need enough detail to explain costs and investigate errors. Preserve the relationship between each customer operation, the work it triggered and the charge eventually shown.
Review unusually expensive operations before promising a flat rate. The typical customer journey and the heaviest legitimate workload can have different economics.
The useful lesson from the debate is a practical one: make the invoice easy to check, and keep the engineering detail available for the people who need to investigate it. A simpler label only helps if the underlying billing rules are clear.
Reporting checked on 13 October 2026. Pricing recommendations are our editorial assessment.
