Cost & Quota UX

Denomination is the whole design problem.

The unit you display decides whether the number is information or noise. Tokens are the vendor's unit; dollars are finance's unit; neither is the user's. The user's unit is the thing they asked for — a report, a migrated file, a reviewed contract, an hour of research — and every useful cost surface is denominated in that.

• Bad: "142,000 tokens used." Uninterpretable. The user cannot tell whether that is a lot.
• Better: "$0.94 for this run." Interpretable but unanchored — a lot or a little compared to what?
• Good: "$0.94 — about 3× a normal report, because it searched 40 sources instead of the usual 12." Anchored to a baseline and attributed to a cause the user can change.

The third form is the only one that lets a user do anything. It also costs you nothing extra to produce: you already have the run's median for this task class from your unit economics, and the driver is in the trace.

Three surfaces, three different jobs.

Cost shows up at three moments and each needs a different design. Teams typically build the middle one, which is the least useful of the three on its own.

• The estimate, before the run. Its job is consent. It appears where the user commits — the same place as any other confirmation — and it is the only one of the three that can prevent spend rather than narrate it.
• The meter, during the run. Its job is control, not information. A live counter with no stop button is a stress test, not a feature. If the user cannot act on it, do not show it.
• The receipt, after the run. Its job is calibration — teaching the user which of their requests are expensive so the next estimate is believable. This is the surface almost nobody builds and the one that compounds.

The estimate is a commitment device, so design the band and honour it.

Agent cost is heavy-tailed: the same request can cost the median or twenty times it depending on how many steps the loop takes. A point estimate on a heavy-tailed distribution is a promise you will break, and users experience a broken cost promise as a billing error rather than a modelling limitation.

• Show a band, not a point. "Usually $0.60–$1.10" is honest and users tolerate it. "$0.85" followed by a $4.20 charge is a support ticket.
• Bound the band with a real cap. The top of the range should be enforced in the request path, not aspirational. An estimate whose ceiling is not a limit is a guess wearing a promise's clothes.
• Explain every overrun at the moment it happens, in the driver's terms: "this one is running long because the document had 340 pages". Silence during an overrun is what converts a cost surface into a trust problem.
• Let the user pre-commit to the cheap path. "Quick pass ($0.20) or thorough ($1.40)?" is a better cost control than any cap, because the user chooses with the trade-off in front of them.

Every meter needs a reachable control.

A number that rises while a user watches, with nothing to do about it, is the worst surface in this playbook — it makes the product feel expensive without making it cheaper. Attach at least one of these to every live meter:

• Stop and keep what you have. The most valuable control and the hardest to build, because it requires the agent to be able to return partial work. If a run cannot be interrupted usefully, that is an architecture problem the cost UI is exposing, not creating.
• Downshift. Continue on the cheaper configuration — smaller model, fewer sources, narrower scope. Preserves the outcome while bending the curve.
• Approve to continue. A soft ceiling that pauses and asks rather than failing. The pattern of progressive autonomy, applied to budget instead of permissions.

Note the asymmetry with server-side controls. Your kill switch protects the business from a runaway; this control protects the user from a surprise. They fire at different thresholds, for different people, and one does not substitute for the other.

Quotas that teach, versus quotas that punish.

Most agent products need a ceiling per user or tenant. The design difference between one users route around and one they plan around is entirely in what happens near the boundary.

• Show the remaining budget in the user's unit, not as a percentage of an opaque pool. "About 14 more reports this month" is plannable; "72% of quota remaining" is not.
• Warn on trajectory, not on threshold. "At this rate you will run out around the 22nd" arrives while there is still a decision to make. An alert at 90% arrives after the behaviour that caused it.
• Degrade before you deny. Near the ceiling, drop to the cheaper configuration and say so. A user who gets a slower, cheaper answer keeps working; a user who gets a wall opens a ticket or finds a workaround.
• Never fail silently into a worse model. Quietly downgrading quality to stay under budget is the one move that destroys trust permanently, because the user experiences it as the product getting worse for no reason. See designing for trust.

The metric that tells you whether you built it right.

The obvious success measure is that spend went down. It is the wrong one, and optimising for it produces a product that quietly suppresses its own most valuable use cases.

Here is the failure mode. Cost UX commissioned by finance becomes a deterrent surface: every expensive action is decorated with a warning, users learn that the thorough path is the discouraged one, and usage shifts to the cheap path. Spend falls, the dashboard looks great — and what actually happened is that the workflow with a 55× return got throttled alongside the one that loses money, because the user can see cost and cannot see value. You have reproduced, at the level of a single screen, exactly the asymmetry that makes organisations cut whole deployments instead of individual workloads.

Measure calibration instead: does the user's prediction of what a request will cost match the outcome, and does that gap narrow with use? A well-built cost surface should make expensive-and-worth-it runs more confident, not less. Track the estimate-to-actual error, the rate at which users invoke a control rather than abandoning, and whether high-value expensive workflows held their volume after launch.

Related: agent cost control for the levers behind the numbers you are displaying, cost attribution for getting per-run cost in the first place, and waiting & latency UX for the other meter users watch during a run.