How to design transparent AI cost controls

A practical guide to choosing usage units, designing spending limits, and explaining AI costs before, during, and after the work.

Every AI response has a price. People often discover it only when a limit hits or a bill arrives.

A quick edit and a long-running agent can look almost identical in the interface. One finishes in seconds. The other might read hundreds of files, call external tools, and retry steps along the way. Yet both start with the same button.

Meanwhile, AI products keep changing what they charge for: requests, credits, tasks, usage allowances. Showing more technical numbers won’t make those costs easier to understand. People want to know what a job might use, whether it’s worth running, and what they can do to spend less.

For designers, that comes down to two decisions:

1. The unit: what users see themselves spending.
2. The moment: when they understand the cost — before, during, or after the work.

Under the hood: what a token is

A token is a unit a model reads or generates. A tokenizer breaks text into pieces: words, parts of words, punctuation, sometimes even spaces. For English, a useful rough estimate is that one token represents about three-quarters of a word. So a million text tokens might represent around 750,000 English words. The exact count depends on the tokenizer, language, and content.

• Input and output cost different amounts. Model providers commonly charge more for tokens they generate than tokens they read. On several current models, output is about five times the price of standard input. Longer answers, reasoning, and repeated attempts can change the economics of what looks like one request.
• Model choice matters. Output-token prices can differ by tens of times — or more — across models. A request that is cheap in a lightweight model can cost considerably more in a frontier model. The user’s task hasn’t changed, but the meter has.
• Modality changes the calculation. Text, images, audio, and video don’t share one universal token conversion. A short prompt, an image attachment, and a five-minute clip may all look like inputs to the same composer, yet require very different amounts of processing. Some providers charge by tokens, others by frames, seconds, or generation settings.

For a sense of scale, a 15-word prompt might be around 20 text tokens. A 1092 × 1092 image has been estimated at roughly 1,600 image tokens using one image-accounting method. For video, Google’s published static-processing examples imply roughly 30,000–90,000 tokens for five minutes, depending on the resolution setting. Those estimates come from different systems, so they cannot be priced as though they were the same kind of token. That limitation is part of the lesson: a single input box hides very different work.

Why showing tokens fails

Tokens are the system’s currency, not the user’s. People budget in money, time, attention, and finished work. They feel the effects of tokens through longer waits, changing quotas, and unexpected charges — not by counting them.

“382,000 tokens used” may be technically precise. It doesn’t tell someone whether the next research run will fit within their allowance, which part of the job was expensive, or what to change next time.

The job isn’t just to disclose a number. It’s to translate system cost into something people can make decisions with.

Predictability beats precision

There’s a useful parallel outside AI. In a study of 10,882 internet subscribers, Lambrecht and Skiera (2006) found that many customers chose a flat-rate plan even when a metered plan would have been cheaper. In one group, nearly half made that choice; more than half of them paid at least twice what they needed to.

The researchers described two reasons:

• Insurance effect: paying more can feel worthwhile if it removes the risk of a variable bill.
• Taxi meter effect: people enjoy a service less when they have to watch the meter climb.

The study was about internet tariffs, not AI, so it doesn’t prove how AI subscribers behave. But it captures a tension designers know well: people want to understand what they’re spending without being forced to calculate every interaction.

A good AI cost interface gives them that predictability without pretending the underlying costs are fixed.

Decision 1: choose the unit

Before designing a meter or a pricing screen, decide what people see themselves spending.

There isn’t one perfect unit. Raw tokens expose the model’s actual consumption, which is useful in API consoles but hard to reason about in a product workflow. Dollars are easier to recognize, especially for teams managing a budget, but the amount can still change from one run to the next.

Some products charge in natural units such as minutes of audio, pages processed, or GPU time. Others use credits: a product-specific currency that lets very different AI features draw from one balance. Credits simplify billing, but people have to learn what they’re worth.

Closer to the work itself are tasks and actions — one generation, enrichment, or run — and outcomes, where a charge depends on a defined result. These are easier to count because they resemble what the user asked for. They also shift more uncertainty to the vendor: a 200-page document and a one-page email might both count as one summary, despite costing very different amounts to process.

At the other end are usage allowances, where people work within a pool or reset window, and invisible usage, where a feature is included without showing a meter at all.

The important distinction is who carries the uncertainty. Tokens and metered dollars pass more of it to the user. Tasks and outcomes put more of it on the vendor. A usage allowance protects people from per-action calculations, but can leave them guessing when they’ll hit the limit.

Neither end works for everything. That’s why many products use a hybrid approach — an included allowance for everyday work, with separate limits or paid usage for expensive actions.

When to show a price — and when to hide it

A visible cost makes people more careful. That’s helpful for an expensive batch, but exhausting for everyday chat.

For discrete, potentially expensive work — enriching 500 rows, rendering a video, or scheduling a nightly automation — show the price or a credible range before the user commits. That number matters to the decision.

For frequent, exploratory actions like chatting, small edits, or code suggestions, a usage allowance is often better. Putting a price on every interaction turns experimentation into budgeting. But when one job is unusually expensive, even inside a subscription, make an exception: show its likely cost before it starts. The goal isn’t to hide spending; it’s to show it when someone can still act on it.

Usage limits

Instead of pricing each action, the product gives users a pool and shows how much remains. It’s familiar from subscriptions and easy to understand — until the pool disappears unexpectedly.

Where it fits: Consumer and prosumer plans with frequent, exploratory actions.
What good looks like: Users can tell what’s left, when it resets, and what will happen at the limit.
Why it works. Limits remove the need to do arithmetic every time someone sends a message. The user can focus on the work, with a fairly predictable subscription price.

• Show each time window and its reset. Claude uses short session limits alongside weekly limits. A line such as “resets in 1 hr 36 min” beside “resets Friday at 8:00 AM” gives people a plan. “Resets soon” doesn’t.
• Separate genuinely different pools. In the examples above, Cursor distinguishes model usage categories and Claude breaks out a top-model allowance. That helps users connect a decision — using a more expensive model — to the quota it affects. Don’t split pools simply because the billing system happens to have multiple internal counters.
• Explain the overflow order. Show what is consumed first, what happens next, whether on-demand spending is enabled, and where an actual cap applies. Users shouldn’t need to infer the order from three settings screens.
• Give temporary promotions an end date. Claude advertises a temporary higher allowance. Stating when standard limits return avoids making the end of a promotion feel like a stealth reduction.
• Offer an alternative to upgrading. A saved or banked reset in Codex can restore eligible usage windows, subject to plan and expiry rules. Waiting for the reset, switching modes, or reducing scope can be just as important

Tasks and outcomes

Per-action units count something users already recognize: a generation, enrichment, run, or task. The appeal is that the decision and the charge use the same language.

Where it fits: Automations and actions that are easy to count.
What good looks like: Someone can estimate a month’s workload and get close to the bill.

Zapier is a useful reference. In the captured plan, the interface shows “Included tasks: 119 / 750” and “Additional tasks ($0.05/task): 0 / 1,500.” Users can distinguish the included pool from overflow, see the unit price, and understand the potential ceiling.

The more important detail is what Zapier doesn’t count. Triggers, filters, and certain built-in steps don’t count as tasks; successful action steps generally do, while errored steps don’t. Those rules answer a question that matters as much as the price: who pays for failure?

Why it works. An action is legible. If the same action consistently costs the same amount, users can forecast and compare.

Do: Explain what counts, what doesn’t, and how failed or repeated attempts are treated. Give overages their own unit price and ceiling.

Don’t: Call something an outcome if customers can’t independently tell whether it happened.

Credits

Credits let a product use one balance across different features: chat, app building, hosting, deployments, enrichment, or external services. They’re useful, but no one arrives with an intuition for what one credit is worth.

Where it fits: Products offering several expensive AI features under one account.
What good looks like: Users understand both the credit’s approximate value and why a particular action consumed it.

Why it works. Credits make unlike actions comparable and let providers adjust underlying costs without rebuilding the subscription. The left-hand screenshot shows several pools — daily, monthly, rollover, and top-ups — with different expiry rules. The right-hand example attributes deductions to projects and jobs and maintains a running balance. That’s useful accounting.

Where it breaks. The screenshots show several familiar problems:

• No transferable sense of value. A 50-credit pack priced at $30 works out to $0.60 per credit. A different product’s 3,000-credit pack for $500 is about $0.17 per credit. The name is the same, but the unit isn’t. These are snapshot prices from the illustrations, not a shared market rate.
• Fractional deductions without context. “Agent Call: −0.77” is precise but doesn’t tell users what the call achieved.
• Unexplained differences. A deployment costs 50 credits and an agent call costs 0.77. A ledger can record that difference without helping anyone understand it.
• Promotions mixed into accounting. A “20% More” top-up offer belongs in the purchasing flow. On a usage-history screen, it competes with the reason someone opened that screen: checking where the balance went.

Decision 2: choose the moment

Choosing a unit answers what users spend. Next comes when they learn about it.

There are three chances to communicate cost: before, during, and after the work. Ignore them and the user finds out at a fourth moment: the wall, when the allowance runs out or an unexpected charge appears.

Before the work, help people judge the likely cost while they can still change the scope. Explain what drives it, use a range when the total is uncertain, and offer a cheaper mode, a smaller run, or a spending ceiling.

During the work, show meaningful progress instead of an unreliable countdown. Let long jobs run without keeping people on the same screen. Make it clear what stopping will cost, and ask before continuing if the original estimate no longer holds.

After the work, show what was delivered and what it cost. Explain unusual charges, make reused work or savings visible, say how failures are billed, and keep a history people can return to. These are the three moments the illustration brings together.

Before: model selectors, effort controls, and previews

Before a run begins, the user can still change the scope. Three controls are especially useful.

Model selectors. A dropdown of model names can force people into an engineering decision. Not everyone wants that. In August 2025, OpenAI launched GPT-5 with automatic routing, then quickly brought back clearer choices such as Auto, Fast, and Thinking alongside more detailed model controls. The lesson isn’t that model choice should disappear. It’s that most users benefit from an outcome-oriented default, while advanced users still need access to the underlying models.

Effort controls. Effort dials are becoming increasingly common in AI products, but what they actually control remains a mystery to many users. Cursor offers a scale from Low to Extra High, other interfaces use sliders, while deep-research modes make the choice more implicit. All give users some control over how much time and computation a model spends on a task. But what does High really mean compared to Medium? Will the result be noticeably better, take longer, or simply consume more of the user’s allowance? The controls are becoming more familiar, but the trade-offs behind them are still poorly explained.

Previews before large spend. Deep-research screen gives users a plan they can edit before an agent starts reading sources. That’s a strong moment to intervene. The two missing pieces are cost and consent. A plan with five steps doesn’t reveal whether cutting one will save much. And for a genuinely costly job, an auto-start countdown can turn doing nothing into agreement.

A good preflight makes the trade-off concrete: what’s included, what’s optional, what the approximate total could be, and what will happen if the job needs more.

Clay is a useful reference for pricing before execution. In the captured interface, enrichments show figures such as “0.5 / row,” “~3 / row,” or “varies by model.” A recurring signal displays its monthly cost before activation. These labels tell the truth about uncertainty rather than presenting every action as fixed-price.

The same principle applies to scheduled work. Show the likely monthly spend of an hourly or nightly automation, not just its price per execution. Small recurring charges are easy to overlook.

During: progress, cancellations, and changing forecasts

This is the thinnest part of many AI cost experiences. A run starts, a spinner appears, and all the useful controls return only when it’s finished.

Show real units of progress when they exist: 320 of 500 contacts processed, 12 sources checked, three files edited. For open-ended work, show meaningful phases instead of a percentage you’ve invented. Let long jobs move out of the foreground without losing their status.

Where costs accrue as the job runs, display usage so far and the remaining budget or cap. A forecast can change if an agent discovers extra work. When the expected cost moves well beyond the original range — or reaches an agreed checkpoint — pause and ask whether to continue. Don’t silently treat the original approval as unlimited permission.

After: receipts

The receipt connects a charge to the work it paid for. It’s also what helps people make a better choice next time.

• Per action, right next to the result. Replit’s captured run summary lists “13 actions” and what changed; a message menu shows “Worked for 43s” and “Credits used 0.50.” The receipt is available where the work happened.
• Per session, with cost drivers. Another captured panel shows 3,450 credits alongside context used by instructions, tools, messages, files, and tool results. The surprising insight isn’t the total; it’s what consumed the context. A Compact Conversation control gives the user a way to respond.
• Per period, with searchable history. Clay’s usage history can be examined by time, column, run, or provider and exported. That’s what a team lead needs when someone asks why the workspace budget changed.

A breakdown with a way to act is a receipt. A breakdown without one is a report.

For most users, keep the first layer light. Put the deduction and result together; make the technical breakdown one click away; put exportable history where teams already manage billing.

Do: Attach a light receipt to the result, reveal cost drivers on demand, and record the failure policy.

Put it to work

As AI products move toward longer, more autonomous workflows, the cost of a single action becomes harder to predict. What looks like one request can involve dozens of steps, multiple models, and external tools. Traditional usage meters weren’t designed to explain that complexity.

The challenge isn’t simply to expose more information. It’s to help people understand what they’re spending, why costs vary, and which choices are within their control.

Across the examples we’ve explored, one principle stands out: cost should be visible when it matters, without becoming something users have to think about constantly.

Good cost transparency isn’t about making every charge predictable. It’s about making uncertainty understandable, so people can make informed decisions without needing to understand the system underneath.

This essay was originally published on my Substack Syntax Stream, where I write about principles of human–AI interaction.

How to design transparent AI cost controls was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.