The idea

A context window is the bounded set of material a language model can use while producing one response. Think of it as the task packet available for this turn, not as permanent memory and not as the model’s training data. The packet may include earlier messages, a system prompt, documents, images, tool definitions, tool results, and the new request. The answer being generated also occupies space in the window. Source

That matters in a familiar developer situation. You ask a coding agent to investigate a failing test. Over many turns, it reads source files, receives terminal output, calls tools, and discusses several possible fixes. Later, it overlooks the original acceptance criterion. The criterion may still appear somewhere in the conversation, but it is competing with a large amount of other material.

Models process text as tokens: pieces of text that are not the same as words. A context window has a finite context limit. If input alone exceeds that limit, an API can return a prompt-too-long error. For some newer models, generation can instead end with a context-limit stop reason. The exact behavior depends on the model and application. Source Source

Plain English: The model can only work from the material supplied for this response. Give it a focused task packet, not every artifact produced during the project.

More room is useful, but it is not a guarantee of a better answer. Anthropic documents that accuracy and recall can decline as context grows, calling this effect “context rot.” Source So the practical goal is not simply to maximize context. It is to keep the most relevant evidence, instructions, and room for the answer together.

A small example

Example: A test for parseInvoice() fails after a date-format change. A broad request pastes a full repository listing, several unrelated logs, and a long discussion, then asks, “Fix it.” The agent must work out which information matters.

A focused handoff instead says:

  • Goal: make parseInvoice() accept ISO dates.
  • Relevant file: src/billing/parseInvoice.ts.
  • Evidence: the failing test and its error output.
  • Constraint: preserve the existing locale-specific format.
  • Check: run the named test after the change.

This does not make the model correct. It gives it a smaller, inspectable task packet. It also makes review easier: you can check whether the proposed change meets the stated constraint and test.

For a long session, create a short working-state note before beginning a new phase. Include the goal, changed files, decisions already made, unresolved questions, and test status. If your tool compacts the conversation, treat that note as a handoff, not as proof that every earlier detail survived. Context compaction can summarize older conversation content after a configured token threshold and continue with the compacted context; summaries can lose details. Source

Try it

Take five minutes on a real task. Before your next agent request, remove one irrelevant file dump or long tool log. Then write four lines: objective, relevant files, open question, and test to run. Ask for one concrete next step and an explanation tied to those four lines.

Compare the response with your previous broad prompt. Did it identify the right file? Did it preserve the constraint? This is not a benchmark of model intelligence. It is a quick check of whether the task packet contains the information needed for review.

Watch out

Do not assume text is remembered permanently because it appeared earlier in a chat. Context is the material available to the current request; persistence across sessions is a separate product feature.

Do not blindly delete context either. Removing a security requirement, interface contract, or failing assertion can make a response less useful. Keep facts that constrain the change, and trim material that does not.

Finally, a model can miss information even when it technically fits in the window. After compaction or a long detour, restate critical requirements and verification steps. A concise, explicit handoff is a practical safeguard—not a substitute for reading the diff and running tests.