A context window is not a metaphor for “what the model remembers.” It is a literal, finite sequence of tokens that the model's self-attention mechanism operates over in a single forward pass. Every token in that sequence — whether it came from your system prompt, a tool schema, a message a user typed three turns ago, a document your retrieval step pulled in, or a result a tool just returned — sits in the same flat sequence and is visible to every other token through attention. There is no separate channel for “instructions” versus “conversation”; it is all just tokens, in order.
That flat sequence is assembled fresh on every single API call. The model does not retain state between turns — there is no persistent memory sitting on a GPU between your first message and your fifth. Instead, the serving stack concatenates the system prompt, the tool definitions, the full message history so far, any retrieved documents, and the results of any tools that were called, then runs a forward pass over the whole thing again. Turn five re-sends and re-processes everything from turn one. This is why the window's size is not a soft guideline — it is the hard ceiling on how much of a conversation, codebase, or tool catalog can be “in play” at once.
Most people building on top of LLM APIs think of “context” as the text they typed into a chat box, and treat everything else as free. It isn't. Tool definitions, retrieved documents, and accumulated history are frequently the largest consumers of the window, and they grow or shrink without the user typing a single extra word. Understanding the anatomy of the window — what's in it, who put it there, and how big each piece actually is — is the prerequisite for every context engineering technique that follows in this course: budgeting, compaction, retrieval grounding, and position-aware ordering all assume you can already answer “where did my tokens go?”