What Is a Token in AI Pricing? How Tokens Are Priced, Billed, and Recognized as Revenue

Every AI feature — whether it's a per-seat SaaS product with an AI add-on or a pure usage-based API offering — eventually reduces to the same unit: the token. Finance and product teams pricing these features rarely need to understand how a tokenizer works internally, but they do need to understand what a token actually is, how model providers price one, what has to happen between a customer's AI interaction and a line on an invoice, and — the step most pricing discussions stop short of — what has to happen after that invoice for the company to actually recognize the revenue it represents.

This article covers all of that ground. It's the definitional layer underneath any AI pricing strategy. Before you can decide how to price an AI feature, you need to know exactly what you're pricing, how it turns into a bill, and how that bill turns into revenue you can put on a financial statement.

What is a token in AI pricing?

A token is the basic unit a language model reads and generates text in, and it's also the unit nearly every AI provider uses to price usage. A token can be a whole word, part of a word, a single character, or a punctuation mark — depending on how the model's tokenizer breaks up the text.

That last part matters more than it sounds. Tokens aren't words, and pricing by the token isn't the same as pricing by the word or character, even though it's related to both. OpenAI's documentation puts the rough conversion at one token per four characters of English text, or about three-quarters of a word, so 100 tokens works out to roughly 75 words. That ratio shifts by language, by model, and even by formatting choices like spacing and capitalization.

This is exactly why a token — not a word or a character — is the unit providers settled on: it's the unit the model itself actually operates in.

For billing purposes, a token is the smallest thing you can attach a price to. Everything else — a chat response, a summarization job, an agent workflow — is a bundle of some number of tokens going in and some number coming out.

How are tokens actually counted?

Tokens are counted by running text through the same tokenizer the model uses internally. That tokenizer splits both the text a customer sends in and the text the model generates back into discrete units, counted separately as input tokens and output tokens.

Several things about that counting process matter for anyone pricing, billing, or recognizing revenue against it:

• Input and output are counted and priced separately. The prompt, system instructions, and any retrieved context all count as input tokens. The model's response counts as output tokens. A single customer interaction produces both.
• Word count is not token count. A technical term, a compound word, or text in a language other than English can tokenize very differently than plain English prose. Estimating cost from word count alone tends to be wrong in ways that only surface at volume.
• Tokenization differs across model generations. This is the subtler risk. Moving from an older model to a newer generation can produce meaningfully different token counts for identical input text — recent Anthropic models, for instance, tokenize the same text into roughly 30% more tokens than earlier generations. A cost model built on token counts from one model generation will be wrong when applied to another, even within the same provider's lineup.
• Context accumulates in multi-turn workflows. In a multi-turn conversation or an agentic workflow, earlier messages and tool definitions are often resent as input on each new step, so token counts climb well beyond what a single visible exchange suggests.
• Reused input is often priced differently. Providers discount tokens that repeat from an earlier request, since the model can reuse prior computation instead of processing them from scratch. The mechanics of this vary enough between providers that it warrants its own section below.

None of this requires a finance team to understand tokenizer internals. It does mean any cost model built on "roughly how many words" — or even on token counts from a prior model version — is working from the wrong unit.

How do you price a token?

You price a token by starting from what the model provider charges per token, then layering on whatever markup and packaging your pricing model requires — keeping input and output priced separately, since providers do the same upstream.

Provider list prices are published per million tokens, since a single token costs a fraction of a cent. To make the structure concrete: Anthropic's current pricing lists Claude Sonnet 5 at $2 per million input tokens and $10 per million output tokens, and Claude Opus 5 at $5 per million input tokens and $25 per million output tokens. OpenAI's pricing follows the same per-million-token structure across its own model tiers, with output priced at a multiple of input on every model.

The specific numbers change as providers update pricing — Sonnet 5's rates were initially announced as introductory, for example, before being made permanent — so any cost model that bakes in today's exact figures without a mechanism for updating them will drift. The structural pattern (tiered models, fixed price per million tokens, input and output priced separately) has held steady across providers even as the specific rates shift.

The number that matters for your own pricing isn't the list price alone. It's the fully loaded cost per token: list price plus the cost of retries, any retrieval or context-management overhead your product adds, any caching write premiums (see below), and which specific model or model version actually served the request. Routing logic that shifts requests between models changes your real cost even when your customer-facing feature looks identical.

Why are input and output tokens priced differently?

Input and output tokens are priced differently because generating text costs meaningfully more computationally than reading it.

Processing input tokens is largely a parallelizable read: the model can examine the whole prompt at once. Generating output tokens happens one token at a time, each depending on everything generated before it — a fundamentally more serial and expensive computation. Across both major providers, output tokens are priced at five times the rate of input tokens for equivalent models. Claude Sonnet 5 at $2/$10 per million and Claude Opus 5 at $5/$25 per million both reflect exactly that 5x ratio; OpenAI's model tiers follow similar patterns, with exact ratios varying by model.

For anyone pricing an AI feature, this asymmetry is a direct signal about where cost actually concentrates. A feature that generates long responses from short prompts — a report generator, a long-form writing assistant — carries a very different cost profile than one that processes long documents into short summaries, even if both look like "one AI feature" from a product perspective.

How does prompt caching work, and what does it actually cost?

Prompt caching is the single highest-leverage cost mechanism in AI token pricing, and it's also the most widely misunderstood. The headline number — a steep discount on cached input tokens — is real, but it comes with a structure that affects how you account for it.

What caching does. When a model call reuses input tokens that appeared in a recent prior request (a system prompt, tool definitions, a large document), the provider can reuse prior computation instead of re-processing those tokens. The tokens are billed at a discounted rate rather than the full input rate.

The read discount. Anthropic prices cache reads at 10% of the standard input rate — a 90% discount. For Claude Sonnet 5, that means cached input runs at $0.20 per million tokens instead of $2.00. OpenAI's discount structure varies by model tier; for older models, the discount was 50% off standard input, while newer GPT-5.x models have moved to a comparable 90% discount. Neither provider's cache discount applies universally across their entire model lineup, so always confirm the rate for the specific model you're using.

The write premium. This is where a lot of cost analyses go wrong. On Anthropic, writing tokens into the cache costs 1.25x the standard input rate. Cache writes aren't free — you pay a premium to store context so that subsequent reads come back cheaper. Whether caching saves money on net depends on your cache hit rate and how large the cached context is. For a large, stable system prompt that's reused on thousands of requests, the math is strongly favorable. For a low-hit-rate or volatile context, the write premium can offset the read savings.

How caching is triggered. Anthropic requires an explicit cache_control: ephemeral marker at defined breakpoints in the prompt. OpenAI applies caching automatically above a token threshold (a stable prefix of at least 1,024 tokens) with no explicit configuration required. The Anthropic model gives more control; the OpenAI model requires less setup.

For any application with a large, stable system prompt or tool definitions, caching is worth modeling carefully — not just as a discount, but as a pricing mechanism with both a cost and a benefit side.

How does token consumption become recognized revenue?

Turning a token into recognized revenue takes four distinct steps: metering the raw counts, rating them into a dollar amount, billing that amount to the customer, and recognizing the appropriate portion of it as revenue in the correct accounting period. Each step depends on the one before it, and each is governed by different rules.

Metering captures the raw count. Every model call should log input tokens, output tokens, whether a cache hit occurred, the model and version used, and which feature or workflow triggered it. Skipping any of these makes the later steps unreliable. A token's cost depends on which model served it and whether it was a cache read — so records without that context can't be rated accurately.

Rating applies the price. This is where list cost, any markup, bundled allotments, and overage logic all come together to turn a token count into a dollar amount. Rating needs to be current: if provider pricing changes or your model mix shifts, the rating logic has to update, or your margin calculations will drift silently.

Billing summarizes and invoices. A customer doesn't need, and a financial system of record shouldn't receive, millions of individual token-level line items. What reaches an invoice is a rated, summarized charge: this customer, this feature, this period, this amount.

Recognition determines what's actually earned. Under ASC 606, revenue is recognized as the performance obligation is satisfied — for token consumption, that generally means as tokens are actually used, not when they're billed or paid for. A customer who prepays for a block of tokens has been billed and has paid, but the revenue is earned only as those tokens are consumed over the following weeks or months. Tokens purchased but never used — breakage — have their own recognition treatment. Mid-period plan changes, tiered volume discounts applied retroactively, and true-ups against committed minimums all require re-estimating variable consideration, sometimes after the period they relate to has already closed.

This is the step most token pricing conversations stop short of, and it's usually the most operationally demanding one. Metering, rating, and billing can all be automated against a rate card. Recognition requires reconciling what was billed against what was actually consumed, on a schedule that often doesn't match the billing schedule at all — a customer billed monthly for a prepaid annual token pool is generating revenue recognition entries on a completely different cadence than their invoices.

Skipping straight from raw token counts to an invoice — without a metering and rating layer in between — is how teams end up rebuilding reconciliation by hand each billing cycle. Skipping from invoice to recognized revenue without a clear consumption record is how that same reconciliation problem shows up again at close, this time in front of an auditor.

What does a clean token billing record need to contain?

A clean token billing record needs enough detail to reconstruct exactly what happened, why it cost what it did, and when the underlying obligation was actually satisfied. At minimum, that means:

• Model and version. The same feature can route across multiple models, and each carries its own price. A record without model attribution can't be rated accurately.
• Input and output token counts, kept separate. They're priced at different rates; blending them produces a number that's impossible to audit or reconcile.
• Cache status. Whether a request was a cache hit, a cache write, or neither changes the per-token cost materially. A billing record that doesn't capture this will systematically misstate cost.
• Feature or workflow attribution. This is what lets a product or finance team see which feature is driving cost, not just that aggregate cost went up.
• Consumption timestamp, separate from the billing period it's summarized into. This is the field that makes revenue recognition possible after the fact. A record that only carries "which invoice this rolled up into" can't answer when the obligation was actually satisfied — which is the question recognition timing depends on.

Each of these has a direct operational reason for being on the record. Teams that discover they need one of these fields after the fact typically find they can't reconstruct it retroactively — the event data is gone, and neither the rated charge nor the recognized revenue entry can be corrected without it.

Key takeaways

A token is the unit both the model and the bill are built on. Treating it as a rough stand-in for word count is where a lot of AI pricing goes wrong — and treating token counts as portable across model generations is a subtler but equally common error.

Input and output tokens are counted and priced separately, with output typically running at five times the input rate for equivalent models. Prompt caching introduces both a read discount (up to 90% off input pricing) and a write premium (1.25x input pricing on Anthropic), so it has to be modeled as a two-sided mechanism, not just a savings lever.

Turning any of this into an accurate invoice takes three distinct steps: metering the raw counts with enough attribution to rate them correctly, applying current pricing to produce a dollar amount, and summarizing rated usage into a clean charge downstream. But the invoice isn't the finish line. A fourth step — recognizing the appropriate revenue in the correct period, against the correct performance obligation — is where token-based pricing tends to create the most work, because consumption timing and billing timing rarely line up. Get the unit right at the start, and every decision built on top of it, all the way through to recognized revenue, gets substantially easier to make correctly.