A 200,000-token context window is a place to put documents. It is not a promise that they’ll be read.

That distinction is the whole subject of this article. Claude handles long documents better than almost anything else available, and it will still confidently answer a question about page 40 of a 200-page report based on attention it never really paid to page 40. The research on why is now substantial, and it points to a handful of techniques that make the difference between a useful answer and a plausible one.

What the research actually found

Four findings matter, and they build on each other.

Position affects accuracy. Liu and colleagues documented the “lost in the middle” effect: performance follows a U-shape, with accuracy highest when relevant information sits at the beginning or end of the context and dropping by more than 30% when it sits in the middle. The finding replicated across six model families and has been confirmed since across others.

The pattern changes once the window is more than half full. This is the practical update most people haven’t heard. Veseli and colleagues (2025) found the U-shape only holds while context is under 50% full. Past that, degradation runs by distance from the end β€” the model favours recent tokens, then middle ones, then early ones (summary of the literature).

It isn’t a retrieval failure, it’s a length effect. Du and colleagues (2025) replaced all the non-target tokens in a long input with blank spaces and the degradation persisted β€” so the problem isn’t that the model can’t find the fact among distractions. Length itself degrades performance.

Similar-but-irrelevant content actively misleads. Chroma’s 2025 work found that semantically similar distractors reduce accuracy beyond what length alone explains: one distractor hurt, four compounded the damage, across 18 models. And a genuinely strange result β€” models performed better on shuffled text than on logically coherent documents, suggesting the attention mechanism is disadvantaged by ordinary narrative flow (Atlan).

An honest counterpoint: a 2026 paper reported that Gemini 2.5 Flash answered simple factoid needle-in-a-haystack questions accurately regardless of position, even near the context limit (paper). Frontier models have genuinely improved at this. Which leads to the distinction that actually matters.

Retrieval improved. Reasoning didn’t.

Modern models are now quite good at finding a stated fact in a long document. They remain much weaker at reasoning across one.

The clearest illustration in the literature involves two-hop questions. Asking which character visited a particular building is retrieval. Asking which character has been to a particular region β€” requiring the model to know the building is in one city and that city is in that region β€” is two hops, and performance on questions like that degrades far more sharply as context grows (Understanding AI). Other work found degradation across many task types, not just needle-hunting, and often at far fewer tokens once the task was complex.

So the operating rule for long documents is:

Ask a long document for retrieval. Do the reasoning in a second, short pass.

Everything below is an application of that one sentence.

Seven rules that follow from the findings

Rule Why
Put the question after the document, not before Recency advantage is real in both position patterns
One document per question Similar-but-irrelevant material actively misleads; distractors compound
Never ask a multi-hop question of a long document Complex tasks degrade far faster than simple retrieval
Ask for verbatim quotes plus locations Converts an unverifiable summary into a checkable claim
Stay well under the stated window Effective context length is often less than advertised
Start a fresh conversation per document Degradation accumulates with everything already in the window
Don’t rely on material sitting early in a mostly-full window Past 50% full, early tokens are the weakest position

The fourth rule is the highest-value one. “Summarise the termination clauses” produces something you have to trust. “Quote every sentence containing the word ‘terminate’, with the section number for each” produces something you can check in ninety seconds β€” and if a quote isn’t there, you’ve found a fabrication rather than absorbed it. That’s the same verification logic set out in fact-checking AI-generated content.

The two-pass method

This is the core technique, and it’s worth doing properly.

Pass one β€” extraction only. Upload the document. Ask for extraction with no analysis: every passage relevant to your question, quoted verbatim, with section or page references, and an explicit instruction to quote nothing that isn’t in the text. Resist asking what it means. You’re building a short, verified working document.

Verify. Spot-check five or six quotes against the source. This takes minutes and tells you whether the extraction is trustworthy. If two are wrong, discard the whole pass and try a narrower scope.

Pass two β€” reasoning, in a fresh conversation. Paste only the verified extract. Now ask the analytical question. The model is reasoning over two pages instead of two hundred, in a nearly empty context window, which is the condition under which it performs best.

It feels slower and it isn’t. One-pass answers on long documents get re-checked, argued with and redone; two-pass answers get used.

When to chunk, and when not to

Chunking β€” splitting a document and processing sections separately β€” is the right move more often than people assume, but not always.

Chunk when the document is genuinely long, when sections are independent (a contract’s clauses, a report’s chapters), when you need completeness rather than a gist, or when you’ll need to cite specific locations.

Don’t chunk when the answer depends on relationships across the whole document β€” narrative arc, an argument developed over chapters, a contradiction between an early clause and a late one. Chunking destroys exactly the connections you’re looking for.

For that second category, the honest advice is to read it yourself and use the model for extraction around your reading. Every finding above says the same thing: the model’s cross-document reasoning is the weakest thing it does, and it’s the thing people most want to delegate.

The most dangerous question you can ask

“Does this document mention X?” β€” and getting “no.”

A negative answer about a long document is the least reliable output available, because the model cannot distinguish between not present and not attended to. Both produce the same confident “no.”

The consequences are asymmetric. A false positive is caught the moment you look for the quote. A false negative is invisible β€” you conclude the contract has no auto-renewal clause and move on.

Three ways to handle it:

  • Search the file directly first. Ctrl-F is not obsolete. Use it for exact terms, then use the model to interpret what it finds.
  • Invert the question. Instead of “does it mention termination,” ask “quote every passage about ending, cancelling or exiting the agreement.” A positive extraction task rather than a negative judgement.
  • Never take absence as a finding. If nothing came back and it matters, that’s a prompt to look yourself, not a conclusion.

What else not to trust from a long-document pass

Numbers you didn’t verify. Figures pulled from tables in long documents are a common failure point β€” a value read from an adjacent row or column looks entirely plausible. Check every number you’ll act on against the source.

Comparative claims across documents. “The second contract is more favourable” requires reasoning across two long inputs at once, which is the worst-case scenario for every finding above. Extract both separately, then compare the extracts.

Anything phrased as a total or a count. “There are seven exceptions” implies exhaustive attention across the whole document. Ask for the list with locations, then count them yourself.

These limits apply to any assistant, not just Claude β€” the research covers many model families. For the trade-offs between them, see ChatGPT vs Claude vs Gemini, and for Claude’s usage caps specifically β€” which matter a lot when you’re doing multiple long-document passes in a session β€” the Claude AI review.

Setting up for repeat work

If you return to the same body of material regularly, a persistent project with the documents attached beats re-uploading, but it doesn’t repeal any of the rules above β€” a project is still a context window, and everything in it competes for attention. Keep projects narrow, one subject each, and prune documents that are no longer relevant. The retrieval-over-your-own-material framing is developed in the Notion AI review.

For research where the sources are external rather than uploaded, the sourcing workflow in using Perplexity as a research assistant is the better starting point, and the same extraction-then-reason discipline carries into market research and competitor content analysis. The wider stack is in the best AI tools for small business owners.

Frequently asked questions

Can Claude really read a whole 200-page document?

It can hold one, which isn’t the same thing. Research across multiple model families shows accuracy degrading with input length regardless of position, with more than 30% drops documented for information in weak positions, and effective context length often falling short of the advertised figure. Treat a large window as capacity, not comprehension, and verify anything you’ll act on.

Where should I put my question β€” before or after the document?

After. Both documented position patterns favour recent tokens, so a question placed at the end of the context sits in the strongest position. Where the window is more than half full, early content is the weakest position rather than the middle, which is the reverse of the advice most guides still give.

Why does the model invent details from long documents?

Two mechanisms. Length alone degrades performance even without competing content, as shown by experiments replacing non-target text with blanks. And semantically similar but irrelevant passages actively mislead, with the effect compounding as more distractors appear. Asking for verbatim quotes with locations makes both failures visible instead of invisible.

Should I upload several documents at once?

Generally no. Related documents are exactly the kind of similar-but-irrelevant material that degrades accuracy, and comparisons across long inputs compound every weakness at once. Extract from each separately, verify, then compare the short extracts in a fresh conversation.

Is “no, that isn’t mentioned” a reliable answer?

It’s the least reliable answer you can get, because the model can’t distinguish between information that isn’t there and information it didn’t attend to. Search the file directly for exact terms, rephrase as a positive extraction task, and never treat an absence as a finding when it matters.

What’s the single most effective habit for long documents?

Two passes. Extract verbatim quotes with locations in the first pass and do no analysis; verify a handful of them; then reason over the short verified extract in a fresh conversation. It moves the hard thinking into a nearly empty context window, which is where models perform best.