Five seconds: that is how long Adriaan de Groot showed a chessboard with a game in progress before covering it and asking the player to rebuild the position on an empty board. The Dutch psychologist, himself a chess player, tested masters and ordinary players this way in the 1940s and described the results in a study of the chess player's thinking published in 1946. Masters reproduced positions from real games with astonishing accuracy, while weaker players managed to set up only a handful of pieces from memory, which looked like simple proof that the master just has a better memory. It is hard to find a more natural explanation than the idea that someone who remembers more plays better a game in which a great deal has to be remembered.
The twist came in 1973, when William Chase and Herbert Simon added boards with the pieces placed at random. On those boards the master's advantage in their study disappeared, and the master remembered the layout no better than a novice. Later work showed that masters cope with random layouts slightly better than that experiment suggested, but their advantage still shrinks markedly compared with positions from real games.
Chase and Simon explained the result this way: the master recognises familiar arrangements of pieces, which they called chunks, and remembers a few such chunks instead of a dozen or so individual pieces, so the capacity of the master's short-term memory does not exceed a novice's. A position from a real game is made of familiar chunks, for instance the arrangement of pieces after castling, which the master has seen thousands of times. A random board contains none of them, so the master has to count the pieces one by one like any other player. How much of their memory does a chess player owe to what they remembered, and how much to what they knew to be irrelevant?
Artificial intelligence tools have their own version of this relationship. The context window, meaning all the text the model sees at the moment it answers, grows year after year and creates the impression that you only need to upload every document into the conversation and the answer will improve. The thesis of this post is that the quality of an answer depends on the selection and order of the material, and that the size of the window matters less, because a heap of documents with no order is to the model what a random board is to the master.
What the context window is and why the bill grows with every message
The context window contains your instruction, the uploaded documents, the earlier part of the conversation and the model's own previous answers. It is measured in tokens, the fragments of words into which the model splits every text before processing it. In current models of the Claude family, such as Opus 5.5 or Sonnet 5.5, the window reaches a million tokens, and the vendor's documentation calls it the model's "working memory".
The model stores nothing between conversations, so with every new message it receives the entire history again, together with the documents uploaded at the start. In practice, the longer the conversation, the more tokens are processed with every question, and the more that costs and the longer it takes. According to the documentation, requests with long context are billed at the standard rate, except for the Haiku 5.5 model, where prompts longer than 100 thousand tokens cost more.
Why room in the window does not mean good memory
Intuition says that if a million tokens fit, the model will use all of them equally well. Nelson Liu and co-authors published the paper "Lost in the Middle" in 2023, later accepted by the journal Transactions of the Association for Computational Linguistics. In it, models answered best when the needed information sat at the beginning or the end of the input and clearly worse when it was buried in the middle, and this also applied to models built for long texts. Accuracy also fell simply as the input grew longer.
In July 2025 the company Chroma described a test of eighteen models, among them GPT-4.1 from OpenAI, Claude 4 and Gemini 2.5, in which the difficulty of the task stayed constant and only the length of the text changed. Reliability declined as the text got longer, and the models handled fragments topically similar to the sought information especially badly, because those were easy to mistake for it. The vendor itself writes in its documentation that more context is not automatically better, because as the token count grows, accuracy and recall degrade, and it calls the phenomenon context rot.
In an engineering article Anthropic adds that the decline is gradual and visible across models, and that context should be treated as a finite resource, with every token drawing down part of an "attention budget". The Liu and Chroma studies concerned older generations and newer models degrade more gently, yet the same vendor's documentation as of October 2026 still warns about the phenomenon. Back to the chessboard: forty contracts dropped in with no order resemble a board with randomly placed pieces, while ten well-chosen pages with a short description of the task resemble a position from a real game.
What helps and what the model cannot do
The vendor describes two techniques for keeping context in order. The first is compaction, which means summarising a conversation that is approaching its limit and resuming from that summary, and the second is saving notes outside the window, which the tool returns to when needed. Both resemble what a good employee does: before each decision they reach for a note with the most important findings instead of going through the whole archive.
The limit of the model's ability lies where it cannot report that it missed something. It answers in a confident, fluent tone even when a clause from the twenty-seventh contract has slipped out of its attention, and I wrote about the consequences of such confidence for teams in my previous post. Data risk comes on top: every document uploaded "just in case" goes to an external provider, so the rule "only what the task needs" lowers both the bill and the exposure of contracts and personal data.
The same applies to long conversations: after several dozen exchanges the window fills with old answers and abandoned threads, so for a new subject it pays to start a new conversation and paste in a short summary of the findings. A common mistake looks the opposite: one conversation runs for a whole week because "the tool already knows what this is about", and the quality of answers declines from day to day, which the team attributes to the model's whims.
A large window has its uses, and I will assess them with caution: it works when you need to summarise one long document or find a single clause in it, because the model then reads a coherent text with one thread. Trouble starts with tasks where many sources have to be combined at once and nothing may be missed, that is, when comparing contracts or compiling figures from dozens of reports.
My recommendation is simple: treat the window as a desk holding what you are using today. It translates into two habits: upload excerpts instead of whole files and ask for quotations with page numbers, because a quotation can be checked in a few seconds and its absence immediately betrays an invented answer. A good task description placed at the start, the question repeated at the end and selected fragments in between is a setup you can verify by measurement.
First step for Monday morning: a two-hour test
Imagine a procurement department that compiles termination notice periods from supplier contracts every quarter. The measurement looks like this:
- Choose a task whose correct result you know, for example a list of termination periods from twenty contracts that someone once prepared by hand.
- First upload all twenty contracts in full and ask one question about the periods.
- Then ask an employee to pick from each contract the pages with the termination period, write a half-page task description with the expected answer format, put it at the start and repeat the question at the end.
- Count the omitted and wrong items in both answers, compare them with the manual list and note the working time.
Run both attempts on the same model in the same version, because after each update the results may shift. The test promises no difference: if there is none, you have proof that your task fits a simpler method, and if there is one, you have a number to show a director instead of an opinion. Which of the documents your team uploads to the tool "just in case" has nobody ever read to the end?