Credits, Tokens, Tasks, and Why Naming Matters

Research spine

This chapter is grounded in OpenAI API pricing, Anthropic prompt caching documentation, and Stanford HAI, 2025 AI Index Report.

Pricing software that thinks starts by pricing units of resolved work against variable inference, review, and risk cost.

There is a design review I sit in on more than any other in AI pricing, and it is always about one word. The team has decided on roughly what to charge. Now they are arguing about what to call the thing the customer buys. Tokens? Credits? Tasks? Actions? Compute units? Someone usually wants credits, because credits feel flexible and let you change the underlying economics later without changing the price. Someone usually wants tokens, because tokens are "what we actually pay for." Almost nobody, at first, wants to name the work, which is the only answer that consistently survives contact with customers.

The unit name is not cosmetics. It is a pricing decision with consequences for predictability, trust, and how much pricing power you quietly hand to or take from the customer. This chapter is about choosing the word.

The abstraction ladder

Every AI pricing unit sits somewhere on a ladder from raw cost to recognized work. Higher on the ladder means closer to what the customer values and understands; lower means closer to what you pay.

1. Tokens. The raw cost unit. Maximally honest about your cost, maximally meaningless to the customer. A general counsel does not think in tokens, a support manager does not think in tokens, and a CFO cannot budget in tokens.
2. Compute units / API calls. Slightly abstracted but still infrastructure-facing. Better for developer audiences who genuinely think this way.
3. Credits. A synthetic currency you define, that converts to underlying actions at a rate you control. Maximally flexible for the vendor, maximally opaque for the customer.
4. Tasks / actions. Generic units of activity: "an action," "a task," "a run." Better than credits because at least the customer can count them, but still vendor-defined and often fuzzy at the edges.
5. Work units. The recognizable business work from the work-unit chapter: reviewed contracts, resolved tickets, reconciled invoices. Maximally legible to the customer, maximally aligned with value.

The instinct of most teams is to live in the middle of the ladder, at credits or tasks, because it feels like the safe compromise: flexible enough to change later, abstracted enough to hide the messy economics. The middle of the ladder is where trust goes to erode.

Why credits are a trap

Credits are seductive for one reason: they decouple the price the customer sees from the cost you incur, which lets you change the underlying economics without a visible price change. A customer buys "10,000 credits." A research run costs 50 credits today. If your costs rise, you quietly make a research run cost 70 credits, and the customer's same purchase now buys fewer runs. The price per credit never changed, so it does not feel like a price increase, even though it is one.

That is exactly why credits erode trust. The customer eventually notices that their credits buy less than they used to, and they feel, correctly, that they were manipulated. The flexibility you valued is the flexibility to raise prices invisibly, and customers who detect invisible price increases do not just complain; they leave, and they tell other buyers. Credit systems also create a second friction: customers hoard, customers forget how much a thing costs in credits, customers cannot map credits back to value, and every interaction with the bill requires translation. Each translation is a place where the customer's confidence in the fairness of your pricing leaks out.

There is a narrow, honest use of credits: as an internal accounting layer beneath a customer-facing work-unit price, where the customer never has to think in credits at all. If credits are how you meter and the customer buys "reviewed contracts," fine. The trap is making the customer transact in credits. The moment the customer has to do the conversion, you have put an opaque currency between them and the value, and opacity is the opposite of the trust you are trying to build.

Why tokens fail too, in the other direction

If credits fail by being too opaque, billing customers in tokens fails by being too transparent about the wrong thing. Tokens are your cost unit, not the customer's value unit, and exposing them has three problems.

First, tokens are unpredictable for the customer. Nobody can forecast how many tokens a month of work will consume, so token billing produces the bill-shock problem in its purest form. The customer cannot budget, and the finance team hates you.

Second, tokens make the customer pay for your inefficiency. As covered in the usage chapter, if your prompt is bloated or your agent makes redundant calls, the token count rises and the customer pays for engineering decisions they cannot see or control. A competitor who prices the work unit looks more aligned even at a higher margin.

Third, tokens leak your cost structure. Billing in tokens at a markup tells a sophisticated customer exactly what your underlying model cost is and what margin you are taking, which becomes a negotiation weapon. The transparency chapter argues you should explain price without exposing the cost stack; token billing exposes the cost stack by construction.

Tokens are the right unit in exactly one place: a raw API or infrastructure product whose customers are developers who genuinely think in tokens and want the cost transparency to optimize against. For everyone selling work, tokens are too low on the ladder.

The naming test

Here is a simple test for whether your unit name is right. Ask:

When the customer's boss asks "what did we get for this money," can the customer answer with the unit name without translating it?

"We reviewed 43 contracts." Passes. The unit is the answer. "We used 14,000 credits." Fails. The boss asks "and what is a credit," and now the customer is defending your pricing abstraction instead of celebrating the value. "We consumed 14 million tokens." Fails harder. The unit name should be the thing the customer brags about, not the thing they have to explain away.

This is why the work unit, the top of the ladder, is almost always the right place to name the thing the customer buys. It is the only rung where the unit name is also the value story. Every rung below it requires the customer to translate, and every translation is a tax on trust.

When you genuinely cannot use a clean work unit

Sometimes the work is too heterogeneous for a single clean work unit, the case the copilot chapter handles in depth. A general assistant does a hundred different kinds of small task and no single noun captures them. Here you are pushed down the ladder toward "tasks" or "actions" out of necessity. If you must, follow three rules to keep the abstraction honest:

1. Make the action countable and visible. The customer should be able to see, in the product, how many actions they have used and have left, in real time. A meter the customer cannot watch is a bill waiting to shock them.
2. Keep the conversion stable, or change it loudly. If an action's underlying cost changes, do not silently re-rate it. Either hold the conversion fixed and absorb cost changes yourself, or change it with clear, advance communication. Silent re-rating is the credit trap wearing a different word.
3. Define the action so the customer can predict it. "One action" should map to something the customer can anticipate, not a vendor-internal event that fires unpredictably. If a single user request triggers seven "actions" under the hood, the customer cannot forecast their bill, and you are back to token-style unpredictability with extra steps.

These rules turn "tasks" from a credit-style trap into an honest-enough proxy. They do not make it as good as a work unit, but when the work genuinely resists a single unit, an honestly-metered, stably-priced, customer-visible action is a defensible second choice.

A naming worksheet

Run your candidate unit name through this before you ship it:

Question	Tokens	Credits	Tasks (done well)	Work unit
Can the customer count it?	No	Sort of	Yes	Yes
Can the customer forecast it?	No	No	Maybe	Yes
Is it the value story?	No	No	No	Yes
Can you raise price invisibly with it?	Hard	Easy (the trap)	Possible	No
Does it leak your cost structure?	Yes	No	No	No
Right audience	Developers	Almost none	Heterogeneous work	Most products

The column you want to live in is the rightmost one. The column most teams drift into is credits, precisely because of the row that should scare them: "can you raise price invisibly." That row is not a feature. It is the mechanism by which credit pricing destroys trust over time.

The deeper principle

Naming the unit is really about where you put the abstraction boundary between price and cost. Put it too low, at tokens, and you expose your cost structure and inflict bill shock. Put it too high and opaque, at credits, and you hide so much that the customer cannot tell whether they are being treated fairly, which they eventually punish. The right boundary is the work unit, because it is the one place where the customer's mental model and your value story coincide, and where the abstraction is honest: the customer pays for a thing that is real to them, and the price moves with the value they receive.

Pricing psychology research on fairness and predictability backs this up consistently: customers tolerate prices they can predict and understand far better than prices that are technically lower but opaque or volatile. The unit name is the front line of that perception. A customer who buys reviewed contracts at a clear price feels fairly treated even when the price is high. A customer who buys credits at an unclear conversion feels cheated even when the effective price is low. Same economics, opposite trust, and trust is what survives the renewal.

Practical exercise

Write down the unit you currently bill, or plan to bill, and run it through the naming test: can the customer answer "what did we get" with that word, untranslated? If not, find the work unit it should map to and consider whether you can move the customer-facing name up the ladder while keeping whatever metering you need underneath. The internal plumbing can stay as complex as it needs to be. The word the customer transacts in should be the word the customer already uses.

Key Takeaways

• The unit name is a pricing decision: it sits on a ladder from tokens (your cost) to work units (the customer's value), and the rung you choose shapes predictability and trust.
• Credits are a trap because they let you raise prices invisibly by re-rating the conversion, which customers eventually detect and punish; use them only as internal plumbing, never as the customer's transaction unit.
• Tokens fail in the other direction: unpredictable for the customer, they make customers pay for your inefficiency, and they leak your cost structure.
• The naming test: the customer should be able to answer "what did we get" using the unit name without translating it; only the work unit reliably passes.
• When work is too heterogeneous for a clean work unit, "tasks" can work if they are countable, visible, stably priced, and forecastable.
• Customers tolerate predictable, understandable prices far better than lower but opaque ones; the unit name is the front line of perceived fairness.