Context window load

How the calculation works

The window splits into three parts. The permanent payload — the instructions and the documents that ride along with every request. The headroom for the reply — the space the model writes into. What is left is the conversation's memory.

Words are converted into tokens at a coefficient of 2.2 for Cyrillic. The benchmark comes from provider pricing: a Russian word is split more finely than an English one. A page is counted at 1,800 characters — about 250 words, roughly 550 tokens.

The free remainder is divided by the weight of one message pair. That gives the number of exchanges that fit on top of the payload. Beyond that, eviction begins: early messages leave the window, and the bot answers from what remains.

What takes up the window the most

Documents. Forty pages of policy is on the order of 22,000 tokens in every request, and they sit there permanently, whatever the conversation is about. Two hundred pages take up half of a standard window before the first "hello".

The instructions weigh less than they seem to. Fifteen hundred words of rules is about 3,300 tokens, a fraction of a percent of the window. Writing the rules out in detail is cheap, whereas keeping the entire price list alongside is expensive both in space and on the token bill.

Message length matters no less than volume. A dialogue of short 80-word messages lives four times longer than a 300-word request walkthrough. That is why the length of a question–answer pair is measured on the actual chat log rather than guessed at.

When the memory is enough

A conversation fits into the window in full when the permanent payload takes up less than a quarter. That kind of margin absorbs the shock: the customer came back a week later, the exchange continued, the history stayed in place.

The second condition is that reference documents are served on demand. Search pulls the two or three pages that are needed instead of the whole policy, and the window frees up for the dialogue. Order of magnitude: the payload shrinks tenfold or more.

The third is that a long history has a summary. Every twenty or thirty messages, the past is rolled into a compact digest: what the customer asked for, what was agreed, what the restrictions are. The digest weighs hundreds of tokens instead of tens of thousands.

How to tell that forgetting has started

The symptoms are recognisable. The bot asks again about something already stated. It refers to agreements imprecisely. It changes tone and format mid-conversation — that is part of the instructions leaving the window.

The check goes like this: at the end of a long exchange, a question is asked about a fact from the first messages. A miss means the window is full. The measurement is repeated on three to five real dialogues of different lengths — a single case proves nothing.

Logs give a figure more precise than any impression. The provider returns the number of input tokens for each request; a chart of that number over the course of a conversation shows where the curve hits the ceiling of the window.

When the calculation is unnecessary

One-off tasks with no history. Classifying an email, extracting fields from an invoice, answering a standard question — the conversation ends in a single exchange there, and there is nothing to evict.

The calculation is also unnecessary where memory is kept outside: the dialogue lives in a database, and only the current question with the retrieved fragments goes to the model. The window stops being the constraint, and the question moves to the quality of the search.

What to do with the result

The figure from the calculator is the boundary at which work on memory begins. When even a single conversation does not fit in full, the choice is between compressing the payload and a model with a wider window; the former is usually cheaper.

A good next step is to calculate the token bill at the chosen window size. The full window is paid for on every request, so memory and money are governed by the same dial.