Will the Knowledge Base Fit in the Model's Window
Six numbers — and it becomes clear how many knowledge base pages fit into one request, how much stays outside the window, and which way of fitting in costs less per month.
Your numbers
Only what the bot needs to see for this task. A ten-year archive does not belong here.
How many previous messages are inserted into every new request.
All users' queries combined, on a working day.
The share of the window's free part that documents and history will take up. Anything above 100% will not make it into the request — truncation starts with the oldest chunk.
The whole base will not fit into one request, so only relevant chunks are placed into the context — search picks them for the specific question. The difference in the bill is visible in the breakdown: the payment covers thousands of tokens instead of hundreds of thousands.
- Knowledge base, tokens
- 300 000
- Dialogue history, tokens
- 3 072
- Free for data, tokens
- 176 000
- Pages that fit at once
- 230
- Left outside the window
- 127 072
- Full context per month
- 500 000 RUB
- Fragment retrieval per month
- 27 000 RUB
- Difference per month
- 473 000 RUB
The calculation gives an order of magnitude. The exact token volume depends on the specific model's tokenizer and on the formatting of your files — that is measured by the provider's token counter on real documents.
How the calculation works
It all comes down to a single comparison. On the left is the volume that needs to go into the request: documents plus conversation history. On the right is the model's window minus what the window is obliged to hold even without documents.
An A4 page of dense text is roughly 1,800 characters. Russian text tokenizes at an average of 2.4 characters per token, hence 750 tokens per page of policy text. The coefficient can be checked in a minute: twenty typical pages are run through the provider's token counter and the total is divided by twenty.
The dialogue is counted as a separate line. A 160-word turn is about 256 tokens, and the entire saved history goes into every new request in full. Twelve turns add three thousand tokens to the request.
What occupies the window before the documents
Two items are always subtracted. The first is the system instructions and the descriptions of the tools the bot calls: 4,000 tokens in this calculation, and in a setup with a dozen integrations it can be twice that. The second is the reserve for the answer itself, 10% of the window.
What remains is the actual working space for data. For a 200-thousand window that is 176 thousand tokens. Fill is calculated from this number, not from the model's spec-sheet figure.
What affects the result most
The size of the base has a linear and predictable effect. Twice as many pages means twice as many tokens, and the overflow threshold arrives exactly twice as fast.
Dialogue history behaves differently. Every new turn lengthens the request, and that lengthening is paid for on every subsequent query. A long conversation grows expensive faster than it grows useful — which is why the compaction threshold is set in advance.
Document type produces a spread of one and a half times. Spreadsheets and call transcripts take about 1,000 tokens per page: they are full of numbers, names, and fragmentary phrases that the tokenizer splits finely. Correspondence fits into 600.
Three ways to fit
Compaction collapses the older part of the dialogue into a short summary. The documents stay in the request in full. The method works when the base fits into the window and overflow is created only by the length of the conversation.
Fragment retrieval picks several chunks of the base for each question — the calculation assumes 6,000 tokens of selected text. The request becomes tens of times shorter, and document search is added as a separate service. This is the only way to work with a base that is several times larger than the window.
A long window removes the limit with money. A million-token model will accept a thousand-page base, but full context is paid for in every request. At three hundred queries a day, the difference from the fragment retrieval line is measured in hundreds of thousands of rubles per month.
When full context pays off
There are three conditions, and they are needed together. The base is stable and small — up to a hundred and fifty or two hundred pages. Queries are few, dozens a day. The task requires seeing the document as a whole: comparing contract versions, finding contradictions between policies, reviewing a long transcript.
Under those conditions full context wins both on money and on answer quality. Nothing needs to be searched for, so there is nothing to miss the right paragraph with. Caching the stable part of the request lowers the bill further.
As soon as queries become a daily routine, the picture flips. A thousand requests with the full base inside cost more than search, the index, and its maintenance combined.
How to check the numbers on your own data
The measurement takes half an hour. Twenty pages typical of the base are taken and run through the token counter of the model that is expected to be used. The resulting per-page number is entered in the "What kind of documents" field, instead of the default coefficient.
The second measurement covers dialogues. Fifty queries are taken from support logs, and the average turn length in words and the conversation depth up to resolving the issue are calculated. These two numbers usually diverge from an executive's intuitive estimate by a factor of one and a half to two.
The third step is an honest page count. The knowledge base often ends up holding the entire corporate drive, even though the bot needs ten policies and a price list. Selecting by the principle of "what is actually quoted in answers to the client" cuts the volume several times over and shifts the verdict one step down.
What stays outside the calculation
The quality of the documents themselves. Contradicting versions of a policy produce contradictory answers regardless of whether they fit into the window or were picked by search. Putting the files in order often turns out to be a bigger job than the token bill.
Response speed is not accounted for either. A 300-thousand-token request takes noticeably longer to process than a short one, and in a support chat that delay is palpable. When users are waiting for an answer in real time, short context wins here too.
FAQ
How many pages fit into a 200-thousand-token window?
About 230 pages of dense policy text with a short dialogue history. The math is this: from 200,000 subtract the reserve for the answer (10%) and the system instructions with tool descriptions (about 4,000 tokens), then divide the remainder by 750 tokens per page. For emails the page count comes out higher, for spreadsheets lower.
What happens when the context overflows?
The oldest content is truncated — usually the beginning of the dialogue and the first inserted documents. The model does not report this and keeps answering in a confident tone, relying on what is left. That is why overflow is caught with a token counter before the request is sent.
Compaction or fragment search?
Compaction collapses the conversation history and suits cases where the base fits into the window and only the dialogue grows. Fragment retrieval is needed when the documents on their own are larger than the window. They often work together: fragments are picked for the question, and history is collapsed once the threshold is reached.
Can a model with a million-token window settle the issue?
It removes the limit but leaves the bill. Full context is paid for in every request, and at 300 queries a day the cost grows tens of times over compared with fragment retrieval — the difference is visible in the breakdown. A long window pays off on rare tasks where a document is read in full: reviewing a contract, comparing versions.
Where does the token price come from?
The calculation assumes 250 RUB per million input tokens — a benchmark based on mid-tier model rates converted into rubles — and 22 working days per month. Output tokens and request caching are not counted: a cache on the stable part of the context lowers the bill, while the answer's volume is almost invisible next to the volume of the base.
Are one-off works included?
One-off preparation is not part of the calculation. For fragment search that means parsing files, chunking, and indexing; for full context, cleaning documents of duplicates and outdated versions. The scope of this work is estimated from the state of the files, and the 12,000 RUB in the fragment retrieval line is the monthly operation of the index.
Check it on your case?
We will look at your process and give numbers for it, not for averages.
Related tools
Updated: August 25, 2026