The context window is the maximum amount of text — measured in tokens, not words — that a language model can attend to at once. It is the model's working memory: the prompt you send, any retrieved documents, the conversation so far, and the response being generated all have to fit inside this single budget, and anything that falls outside it simply does not exist as far as the model is concerned. When people say a model has a "128K context," they mean it can hold roughly that many tokens in view at one time. Almost every practical frustration and design choice around long documents, long chats, and retrieval traces back to this one hard limit and the costs of enlarging it.\n\nIt is a hard architectural boundary, and the prompt and the output share the same budget. The window size is baked into the model by how its attention and positional encoding were built and trained; it is not a soft preference but a ceiling. Two consequences follow immediately. First, everything is counted in tokens — sub-word pieces — so a rough rule of thumb is that a token is about three-quarters of a word, and code or unusual text tokenizes less efficiently. Second, generation eats into the same budget: if a model has an 8K window and your prompt is 7,500 tokens, there is only room for about 500 tokens of answer. Exceed the window and something must give — older turns get truncated or the request is rejected — which is why long conversations "forget" their beginnings.\n\nEnlarging the window is expensive because attention cost grows quadratically and the KV cache grows with length. The reason context windows are not simply enormous is cost. Standard self-attention compares every token with every other token, so its compute scales with the square of the sequence length — double the context and you roughly quadruple the attention work. At inference there is a second tax: the KV cache, the stored keys and values for every token processed so far, grows linearly with context length and quickly dominates GPU memory for long sequences. Together these are why a longer context costs more per query and why an enormous amount of research — sparse and sliding-window attention, FlashAttention, RoPE-based position scaling, and retrieval-based alternatives — exists specifically to make long context affordable.\n\nA bigger window is not automatically better, because effective use lags the advertised number. Models can attend to a long context but do not attend to it evenly. The well-documented "lost in the middle" effect shows that models reliably use information at the start and end of a long context while recall sags for material buried in the middle, so an answer sitting at token 60,000 of a 128K prompt may be missed. This is why effective context — how much the model can actually reason over reliably — often trails the advertised window, and why simply stuffing everything into a giant prompt is frequently worse than retrieving the few relevant passages and placing them well. The context window sets what is possible; how the model weights positions within it sets what is reliable.\n\n| Aspect | What it means |\n|---|---|\n| Unit | Tokens (~¾ of a word), not characters or words |\n| Shared budget | Prompt + retrieved text + history + output together |\n| Hard limit | Fixed by architecture/training; overflow truncates |\n| Cost of length | Attention ~O(n²); KV cache grows linearly |\n| Effective < advertised | "Lost in the middle" — uneven recall across position |\n\n``svg\n\n``\n\nThe unhelpful way to think about the context window is as a simple "bigger number is better" spec, as if a model with a million-token window is straightforwardly ten times better than one with a hundred thousand. The useful way is to treat it as a fixed working-memory budget denominated in tokens, shared by everything the model must consider at once, and priced by a quadratic attention cost that makes every extra token of length progressively more expensive. That framing explains why long chats forget their openings, why long-context models are costly to serve, why the industry pours effort into sparse attention and position scaling, and why a giant window still disappoints when the crucial fact is buried in its middle. Read the context window through a working-memory-budget lens rather than a bigger-is-always-better lens, and you start doing what actually helps — spending the budget deliberately, placing the important tokens where the model looks, and reaching for retrieval instead of simply making the prompt longer.