Comparisons

Which AI handles the longest documents

Context windows are spec-sheet numbers. What actually decides whether your report, manuscript, codebase or contracts fit, and how to tell inside the app.

Multi Chats Team
October 14, 2026 · 9 min read

It is tempting to choose the model with the largest context window. The number that would build it sits on every model's info card in MultiChats, printed as a token count with the word context after it, and it does not tell you how well the model will read your document.

So this page goes by document instead. Five kinds of long thing people actually put into a chat, and what decides whether each one survives.

Why the biggest number is the wrong number

A context window is the total amount of text a model holds at once: your document, the conversation so far, and the reply it is about to write, all in one space. 23 of the 60 models here advertise a window large enough that most people stop reading it as a limit.

That figure is a ceiling on what a model will accept and says nothing about where it stops being reliable. Models start missing things well before they fill up, usually in the middle of a long document, and the failure looks like a confident answer about a passage that was skimmed. Our registry keeps an internal threshold per model marking roughly where that begins, and for several of the largest advertised windows it sits at a fraction of the headline.

We do not publish those thresholds; they get recalibrated as models change. The live one is in the app.

The two things the app tells you

The context meter. It sits under the chat box beside the model selector, showing what the thread has used over what the model advertises. The tilde in front is doing real work: the left-hand figure is an estimate, built from the token usage your last reply reported plus a rough character count for everything typed since. The right-hand figure is the full declared window, the same one on the info card.

The color is the part worth watching, because it tracks the internal quality threshold rather than the number printed beside it. Amber lands at four fifths of that threshold and red once you are past it, both well before the fraction beside them looks alarming: a meter showing a modest slice of the advertised window can already have turned. Hover it and the tooltip names, in tokens, the point where answers tend to fall off for the model you are on. Web and mobile share the estimator and trip at the same place.

The pre-send block. The meter warns; this one refuses. Before a message goes out the app estimates the whole turn against the model's real window. If it would not fit, nothing is sent. You get a message naming the model: "This conversation is too long for Claude Opus 5.5. Try starting a new chat or shortening your message." On mobile the same alert offers a New chat button.

What the app will read at all

25 of the 60 models take a PDF attachment, four of them on the free plan. Order matters more than the count, because the gate sits on the attach rather than the send. Select the model and the file goes in. Select it afterwards and the app has already turned the file away.

A scan has no text layer to pull out, so for signed-in users a scanned PDF of up to 20 pages and 20MB is transcribed first, and the model is told the text may contain recognition errors. Any transcript can misread a figure. Longer scans go to a model that reads PDFs natively as the file itself, and what the provider makes of the pages is up to them.

A long report, 100 to 300 pages

The size of the thing. By the app's own arithmetic, about 2,500 characters to a page and four characters to a token, a page of prose runs a little over 600 tokens. Call it 60,000 for a 100-page report and nearer 190,000 for a 300-page one, before you ask a single question.

What decides whether it fits. Three things, in order: whether the PDF has a text layer, whether your model takes PDFs, and how much conversation is already in the thread. Start fresh and attach before you type.

Where it goes wrong. Quietly, at a limit most people never find out about. A PDF with a text layer now usually travels as the text we pull out of it, even to a model that reads PDFs natively, and that text is cut at 400,000 characters, roughly 160 pages by the arithmetic above, with a truncation note where the rest used to be.

The routine. Ask for a map before a summary. "List every section heading and say in one line what each covers" gives you a table of contents to interrogate section by section.

Verdict. Comfortable to about 100 pages on any model that takes PDFs. Past roughly 150, split the file into sections and assume the middle needs checking.

A book-length manuscript

The size of the thing. A 90,000-word novel lands near 120,000 tokens on the same estimate, before your questions and before the model's replies, which live in the same window.

What decides whether it fits. The window holds the manuscript and everything the two of you say about it afterwards. A book that fits at the start of a session may not fit an hour in, which is the meter's reason for existing.

Where it goes wrong. Continuity questions across the whole book are the least reliable thing on this page. "Does the timeline hold up in chapter 19 given what happens in chapter 4" asks for two distant passages at equal sharpness, and that is the ability that degrades first. A manuscript sent as a .docx counts as a document upload, which is a Pro feature, and a PDF or .docx stops at 400,000 characters, roughly the first 75,000 words.

The routine. One thread per part or act. When a thread has done its job, use Summarize and start fresh from the meter's warning popover: it saves a short summary of the conversation as a memory and attaches it to the next chat. Summarizing is a paid feature.

Verdict. No model here reads a whole novel well in a single thread. Split by part, carry a summary forward, and you get most of the way there.

A codebase

The size of the thing. Individually small, collectively enormous. Archives are rejected on every plan, so files go one at a time. Text and code uploads are a Pro feature, and 59 of the 60 models accept them.

What decides whether it fits. The per-message file count, well before the window: 2 files on Pro, 20 on Pro+. Paste code instead and the ceiling is a per-message size cap that rises with your plan and counts pasted text and attached files together, lower still on phones with limited memory. Go past it and the send is refused, with a note telling you to shorten the message.

Where it goes wrong. The estimate runs high on dense code, since punctuation-heavy text tokenizes differently from prose. The pre-send block compensates by measuring against the full declared window rather than the quality threshold, so it only stops a doomed send.

The routine. Send the two or three files the question is about and describe the rest in a sentence. One module plus a clear account of its neighbors beats twelve files and no orientation.

Verdict. Good at reading code, bad at holding repositories. One module per thread.

A year of chat history

The size of the thing. The thread you never closed. Every turn resends everything before it, so a conversation fills the window with no upload involved.

What decides whether it fits. Time, mostly. The meter climbs on its own, and the point where it turns amber arrives sooner than the printed fraction implies.

Where it goes wrong. Two ways, both visible in the app. Switching models repeatedly inside one thread trips the conversation health warning, which fires at three or more different models in the last twelve messages. Switching to a model with a smaller window is the other; the app now flags it the moment you pick, with a button to switch back.

The routine. When the meter goes amber, act on it rather than pushing through. Summarize and start fresh carries the conclusions into a new thread as a memory. Failing that, open a new chat and paste the three paragraphs that matter.

Verdict. No model choice fixes this one; it is housekeeping. Long threads need pruning, and the app tells you when.

A stack of contracts

The size of the thing. Twenty documents of twelve pages each. Every file trivial on its own, the pile a small library.

What decides whether it fits. The per-message attachment cap, before the window gets a say. One file per message on Free at 10MB and three uploads a day, two on Pro at 20MB, twenty on Pro+ at 200MB.

Where it goes wrong. Cross-document questions. "Which of these has the shortest notice period" invites an answer drawn from whichever two documents the model read most closely, delivered with the confidence of one drawn from all twenty. Before you upload anything with a signature on it, check the model you are on. We do not train on your conversations. Where we know a provider's practice differs, that model's info card carries a notice, and some are blunt about it: Grok's reads "xAI may use your conversations to train Grok models."

The routine. Read each contract in its own thread, asking for the same five facts every time: parties, term, notice period, money, termination. Then open one more thread, paste the twenty short answers, and compare those.

Verdict. Pro+ will physically accept the stack, in one message or kept in a folder's Files section. A comparison you can trust still means reducing each document first.

Four things to check before you paste something long

  1. Is it a scan? Ask the model to quote the first line of page three word for word. If it paraphrases, it never read your document.

  2. Does the selected model take PDFs? Twenty-five of sixty do, and the app blocks the attach if yours does not.

  3. What color is the meter? Amber before you attach means the thread was already too full for a long file.

  4. Is this the model you started on? A mid-thread switch to a smaller window is the usual cause of a blocked send.

What is a context window covers tokens, limits and why quality drops before capacity does. Otherwise the meter under the chat box is what this page keeps arriving at, and it measures your document rather than a spec sheet. Open a chat and watch it while you work.