3.3 Managing Context Limits and Memory

Every model has a finite context window -- the total amount of text it can consider at once. That total isn't just the current question; it covers your instructions, any uploaded material, the full conversation history so far, and the answer being generated, all sharing the same finite space. As a conversation grows very long, early details can get crowded out and quality can drift, even though nothing has technically broken.

Here is the central Associate-level insight in this task statement: recognizing that degraded output late in a long session is often a context problem -- not a model problem. The model didn't get worse partway through the conversation. The conversation got crowded, and low-signal or stale content ends up competing with what actually matters for the model's attention.

This distinction matters because it points to a different fix. If you assume the model is broken, you might switch tools, restart from scratch with no plan, or simply give up on the thread. If you correctly diagnose a crowded context window, the fix is straightforward: manage what's in the window, rather than assuming the tool itself failed.

It's easy to assume the fix for a crowded context window is simply a bigger window. That's a trap of its own: a larger context window is not a free fix. It can raise cost and latency, and stuffing everything into it is rarely better than curating what's actually relevant to the task at hand. The available room in the window is a ceiling, not a target to fill.

Think of it the way you'd think about a desk. A bigger desk doesn't automatically make you more organized -- it just gives clutter more room to spread out. The useful move isn't a bigger surface; it's clearing off what doesn't need to be there.

Three concrete moves manage a crowding context window, and they address the same underlying problem from different angles. Summarize and restart both reduce what the current conversation is carrying -- summarize keeps a condensed thread going, while restart cuts over to a clean one. Persist takes a different approach entirely, moving durable knowledge out of the conversation altogether.

• •Use summarize when the conversation should continue but has grown long.
• •Use restart when the conversation has drifted off-track or is too cluttered to salvage with a summary.
• •Use persist for anything durable and reusable -- instructions, reference documents -- so future conversations don't need to rebuild that context at all.

Summarize, restart, and persist are easy to treat as three interchangeable tricks for the same job, but that flattens an important difference. Summarize and restart both operate on the current conversation's length -- they manage the symptom. Persist is a structural fix: it moves durable knowledge (like the recurring reference material from Lesson 3.1's discussion of Projects) out of chat history altogether and into a more stable home, so it never has to accumulate there in the first place.

The failure mode to watch for is repeatedly summarizing or restarting the same durable background information instead of persisting it once into a Project. If the same reference material keeps needing to be re-summarized or carried over into fresh chats, that's a sign the material belongs in a Project, not that summarize or restart needs to be done more diligently.

Task Statement 3.4 questions typically describe a long, degraded conversation or a workflow that keeps re-supplying the same background, then ask what's wrong and what to do about it. Diagnose before you fix: is this a crowded context window, and if so, does the situation call for summarizing, restarting, or persisting?

• 1.Recognize degraded late-conversation output as a likely context problem, not a broken model.
• 2.Don't reach for a bigger context window as the default fix -- curate what's relevant instead.
• 3.Choose summarize for a long-but-salvageable thread, restart for one that's cluttered or off-track, and persist for anything durable and reusable.