Tokens, explained for finance: input, output, cached, and what you pay for

Every AI invoice is denominated in tokens, and most of the people who have to approve those invoices have never been told what one is. This is the explanation, in the order a finance leader needs it: what a token is, why there are several kinds, what each kind costs relative to the others, and what that means for reading a bill.

What a token is

A token is a piece of text, roughly three quarters of a word in English. The model reads text as tokens and writes text as tokens, and the provider counts both. A thousand tokens is about seven hundred and fifty words, or a couple of pages.

That is the whole unit. Everything else is about which tokens, going which direction.

The kinds

A request to a model has text going in and text coming out. Providers price these differently, and they price some kinds of "in" differently from others.

Input tokens are what the model reads: the prompt, the instructions, any documents attached, and the conversation so far. In a long conversation the whole history is sent again with every turn, so input grows as a conversation goes on.

Output tokens are what the model writes: the answer. Output costs several times more per token than input, typically three to five times, because generating text is more expensive than reading it.

Cached input tokens are input the model has seen recently and stored, so it does not have to process it again. Providers charge a fraction of the input price for a cache read, usually around a tenth. This is where a well-built application saves money: the long system prompt and the shared documents are cached, and only the new part of each request is charged at full price.

Cache write tokens are the cost of putting something into that cache in the first place, priced a little above normal input. Anthropic distinguishes two cache durations with two prices.

Reasoning tokens are, on some models, output the model produces while thinking before it answers. They are billed as output whether or not you see them.

So a typical bill line for one model is really four or five lines: uncached input, cached input, cache writes, output, sometimes at more than one service tier. The provider's cost reports keep them apart because the prices differ, and any allocation across people has to keep them apart too.

Why it matters for the number

Three consequences follow, and each of them shows up on the invoice.

The same task can cost very different amounts depending on how it is built. An application that resends a hundred-page document with every question pays full input price a hundred times. One that caches it pays once, then a tenth each time. The engineers know this; finance usually does not, and it is the single biggest lever on API spend.

Output-heavy work is expensive work. Drafting, coding and long-form generation produce a lot of output tokens. Classification and extraction produce few. A team whose usage is mostly output will cost more per request than one whose usage is mostly input, at the same request count.

Models differ by an order of magnitude. Providers offer a range of models at very different per-token prices. The same tokens through a frontier model and a small model can differ by ten times or more. Model mix is the second biggest lever, and a spend breakdown that does not show the model is missing it.

Service tiers and batch

Both major providers offer ways to pay less for the same tokens in exchange for something.

Batch processing runs requests asynchronously, typically within a day, for about half the price. Work that does not need an immediate answer, like overnight document processing, belongs there.

Priority tiers cost more for guaranteed capacity. Work that does need an immediate answer, in production, in front of a customer, may belong there.

On a cost report these appear as a service tier on the line, and they are worth keeping visible, because "why did this team's cost per token change" is often "they moved to batch" or "they moved off it".

Reading a bill

With the kinds in mind, a token-based cost report reads as follows.

• Look at the split between input and output first. A high output share means generative work; a high cached-input share means a well-built application; a high uncached-input share with a long conversation product means there may be caching to add.
• Look at the model mix second. If most of the dollars are on the most expensive model, ask whether all of that work needs it.
• Look at tier third. Batch-eligible work not on batch is the easy saving.
• Then look at who, which the bill will not tell you and the usage report will, by key.

Seats are different

Enterprise seat products, Claude Enterprise and ChatGPT Enterprise, report usage per person, and some of them meter in credits rather than tokens, with a credit worth a set amount of usage and an overage price in dollars. The provider does the token arithmetic and reports the result per user. The kinds still exist underneath, and some reports still show them, but the finance-relevant unit is the credit or the dollar per person, and the same three levers apply: how the work is built, which model, and how much of it is generation.

The one-sentence version

You pay for text read and text written, written costs more, cached reading costs much less, the model chosen multiplies everything, and the bill will not tell you who did the reading and writing.

Arbitir stores every usage row with its token kinds kept apart, allocates each day's cost to keys per token kind so a cache-heavy key and an output-heavy key are priced correctly, and shows spend by model and by tier as well as by person.