Make Cost Visible When It Changes Behaviour
I do not think every token needs to be shown to a customer. I do think users should understand when an action is materially more expensive, consumes a limited allowance, or can continue indefinitely without another confirmation.
- Credits versus raw tokens
- High-cost action confirmation
- Progressive disclosure
- Cost-aware defaults
- Graceful degradation
The situation
Technical cost units are usually meaningless to customers, but completely hiding consumption creates surprises. The product has to translate internal economics into a user model that supports good decisions.
The naive solution
Display input and output token counts everywhere because that is what the provider bills.
The hidden constraint
Most users do not know whether 80,000 tokens is reasonable. Raw provider units also become confusing when different models and modalities have different prices.
The decision
Expose a stable product-level usage concept: included runs, credits, minutes, generations, or another unit tied to value. Only show detailed provider usage where the audience actually needs it, such as administrators or developers.
The implementation
High-cost actions can show an estimate or allowance impact before starting. Expensive optional features can default off. When budgets are low, the system can switch to a cheaper model, reduce the number of variants, shorten an autonomous run, defer nonessential enrichment, or ask the user to approve further spend. The important part is that degraded behaviour remains understandable rather than silently producing a worse result.
The tradeoff
Abstract credits simplify the user experience but can obscure exact cost. I would keep a detailed admin view behind the product-level abstraction so both audiences are served.
The evidence I would look for
I would look for fewer surprise-limit support tickets and lower spend on abandoned or accidental high-cost actions without harming completion rates.
The reusable lesson
Expose cost in the unit that helps the user make a decision, not in the unit that happens to appear on the provider invoice.
The consultant's questions
- Does the user know when an action consumes a meaningful portion of their allowance?
- What happens when the customer is nearly out of budget?
- Can the product degrade gracefully instead of simply failing?
- Are expensive defaults creating spend that customers never intentionally chose?