What Is a Token and Why You Pay for It

Why this matters

• Understand exactly what an AI invoice charges for, and how it will grow as volume grows
• Know why processing Russian documents costs more than English ones at the same rate
• Ask a vendor for a price per operation, not just a price for the project

What is a token in plain language

Telegrams used to be paid for by the word. A short word counted as one unit; a long one might count as two. The sender paid per item, so the text was squeezed to the bone: "leaving tuesday meet me."

Language models count the same way. The unit of account is the token, a chunk of text roughly three quarters of an English word. Common words become a single token; rare ones break into pieces — a mouthful like "undercapitalization" turns into five or six fragments.

Hence the point that matters for a budget. The provider charges by the number of fragments the model read and wrote. Pages, documents and requests play no part in the invoice. Rates are quoted per million tokens, separately for input and for output.

How it works

1. The text is cut into tokens. Everything is cut the same way: the user's question, the service instruction, attached documents, earlier turns of the conversation.
2. Input tokens are counted. This is the entire volume sent to the model in a single request. The main cost item hides here: a six-page instruction is sent again with every request.
3. The model writes its answer one token at a time. These are output tokens. On common models they cost three to five times more than input tokens, so a long answer costs appreciably more than a short one.
4. The two are added and multiplied by the rate. Cost of one request = input × input price + output × output price. That figure is then multiplied by monthly volume.
5. The language is checked. Russian text yields more tokens for the same meaning. A page of 1,800 characters runs to about 450 tokens in English and 700–900 in Russian. The exact figure for a given set of documents comes from the token counter of the model in use.

Conversation length deserves separate attention. In a chat the model does not remember the past on its own: the whole message history is resent with every turn. By the twentieth message the input volume has multiplied several times over, and the price of a turn along with it.

A case from practice

An online retailer used a model to handle roughly 12,000 support requests a month. Each request carried a six-page instruction, the product record and the full message history — an average of 9,000 input tokens and 350 output tokens. At mid-tier model rates this worked out to about RUB 2.6 per conversation, around RUB 31,000 a month.

Three things were done: the service instruction was translated into English (4,500 tokens became 2,300), caching was switched on for its fixed part, and the last four turns began to be sent instead of the entire history. Answers to customers stayed in Russian.

Input volume fell to 3,200 tokens per conversation. Caching added a discount: for resending the same instruction, the provider charges a reduced price. The invoice dropped to RUB 14,000 a month — input tokens fell by nearly two thirds, but output tokens stayed the same, so the invoice fell less sharply than the volume. Quality was checked against a single sample of 300 conversations before and after: the share of handoffs to a live agent did not change.

What this gives a business

• The invoice becomes a calculable figure. Cost per operation multiplied by volume gives an annual budget that is worked out before launch rather than discovered after the fact. A rough order of magnitude for a given process can be estimated with the budget calculator.
• Clear levers appear. Shortening the instruction, caching the fixed part, trimming the history, translating the service text into English — four moves that in the example above cut the invoice by more than half without rewriting the system.
• Vendor proposals become genuinely comparable. A price per million tokens says nothing without volume. A price for processing one invoice or handling one support conversation compares directly.
• The risk of runaway costs is removed. A system whose input volume grows with conversation length gets more than twice as expensive when the load doubles. That is visible in advance if the counting is done in tokens.

When this can be skipped

At small volumes there is no point in counting tokens. A few hundred requests a month at the rates in the example above produce an invoice of about a thousand rubles — the time spent optimizing costs more than the entire saving.

Tokens are also beside the point where a subscription with a flat per-user fee has been bought: there the payment covers seats and the constraint is a request limit, while the volume of text does not affect the price. The same goes for a model deployed on a company's own hardware: the spending is on graphics cards and their upkeep, and tokens remain a technical measure with no price tag attached.

What to check carefully

First: every model cuts text into tokens its own way, and the same Russian text may yield 10–20 percent more or fewer. Comparing providers on price per million is therefore misleading — what needs to be worked out is the cost of one typical operation on the actual texts involved.

Second: reasoning models spend tokens on internal deliberation that never appears in the answer but does appear on the invoice. On hard tasks the invisible part can exceed the answer itself. This has to be checked on real requests before launch.

Third: ask the vendor to show the input breakdown for a single operation — how much of it is the instruction, how much the attached documents, how much the message history. Without that breakdown there is no way to verify any promise of cheaper operation, and it is precisely that breakdown that shows what to cut first.