A model's context window is the amount of text — measured in tokens, not words or characters — that it can consider at once when generating a response. Everything relevant to your question has to fit inside that window: the system instructions, the conversation history, any documents you've pasted in, and the model's own reply. Once you run out of room, older content has to be dropped or summarized to make space for new input.

Context windows have grown enormously, and vendors market larger ones as a straightforward improvement — more room means you can dump in entire codebases, whole documents, or long conversation histories without worrying about running out of space. That's true as far as it goes, but a bigger window doesn't mean the model uses everything inside it equally well.

This is where "lost in the middle" comes in. Across a range of models, there's a well-documented tendency for a model to pay closer attention to information near the beginning and end of its context than to information buried in the middle of a long input. Ask a question whose answer depends on a fact stated on page one of a fifty-page document you've pasted in, and the model is more likely to get it right than if that same fact sat somewhere in the middle. The model isn't lying about having read everything — it genuinely processed all the tokens — but its attention isn't evenly distributed across them.

The practical upshot is that "just paste more in" is not a free strategy. A context window full of irrelevant or redundant material doesn't just cost more money to process (you're billed for the tokens you send); it can genuinely dilute the model's ability to find and use the one relevant fact you actually needed. This is a big part of why retrieval systems exist at all — rather than stuffing an entire knowledge base into every prompt, a retrieval step picks out only the passages likely to matter and puts them where the model is most likely to notice them, typically near the start or end of the prompt.

None of this means large context windows aren't useful — they genuinely let you work with material that simply wouldn't fit before, like an entire codebase or a long support thread. The point is to treat window size as a ceiling, not a target. Curating what actually goes into the context, and putting the most important information where a model is most likely to weight it heavily, tends to produce better results than maximizing how much you can cram in.