What happens when a task needs more context than the window allows?

Answer

Four strategies, usually combined.

Compress. Summarise older conversation turns into a shorter form. Cheap and widely used, but lossy in ways you cannot predict. A detail dropped by the summariser is gone, and the model afterwards has no idea it existed.

Retrieve selectively. Do not load everything. Load what the current step needs. For a codebase, search for the relevant files rather than reading the tree. This is usually the highest value change, and the least implemented.

Decompose. Split the task into subtasks each fitting comfortably in a window. Requires that the subtasks be genuinely separable, which is a real constraint, but when it holds it works better than compression.

Isolate in subagents. A subagent reads widely in its own window and returns only its conclusion. The parent gets the answer without the raw material. This is the main practical reason to use subagents.

What to keep when you must choose: the original task statement, the most recent turns, and any explicit constraint the user gave. What to drop first: verbose tool output, file contents already acted on, and intermediate reasoning that led to a completed step.

A useful design rule is to keep durable knowledge in files rather than in conversation, because files are re-read fresh and never silently summarised away.

Common wrong answer

"Use a model with a bigger context window." It raises the ceiling and does not remove the problem. Attention still degrades over long contexts, cost still scales with tokens, and a task that overflows a large window will overflow a larger one once the codebase grows. It also encourages loading everything, which measurably hurts quality.