TL;DR: The unit you measure and the unit you bill are not the same unit, and collapsing them is the mistake that makes AI pricing impossible to change later. Meter tokens, because that is your cost. Bill in credits, requests, tasks or outcomes, because that is what the customer understands. Keep a rating step between the two, and you can change price without touching your product code. This page covers all four units — what each one really costs to implement, and where each one breaks.
Every AI company answers the same question in its first year: what do we charge for? The answers cluster into four units, and most teams pick one, wire it straight into the product, and discover eighteen months later that changing it means re-instrumenting every call site.
That is avoidable, and the fix is structural rather than clever.
The four units
| Unit | Customer understands it | Tracks your cost | What it costs to build | Where it breaks |
|---|---|---|---|---|
| Tokens | Rarely | Almost exactly | Several counters per call | Nobody can forecast their bill |
| Requests / calls | Yes | Poorly | A counter | One request can cost you 10,000× another |
| Credits | Yes | As well as you define it | A ledger, not a counter | Expiry, refunds, and negative balances |
| Outcomes | Best of the four | Not at all | A judgement, plus its evidence | Disputes, and revenue recognition |
Tokens: the right measurement unit, the wrong price tag
Tokens are what your provider charges you for, so tokens are what you must measure. That part is not optional — if you are not counting them, you do not know your margin per customer, and margin per customer is the whole business.
Selling in tokens is a different decision, and usually a worse one. A token is cost-based in the crudest possible way: it maps to your supplier's invoice, not to anything the buyer values. Ask a non-technical buyer to estimate their monthly token consumption and you will get a blank look followed by a smaller contract, because unforecastable bills get budgeted defensively.
What token metering actually requires, and where it is usually under-built:
- At least two counters per call. Input and output tokens have different prices — often by a factor of three to five. A single "tokens" meter cannot be re-rated when that ratio changes.
- Cache reads and writes are separate again. Prompt caching quietly adds dimensions: a cached read is cheap, a cache write is not, and folding either into the input count destroys the arithmetic.
- The model is part of the identity. The same token count against two models is two different costs. If the model is not on the event, the event cannot be rated later.
- Tokenizers differ between vendors. The same string is a different number of tokens depending on who counts it, which is why cross-vendor price comparisons per token are misleading.
So: five or six dimensions on every event, all of which you need, and none of which the customer wants on their invoice. This is the strongest possible argument for keeping the measurement unit and the billing unit apart.
Requests: honest simplicity, until it is not
Per-request pricing is the easiest thing to explain and the easiest thing to meter — one counter, no dimensions. For a narrow, uniform API it is genuinely the right answer, and reaching for anything more sophisticated is over-engineering.
It fails when request cost varies. In an agentic product it varies enormously: one call answers from cache, the next runs a twelve-step tool loop with three subagent calls behind it. Charging the same for both means the light users subsidise the heavy ones until the heavy ones arrive in volume and the margin inverts. Per-request pricing is a bet that your cost distribution is narrow. Check whether it actually is before betting the pricing model on it.
Credits: a ledger, not a counter
Credits have become the default packaging for AI products, and for good reason — they let you charge in a unit the customer understands while your cost stays denominated in tokens underneath. You can reprice the exchange rate without repricing the product.
The trap is that teams implement credits as a number that goes down, and a balance is not a counter. A credit system is a ledger, and a ledger has requirements a counter does not:
- Grants have identities. A monthly allowance, a promotional grant and a purchased top-up behave differently. When they merge into one integer, you cannot answer "what expires at month end".
- Drawdown order is a policy. Expiring credits first, or purchased credits first? Whichever you pick, pick it explicitly — the difference is money, and it is visible to the customer.
- Expiry is where disputes come from. Unused credits expiring silently is the single most common complaint about credit pricing. Whatever the policy is, it belongs in the customer's dashboard before it happens, not in the terms afterwards.
- Concurrency will make the balance negative. Ten parallel agent calls against a balance of five will all pass a naive check. Decide whether you reserve, allow the overdraft, or hard-stop — and note that a hard stop mid-task is a worse customer experience than a small overdraft.
- Refunds run backwards. A failed generation that consumed credits needs them back, which means the debit must be reversible and individually addressable. A decremented integer is not.
Every one of those is cheap to build up front and expensive to retrofit, because the retrofit needs history the integer never kept. See prepaid credits: drawdown and expiry for the detail.
Outcomes: the model everyone is moving toward
Outcome pricing charges only when the product delivers a measurable result. It is the best-aligned model on paper — the customer buys the result rather than the machinery — and 2026 is the year it went mainstream in customer support:
- Intercom's Fin charges $0.99 per resolution, billed only when a conversation is resolved end-to-end without a human.
- Zendesk bills per automated resolution at roughly $2 pay-as-you-go, or around $1.50 with a volume commitment.
- Salesforce Agentforce charges $2.00 per conversation — and bills escalations as well as resolutions, which is a materially different definition.
The direction of travel is steep: fewer than one in ten AI vendors offered outcome pricing entering 2026, and Bessemer projects roughly 61% by the end of the year.
The engineering reality is harder than the pitch, in three specific ways.
An outcome is a derived event, not an observed one. Something decided that the conversation was resolved. That decision has a definition, the definition will change, and when it changes every historical number moves with it unless you kept the evidence. Store the underlying events and the rule version that classified them, or you will be unable to explain last quarter.
Disputes are about the definition, not the count. Nobody argues that you counted 4,000 resolutions; they argue that 300 of them were not resolutions. That is a fundamentally different support conversation from a usage dispute, and it requires you to show the transcript behind the charge. Agentforce billing escalations is instructive here — it is a definition chosen to be unambiguous rather than generous.
Revenue recognition gets genuinely complicated. Outcome-based contracts in agentic products are enough of an accounting question that the large firms have published guidance on them. If you are heading this way and you have auditors, involve finance before the pricing page goes live, not after.
And underneath all of it: you still meter tokens, because outcome pricing without cost-per-outcome tracking is a way to lose money at scale with excellent alignment.
The architecture that survives all four
Here is the part that matters more than the unit you choose, because it is what lets you change your mind.
product code emits atomic facts
model, input_tokens, output_tokens, cache_read, request_id
│
metering layer counts them, idempotently, with a documented window
│
rating converts quantity → commercial unit, at the price in force
tokens → credits → invoice line
│
biller charges the card
The product code emits what happened. It does not know the price, the credit exchange rate, or what counts as an outcome. That knowledge lives in the rating step, which is configuration rather than code.
Three consequences, and they are the whole point:
- You can change pricing without a deploy. Moving from per-request to credits, or changing how many credits a GPT-class call costs, becomes a config change instead of a migration through every call site.
- You can bill two ways at once. Enterprise on committed tokens and self-serve on credits, from the same events, because the events are neutral.
- You can answer "why is this number what it is". Given an invoice line, you can walk back to the events. If you cannot do that, you lose the first serious dispute, and it will cost more than the feature would have.
The one rule that makes this work, and the one most often broken: prices must be versioned, never edited in place. The moment someone corrects a unit price by overwriting it, every invoice raised under the old value becomes unreconstructable. Close the old version with an end timestamp, write a new one, and rate each event against whichever price was in force when it happened.
Choosing, in one paragraph
If your costs are uniform and your buyers are developers, charge per request and keep it simple. If your costs vary widely and your buyers are not developers, charge in credits and put real work into the ledger. If you can define an outcome your customer would recognise and your finance team can live with, outcome pricing will win deals the other two will not — but build the evidence trail first. And in all three cases, meter tokens underneath, because that is the only number that tells you whether any of it is profitable.