Monthly Inference Bill

How the calculation works

The provider bills for tokens. A token is a chunk of text of roughly 2.5 characters of Russian writing; the calculation converts characters at that rate. Everything the model reads is paid for, and everything it writes as well.

The starting point is the dialogue as a whole. The number of interactions per day is usually known to a manager: requests, emails, chat questions. Inside one interaction a person writes several turns in a row.

Then comes the place where intuition fails. Every turn goes to the model together with the entire history: the model has no memory between calls, so the conversation is resent each time. With five turns the total input equals fifteen turns — 5 × 6 / 2. That is exactly the formula used in the calculation.

A constant load is added to every request: the instruction, the processing rules, excerpts from the knowledge base. It is set as a coefficient on input tokens. A short instruction is 1.4; an instruction with document fragments is 2.6; whole documents are 4.5. The spread between the extreme options is threefold.

Answers are counted separately, and their length is taken as 1.6 of the human turn length. The sum of input and output is multiplied by the number of dialogues and by 30.4 days. On top of that, 12% is added for retries, follow-up questions, and service calls — request classification, answer checking, attempts after a failure. The result is rounded to the nearest thousand rubles.

What moves the bill the most

Dialogue length. Growth here is quadratic, and the turns slider shifts the result more noticeably than the others. Moving from five turns to ten raises input tokens 3.7 times with the same number of interactions.

The volume of attached context. The relationship is linear, but the range is wide. Between a short instruction and full documents the difference is more than threefold.

Model class. Between the compact and the flagship rate the calculation has a twentyfold gap. The model is chosen for the task: sorting emails and extracting fields is handled by a compact one, parsing a contract by a senior one.

The number of dialogues acts linearly and predictably. It sets the scale but does not affect the price of a single interaction.

What to look at in the breakdown

The "Price of one dialogue" line converts the bill into an understandable unit. It gets compared with the cost of the same dialogue handled by a person — minutes of operator work are counted by the same logic as in the budget calculator.

The "Share of context" line shows where the money goes. At default values about 80% of tokens are re-read history and attached documents. Model answers take up the remaining fifth.

When the share of context passes 85%, savings should be looked for in how the request is prepared. There is almost nothing left to squeeze out of the answers.

Under what conditions the bill stays predictable

History gets trimmed to the last few turns, and the older part is replaced with a short summary. The dialogue stops getting more expensive toward the end.

The unchanging part of the prompt is handed to the provider's cache. Repeat reads are billed at a lower rate, and the shared instruction stops being paid for at the full rate on every call.

Fragments found by search go into the request. One precise paragraph from a policy document works better than the whole file and costs tens of times less.

Requests are routed by complexity. Routine questions go to a compact model, contentious ones to a senior one. On a stream of uniform tasks such a fork removes half the bill.

A token limit is set per dialogue. It turns open-ended spending into a ceiling that is visible in advance.

When a rough estimate is enough

A pilot handling a few dozen interactions per day fits into a sum comparable to a couple of hours of development. A detailed calculation decides nothing there: it is worth doing after reaching steady volume.

The conversation about money becomes concrete from a few hundred dialogues a day. From that volume the inference bill starts showing up in reports and responding to system settings.

The number obtained is an order-of-magnitude reference point. The precise figure appears after a measurement on real interactions: a week of logs shows the true dialogue length and context volume better than any estimate.