Context & Memory
Module 13 — Context & Memory
Goal: Understand Copilot’s two kinds of “remembering”: the context window (its short-term working memory during one session) and the memory system (long-term notes kept between sessions) — including compaction, how memories are stored and validated, and how to manage both.
This answers your question about how Copilot manages context and memory.
13.1 Two different kinds of memory
People say “memory” and mean two very different things:
- The context window — Copilot’s short-term working memory. It’s everything the model can “see” right now, in this one conversation. It’s finite and resets each session.
- The memory system — Copilot’s long-term memory. Facts it deliberately saves to storage so it can recall them in future sessions.
Mixing these up causes confusion (“why did it forget?” vs. “why did it remember?”). Keep them separate in your mind.
13.2 The context window — short-term working memory
What it is
The context window is the total amount of information the underlying model can consider at one time, measured in tokens (a token is roughly ¾ of a word). It has a fixed maximum size that varies by model. Everything Copilot uses for a response competes for this space:
- Your current prompt and the ongoing conversation.
- The code files and selections you’ve referenced.
- Your custom instructions (Module 11).
- Any skill bodies that got loaded (Module 12).
- Retrieved long-term memories (section 13.4).
- Tool/command outputs the agent has seen.
Think of it as a desk of fixed size: you can pile on papers, but once it’s full, something has to come off. The model cannot “see” anything that isn’t currently on the desk — which is exactly why instructions, skills, and memory are designed to load selectively.
Why it matters
- If context overflows, important details fall off and Copilot seems to “forget” what you said earlier or ignore a rule.
- This is the entire reason for progressive disclosure in skills (Module 12) and for keeping instructions short (Module 11): every token you spend on rarely-needed text is a token unavailable for your actual code.
Compaction — surviving long sessions
Long agent sessions would blow past the window quickly. Copilot handles this with compaction: when a conversation reaches roughly 80% of the window’s capacity, Copilot automatically compresses the older conversation history into a much smaller summary. The summary preserves what was discussed and decided while freeing space to keep going. You’ll see the session continue smoothly; under the hood the early back-and-forth has been distilled to its essence.
Compaction is lossy by nature (a summary isn’t the full transcript), so for very long tasks it helps to restate critical constraints periodically or rely on written instructions/memory rather than assuming a detail from 200 messages ago survived verbatim.
Managing the context yourself
You have direct control over what goes on the “desk”:
- Reference precisely. Point Copilot at the exact files/symbols relevant to the task instead of the whole repo.
- Start fresh for new tasks. A new conversation clears the context; don’t let one long thread accumulate unrelated junk.
- Trim instructions and skills. Remove stale rules; scope skills tightly so only relevant ones load.
- In the CLI, commands exist to inspect and manage context usage (clearing, compacting, checking how full the window is). Check the current docs for the exact commands, as they evolve.
13.3 The memory system — long-term memory
What it is
Copilot Memory is a GitHub-hosted system that lets Copilot learn and retain repository-specific insights as it works, and recall them in later sessions. Where the context window forgets everything when a session ends, memory persists.
Examples of what it captures: “this project uses pnpm, not npm,” “the auth logic lives in src/auth/ and tokens are validated in verifyToken(),” “the team prefers integration tests over heavy mocking.” These are facts Copilot figured out once and shouldn’t have to rediscover every time.
How it works across a session
- Retrieval at start. When an agent begins a new session, Copilot retrieves the most recent, relevant memories for that repository and includes them in the prompt (spending some context-window budget — the two systems interact).
- Validation before trusting. Before relying on a stored memory, the agent verifies it’s still accurate — for instance by checking that cited code locations still exist and still say what the memory claims.
- Correction. If the current code contradicts a memory, Copilot stores a corrected version rather than acting on stale information.
- Refresh. If a memory proves accurate and useful, Copilot refreshes its timestamp to mark it as still relevant.
- Expiry / garbage collection. Any stored fact that goes unused is automatically deleted after about 28 days — though that timer can reset when the memory is successfully validated and used. This keeps memory from accumulating stale or irrelevant cruft over time (conceptually similar to how Git garbage-collects unreferenced objects in Module 04).
Where it lives
Copilot Memory is GitHub-hosted and scoped to a repository, so insights learned while working on a repo are available in future sessions on that same repo. This is distinct from the file-based customization (instructions/skills) you author by hand — memory is populated automatically by Copilot itself as it works, not written by you (though you can manage it; see below).
13.4 Managing long-term memory
Because memory is automatic, you mostly let it run — but you have oversight:
- Review and prune. You can inspect what Copilot has remembered and remove entries that are wrong or no longer wanted. (Exact UI/commands vary by surface — IDE, CLI, github.com — so check current docs.)
- Prefer explicit guidance for must-follow rules. Memory is best-effort and can expire; anything that must always hold belongs in custom instructions (Module 11) or a skill (Module 12), which are deterministic and version-controlled. Use memory for accumulated convenience knowledge, not for critical policy.
- Correct it in conversation. If Copilot acts on a wrong remembered fact, tell it the correct version — its validate-and-correct loop will update the stored memory.
13.5 How the three guidance systems fit together
You now have the full picture of Part C’s levers. Here’s the unified model:
| Mechanism | Lifetime | Who writes it | When it’s loaded |
|---|---|---|---|
| Context window | One session | (it’s the live workspace) | Always — it is the working memory |
| Custom instructions | Permanent, version-controlled | You, by hand | Every relevant request (always-on) |
| Skills | Permanent, version-controlled | You, by hand | On demand, by description match (progressive) |
| Memory | ~28 days, auto-expiring | Copilot, automatically | Retrieved per session, validated before use |
A mature setup uses each for its strength: instructions for standing rules, skills for detailed on-demand procedures, memory for facts Copilot learns on its own — all flowing through the finite context window, which compaction stretches across long sessions.
Try it yourself
- In a long agent session, notice if/when the tool indicates it summarized earlier history — that’s compaction at work.
- Tell Copilot a project fact (“we use pnpm here”), end the session, start a new one later, and see whether it recalls it (memory) — then check whether it validated the claim against your code.
- Move a “must always” rule out of conversation and into
copilot-instructions.md; confirm it’s now reliably applied without depending on memory. - Reference one specific file in a request instead of the whole repo, and notice tighter, more relevant output (better context hygiene).
Key takeaways
- Context window = short-term working memory, finite, measured in tokens, shared by prompt + code + instructions + skills + memories; resets each session.
- Compaction kicks in around 80% capacity, summarizing old history so long sessions can continue (lossily).
- Copilot Memory = long-term, repo-scoped, GitHub-hosted facts that Copilot saves automatically, validates before trusting, refreshes when useful, and deletes after ~28 days unused.
- For anything that must always hold, prefer instructions/skills over memory; memory is best-effort convenience knowledge.