Insights
Show cost before an action, a meter during use, warnings before the limit, a clear choice at it, and invoice lines a user can explain. Plus admin caps. Show an AI feature's cost at five points: before the action, as a meter while the user works, in warnings before a limit, as a clear choice at the limit, and as invoice
Show an AI feature's cost at five points: before the action, as a meter while the user works, in warnings before a limit, as a clear choice at the limit, and as invoice lines the user can explain. Give the admin a separate set of controls: caps, alerts and a way to see who spent what. Do this because AI made cost a property of each action. A person who cannot predict what an action will cost stops using the feature, and an admin who cannot cap it eventually cancels. So design the meter before the feature ships.
This page is about the billing and usage screens your customers see. It does not cover what to charge. For retention and engagement beyond billing, see our piece on strategies to boost SaaS user engagement and subscriptions.
The moments that matter
A billing experience is a sequence of moments, and each has one job. Many products cover the invoice and little else.
| Moment | What the user needs to see | Failure if missing |
|---|---|---|
| Before an action | A cost, a range or a size band for this action, in the unit the plan uses | The user avoids the feature, or runs something expensive by accident |
| During use | A meter showing used, remaining and when it resets | The limit arrives as a surprise |
| At thresholds | A warning with the remaining amount and the options | The user learns about the limit at the moment of blockage |
| At the limit | What happens now, who decides, and the next step | A dead end, or silent charges |
| On the invoice | Line items that match what the user saw in the product | Support tickets, disputes and distrust |
| For admins | Caps, alerts, allocation per person and an audit trail | The buyer cannot approve wider rollout |
The failure that connects the whole table is the surprise bill. Everything below is a way to prevent it.
Before and during: cost preview and the meter
An exact price is not always knowable in advance, especially when cost depends on how much a model reads and writes. The honest options are a fixed cost per action, a range, or a size band ("small, medium, large") shown before the user confirms. Show the unit the customer is billed in, and never a different internal one.
Some products already charge different rates by model. GitHub documents, for its legacy Copilot billing, that some models count one interaction as several premium requests, with advanced reasoning models at 5 or 20 times the standard rate, and that allowances reset on the first of the month. If your product has that shape, put the multiplier in the picker, where the user chooses. We cover that choice in how an AI product should let users choose a model.
The meter belongs where the work happens, not only on a billing page. It needs four things: what has been used, what is left, when it resets, and how fast the user is going. A meter that shows only a per centage hides the one fact people ask about, which is whether they will last until the reset.
When credits are involved, show the credit ledger as a ledger. Stripe's billing credits are a good model of the underlying data: each credit grant can carry an expiry and a priority, and when several apply, the order of use is defined (priority, then earlier expiry, then promotional before paid). Users should see that order and every expiry date, because an unseen expiry is a lost balance that feels like theft.
Thresholds: warn early, and warn the right person
Warnings work when they arrive while the user still has choices. The vendors that publish their thresholds converge on the same shape. Vercel's spend management notifies a team at 50, 75 and 100 per cent of a set amount, by web and email, with text messages available at 100 per cent. GitHub's budgets alert at 75, 90 and 100 per cent.
A warning should answer three questions in its own text: how much is left, when it resets, and what can be done now. "You have used 80 per cent of your credits" invites a shrug. "You have 1,200 credits left, reset on 1 December; add credits or raise your cap" gives a next step.
Three details are easy to miss:
- Alerts are not instant. Vercel states that it checks spend every few minutes, so notifications and pausing can trigger after the amount is crossed, and advises setting the limit below the real maximum. If your enforcement lags, say so, and leave headroom.
- Alert recipients matter. Vercel sends alerts to people with owner or billing roles, each configuring their own preferences. A warning that reaches only the person who is spending is useless to the person who is accountable.
- Alert once per crossing. Stripe offers a one-time per-customer usage alert for the first time a threshold is exceeded, delivered to you as a webhook. Decide whether your customer receives the equivalent, in the product and by email, and keep it from repeating on every action.
At the limit: degrade, block or overage
The limit is the most important screen in the system, and the key design question is who decides what happens. There are three behaviours, and the product should state which one applies before the limit is reached.
- Block. Usage stops until reset or until someone changes the limit. This is the safe default for a spend cap, but it must say why, when access returns, and who can change it.
- Degrade. The feature continues in a reduced form, such as a smaller model, slower queue or lower volume. Only choose this if the quality change is visible and the user can opt out.
- Overage. Usage continues and is billed. This should be opt-in by someone with billing authority, with a cap of its own.
Two vendor behaviours show why wording matters. Anthropic's API distinguishes a spend limit from a rate limit: a limit the customer set returns an HTTP 400 whose message says when access resumes, while hitting the tier's own monthly cap returns a 429 of the same error type as a rate limit, with a message giving the date access returns but no `retry-after` header, so retrying fails until access resumes. Your interface has the same problem. "Try again later" is correct for a rate limit and wrong for an exhausted budget, so the two need separate messages and separate actions.
Vercel's pause is a switch in the spend settings, and its documentation says that setting an amount alone does not stop usage. The pause says what it does: production deployments stop serving traffic, projects must be resumed one by one, and some usage, such as AI gateway calls, continues to count. Whatever your enforcement does not cover should be on the screen where the cap is set, not discovered afterwards.
The invoice: lines a user can explain
The invoice is where trust is settled. Every line should use the unit and name the user saw in the product, and the totals should reconcile with the meter. Stripe applies billing credits at the moment an invoice is finalised, so a preview or draft invoice can show different credit amounts than the final one. If your preview can change, label it as an estimate.
Break usage down by person, project or feature, whichever the buyer allocates cost by. GitHub's billing reports carry a product column, a gross amount, a discount amount that covers included usage, and a net amount, so finance can see what was included and what was billed (see GitHub's billing reports reference). That split is the one finance teams ask for.
Admin controls: caps, alerts and allocation
The person who signs the contract can be a different person from the one who uses the feature, and they decide whether usage widens. Give them this checklist:
- A hard cap at account level, with a choice between block and overage.
- Caps scoped below the account: team, project, cost centre or person. GitHub budgets can apply to an organisation, repository, cost centre or user, and user-scoped budgets apply only to some products, which tells you scope is something to plan, not retrofit.
- Alert recipients chosen by role, with more than one person per alert.
- A clear distinction between products where a budget only alerts and those where it blocks. GitHub documents both behaviours, depending on whether the product is licence-based or metered.
- Allocation per seat or per person, and a pooled option.
- A change log: who set or changed a cap, and when. Vercel shows spend-management changes in an activity log.
- Export to a spreadsheet or finance tool.
These are interaction design problems with consequences for contracts. If you are working through them for your own product, our interaction and UI design work covers this kind of interface.
Cancelling and renewals
Usage-based billing sits on top of subscriptions, and cancelling is part of the experience. The rules are in motion in the United States. The Federal Trade Commission's 2024 amendments to its Negative Option Rule, the so-called click-to-cancel changes, were vacated: the Eighth Circuit set them aside in July 2025 on procedural grounds. In March 2026 the FTC opened an advance notice of proposed rulemaking on whether to restore some of those provisions, citing over 100,000 complaints in five years about these practices. State auto-renewal laws, California's among them, remain in force. The status can change, so check ftc.gov and take legal advice for your markets.
Whatever the law requires, the design is simple: make cancelling and downgrading as easy as signing up, and show what happens to unused credits before the user confirms.
What to test
- Can a new user predict the cost of their next action, from the screen alone?
- Can they tell, mid-task, how much is left and when it resets?
- Do they understand what happens at the limit before they reach it?
- Can they tell a rate limit from an exhausted budget?
- Does each invoice line match something they saw in the product?
- Can an admin set a cap, find who is spending, and tell whether the cap will block or only warn, without help?
- Does the first warning reach the person accountable?
Test these with the real limit states, using seeded accounts at 80 per cent, 100 per cent and over. A billing flow that only works in the happy path has not been designed.
