What Context Actually Is
Context is everything the model can see in one request. It has a ceiling, and seeing doesn't mean using.
Context is everything the model can see within a single request. It has a ceiling, and seeing it doesn't mean using it. That's the single most useful model to build before you start working with AI.
What you'll run into:
- Thirty rounds into a conversation, it starts forgetting the rules you set earlier
- You throw the whole project at it and the answers get vaguer instead of better
- You open a fresh session and have to re-explain everything you settled yesterday
What it contains
Context is more than the text you type—it's the whole information environment the model can see this time. It's assembled from five parts:
- System prompt and project rules. The tool's built-in instructions, plus the constraint files in your project.
- Conversation history. Everything said in this session, including its own replies.
- Files it has read. The code and documents it has opened. One big file can swallow a large share of the window.
- Tool output. Search results, command-line output, error messages. This part runs away the easiest and can blow out the window in one call.
- Your latest words. This turn's instruction.
Managing that environment matters more than polishing the wording of your prompts. One more trap: context doesn't carry across sessions automatically. When today's session ends, yesterday's decisions are gone—unless they were written into a file in the project.
Two of the five parts grow quietly: conversation history and tool output. The longer a conversation goes, the larger the history's share; every search you run and every command you execute leaves its output behind. You think you handed it a one-page instruction, but the content this request actually has to process has already grown far beyond those few sentences.
It degrades as it gets longer
Intuitively, more information is better. In practice, no. As context grows longer, reasoning accuracy gradually declines. The decay is gradual, not a sudden cliff, so it's hard to notice. lost-middle
- The middle gets ignored most. The model pays more attention to the opening and the end, so key constraints buried in the middle often don't take effect. Put important rules first, or restate them in the current instruction.
- A big window isn't the same as using it. Being able to fit a million tokens doesn't mean all of them get used well. Once noise fills the window, instruction following and reasoning both drop noticeably.
- Irrelevant content is pollution. Reading a pile of files you don't need, pasting an unrelated log—these aren't "extra information, no harm done." They're crowding out attention.
- Cost and latency rise too. Every call costs real money; the more you stuff in, the longer you wait.
Four responses
- Write it out. Store conclusions outside the context: spec files, constraint files, progress notes. Stop it from re-deriving what's already been decided. This one has the most leverage—writing decisions into a file gives the model a memory that doesn't blur as the conversation grows.
- Give selectively. Hand over only what this step actually needs. Name the file you want changed instead of letting it search the whole repo.
- Compress. Summarize long material before it enters the context. Extract the key lines from a large log; write a periodic summary of a long conversation.
- Isolate. Run different tasks in separate sessions. One task per session, so the noise of the previous job doesn't contaminate the next.
One more thing about code organization: organizing by feature beats organizing by technical layer when you're working with AI. For a change to login, the former only requires reading the auth directory; the latter requires pulling a few files from every layer to assemble the full picture. Context management in one sentence: make everything it sees worth seeing.
