AI Context Window Explained: Which AI Reads Long Documents Best?

The most quoted number in long-document work is also the one that decides the least: the AI context window. "Reads a million tokens" is sold as a spec, yet the moment you drop a 300-page tender specification on the table you hit three separate limits. The model's theoretical window, the file cap of the app you are using, and how much of that window the model actually uses with any comprehension. Those are three different things, and that difference is what this article is about.

By the end you will have the page equivalent of a context window, why non-English documents cost more tokens than English ones, what long-context benchmarks measure and what they quietly skip, which assistant to pick for which document job, and where the cost line falls between long context and RAG. It deepens the tool-selection section of our guide to AI tools for business for one specific case: the long file.

What is a context window, and how many pages does it hold?

A context window is the amount of text an AI assistant can "see" at once, measured in tokens. Your question, the document you upload, the earlier messages and the model's own reply all have to fit inside the same window. When it fills up, the model either misses part of the document or silently drops the oldest messages. The page equivalent depends heavily on language.

A token is a unit smaller than a word. In English one token is roughly four characters, about three quarters of a word. Other languages pay more. Agglutinative languages, where a single word carries a chain of suffixes, are the extreme case: the word does not exist whole in a tokenizer's vocabulary (the tokenizer is the component that splits text into pieces), so it gets broken into five or six fragments. German compounds, Finnish, Hungarian and Turkish all sit in this territory.

Turkey spotlight: a study by a Turkey-based security firm puts the Turkish token overhead at roughly two times English for the same content. It is a single-source figure, but it matches what we see in our own projects. A practical band for Turkish: 50 pages is about 35-40 thousand tokens, so a 200-thousand-token window takes roughly 250-280 pages and a million-token window clears 1,200 pages. For English documents you can nearly double those page counts. All of it moves with font size, table density and scan quality; image-heavy scanned PDFs cost extra. For a planning estimate, divide your page count by 750 for Turkish or by about 400 for English, and the result is your rough need in thousands of tokens.

Does a million-token window really read a million tokens?

No, not at the advertised capacity. As the input approaches the end of the window, models start missing information, especially in the middle; researchers call this "lost in the middle". The gap between the advertised window and the "effective window" the model handles reliably is the number that matters for long documents. It is also the number no product page prints.

The test the industry shows most often is "needle in a haystack": one unrelated sentence is buried inside a long text and the model is asked to find it. Most current models pass it almost perfectly. The problem is that the test measures finding a sentence, not understanding a document. Locating the penalty clause in a contract is one skill; noticing that it contradicts the force majeure clause 40 pages later is another.

Harder benchmarks were built for exactly that reason. RULER replaces the single needle with look-alike distractor needles, multiple values tied to one key and multi-query retrieval, 13 tasks measured from 4 thousand up to 128 thousand tokens. The authors of BABILong note that it has "already been shown that most long-context models cannot use their full context". Epoch AI's Fiction.LiveBench asks comprehension questions over long narratives and reports that models which ace the needle test struggle noticeably there.

Quoting a single degradation percentage per model would not be honest; these tables shift with every release, and our research did not turn up a reliable per-model number. Keep the rule instead: do not trust the last third of the advertised window.

Why the app's file limit and the model's window are two different numbers

The context window a model offers through its API and the limit the ChatGPT, Claude or Gemini app gives you in the browser are separate figures. Apps impose file size, page count, file count and plan-based window caps, and these usually sit well below the model's theoretical capacity. Your 300-page document may fit the model and still be refused by the app.

As of September 2026, the limits that secondary comparison pages report consistently look like this (check the official help pages before you upload; these numbers change every few months):

• ChatGPT: 512 MB per file; a handful of uploads a day on the free plan, 80 files per three hours on paid plans. The context window itself varies by plan and on the free tier sits far below the model's API window.
• Claude: 20 files per chat, PDFs capped at 32 MB and 100 pages. That means a 300-page specification cannot go in as one piece; you have to split it.
• Gemini: 100 MB per file; 10 files per prompt on the free plan.
• NotebookLM: 500 thousand words or 200 MB per source, whichever fills first, with no page limit. For a single long document this is the widest door. We covered where it breaks in NotebookLM for business.

The practical conclusion: before asking "which model has the bigger window", ask "which app accepts my document without splitting it". The moment you cut a document in two, you also cut the model's ability to cross-reference in two.

Which assistant reads long documents best?

There is no single winner, but there is a clear pattern. Large-window models (Gemini's Pro versions, and the newer Claude and GPT generations that reach a million tokens) lead on deep reading of a single document. In apps that force you to split the file, your splitting strategy decides the outcome more than the model's quality does. Do not decide without measuring; measuring takes 20 minutes.

In our own projects we use a five-question protocol for long-document testing, and we suggest you copy it. Question one asks for a concrete fact that lives in the first 10 pages, question two in the exact middle, question three in the last 10 pages ("what is the guarantee percentage?", "how many days is the delivery term?"). Question four asks the model to connect two distant clauses: "reading the late-delivery penalty together with the force majeure clause, does a storm-related delay trigger the penalty?" Question five is a trap: you ask about something the document does not contain and check whether the model can say "that is not in the document".

What we see in practice: almost every good model passes the first three. The separation starts at questions four and five. On the cross-reference question, models that took the document in one piece are clearly better; with a split document, even the same model can answer wrongly because it never "saw" the clause in the second chunk. On the trap question the difference varies by model family and has to be retested with every release. For the general picture across the big three, see our honest comparison of ChatGPT, Gemini and Claude for business; long documents were one scenario there and are the whole subject here.

Long context or RAG? Where does the cost split?

The decision rule is short: for deep reading and reasoning over one document or a few, use long context; for repeated questions against an archive of hundreds of documents, use RAG (retrieval augmented generation, the architecture that finds the relevant passages first and hands only those to the model). The per-query cost difference can exceed 100 times. If the line is unclear, prototype with long context and move to RAG when volume arrives.

Bands are more honest than point figures. A single million-token API request costs somewhere between $5 and $15 depending on the model, and the cheapest open-weight derivatives drop below a tenth of that. Ask the same question through RAG and the model reads only a few retrieved chunks, so the per-query cost stays under a few cents. One independent technical write-up that runs this arithmetic finds a daily gap of thousands of dollars between the two approaches at 10 thousand queries a day. Its assumptions are its own, but the order of magnitude holds.

Two details sit in the fine print of the price lists. First, some providers (in our research, Gemini's Pro model and Grok fall in this group) double the unit price on requests above a 200-thousand-token threshold, while Claude's newer models charge one rate across the full window. Second, prompt caching cuts input cost several times over when you ask the same document repeated questions, but it does nothing when every request carries a fresh document. A small company's "read each contract once" scenario is exactly that second case. For what RAG costs to set up and when it is worth it, see our non-technical guide to RAG.

A worked scenario: a 380-page tender specification

A 25-person construction contractor receives a 380-page technical specification and a 40-page draft contract for a public tender. The goal: turn the engineer's two-day read into a two-hour scan, flag the risky clauses and produce a summary for the bid team. Which tool, at what cost, and how?

The arithmetic first. If the documents are in an agglutinative language such as Turkish, 420 pages come to roughly 300-340 thousand tokens by the band above; in English, closer to 170-200 thousand. Either way the file does not fit comfortably in a 200-thousand-token window and fits easily in a million-token one. On the consumer side, Claude's 100-page PDF cap means splitting the file into four, while NotebookLM takes it as one source. On the API side, a large-window model can take the whole thing in one request.

Then the cost. One API request that reads the full document lands around $1-2 for input on a mid-priced model, $2-3 including output. If the bid team asks that document 20 questions with no caching, that becomes $40-60; with caching, the same 20 questions fall to $10-15. Set against two days of an engineer's salary, the sum is obvious. But at "30 tenders a month, 20 questions each" the monthly bill climbs into the hundreds of dollars, and at that point a RAG setup that chunks and indexes each document once becomes both cheaper and more consistent.

Our recommendation in this scenario is staged: three months of single-document work in NotebookLM or a large-window API model, a monthly accuracy check with the five-question protocol, then RAG once volume grows. The critical caveat sits here too: before uploading a tender document to a consumer account, check that plan's "do not train on my data" setting. Most business plans have it on by default; a share of individual plans do not.

Frequently asked questions

If I upload a 300-page document to ChatGPT, will it read it?

By file size, yes, but the context window depends on your plan; on the free tier most of the document may not fit, and the model can answer without ever reading the end. The check is simple: ask about a fact on the last page. A wrong answer means the document was not fully read.

How many pages is a million tokens?

Roughly 2,500 pages of English, or 1,200-1,400 pages of a token-heavy language like Turkish. Table-dense and scanned documents bring the number down.

If the window is big, does the model remember everything?

No. Long-context benchmarks show models cannot apply the same attention across the whole window, and information in the middle is the most likely to get lost. Giving a page number when you ask about a critical clause raises accuracy noticeably.

Are non-English documents more expensive to process?

Usually yes, by up to two times for languages like Turkish. The same content splits into more tokens, so it uses more of the window and produces a higher API bill. If an English version of the document exists and the job allows it, reading that is cheaper, but do not rely on a translation for legal text.

Long context or RAG: how do I choose?

Look at document count and query frequency. A few documents, deep reading, occasional questions: long context. Hundreds of documents, repeated questions, several users: RAG. If you sit between the two, start with long context and switch when volume pushes you.

I will ask one document 20 questions. Do I pay full price each time?

Not if you use prompt caching through the API; input cost drops several times over. In consumer apps this is managed for you, with no charge beyond the subscription, though you may hit usage quotas.

What should you actually do?

• Convert your page count to tokens. Divide pages by about 400 for English or 750 for Turkish; the result is your need in thousands of tokens. Above 200 thousand, pick a tool that takes the file unsplit or a large-window model.
• Check app limits separately from the model. Look at page, MB and file-count caps before uploading; if you are forced to split, expect cross-reference quality to fall and plan around it.
• Run the five-question test. Start, middle, end, cross-reference, trap. It takes 20 minutes, and it tells you which tool is reliable on your documents rather than on a product page.
• Multiply cost by query count. One read per document looks cheap; multiply by monthly documents and questions and you will see when RAG becomes the cheaper option.
• Turn off training use before anything else. Read your plan's data policy before uploading contracts; a business plan or direct API use removes most of that risk.

The context window matters for long documents, but it is not a number that decides on its own. Put the app limit, the effective window, the language's token cost and the query volume side by side and the right tool tends to reveal itself. If you run the five-question protocol on your own documents and find the results hard to read, we can share our own test tables showing which tool held up on which document type.