In the last video we saw that the model can only attend to a fixed window of tokens, and that everything it uses to answer has to fit inside that window. This video is about what the harness puts into that window on your behalf. We'll see what is already there before you type, what happens when the window fills up, and the two kinds of memory that carry across sessions.
Here is the context window again, drawn as a box. The model sees exactly what is inside it and nothing else. The model itself does not decide what goes in. The harness does. Everything the model knows about your project, the harness put there, and a large part of an agent's machinery is really about managing this one window.
The first thing in, before you have typed a word, is a block of instructions from the harness to the model. It says how to behave, how to use tools, and how to format its answers. It's called the system prompt. The terminal normally shows your conversation rather than this underlying system prompt, but the model receives both.
The window also contains tool definitions. Each definition gives a tool's name, purpose, and arguments, so the model can ask to use it. This is how the model knows which tools it can use to read a file or run a command. Take the definitions away, and it can still write you text, but it has no way to ask for an action.
Then the harness loads the instruction files, a few short files of instructions about the project, which we'll come back to in a moment. All of this is in place before you type your first prompt. A fresh session is never really empty.
As the agent works, the harness adds your messages, the model's replies, and tool results. That can include file contents and command output, sometimes shortened to fit. The files and the tool output are usually the biggest part. One large log file can take more room than everything the harness loaded at the start.
Remember from the last video that chat is completion over the whole transcript. So every request sends the whole window again, from the system prompt to your latest message. A one-line question in a session that has been open all day still carries that window with it. After compaction, part of the history is a summary rather than the original text.
You can look at the window yourself. The slash context command shows what is in it, category by category, in tokens, and how much of the window is still free. Claude Code setups can have windows from two hundred thousand tokens up to a million, depending on the model and configuration. Watch the percentage used to see how much room remains in yours.
The instruction files get a line of their own, showing how much of the window they take. If the agent ignores a rule, first check whether the file containing it is listed. Slash memory helps you find and edit the file. A loaded rule can still be missed or conflict with another instruction.
Now let's talk about what carries over from one session to the next. A new session does not start with the full earlier conversation. The harness loads instructions and saved notes into a fresh context window. Here we distinguish two kinds of saved memory.
The first is the instruction file. It's a file called CLAUDE dot M-D, which you can review and edit. It explains how to work in this repository: the commands that build and test it, the conventions the code follows, how the project is laid out, and the rules you would otherwise re-explain at the start of every session. You can keep personal instructions in your home directory, shared project instructions in the repository, and local project notes in a file you leave out of Git. Claude Code loads the applicable files together. Other agentic CLIs read a similar file under the name AGENTS dot M-D. Claude Code reads it too, when the project has no CLAUDE dot M-D. When a project has both, a one-line import brings it in. We'll see how in a moment.
The second is auto memory: notes Claude Code can save as you work, such as corrections, preferences, and project facts that are hard to infer from the code. The notes live under your home directory, in a separate folder for each project, with an index file called MEMORY dot M-D. The first two hundred lines of that index load at startup, and there is also a cap on its size. The agent reads the detailed notes when needed. When you see "saved two memories" in the terminal, it has written notes there. When enabled, auto memory loads alongside your instruction files. You can inspect, edit, or delete both kinds of file.
The mental model here is a simple one. The model forgets. The harness carries two kinds of notes across sessions, but what the agent must know about your project is still your job to write down, and to check.
So how do you make an instruction file? The easiest way is to run slash init. The agent examines the repository and drafts instructions from the build commands, conventions, and files it finds. Review that draft, test the commands, and correct anything it misunderstood.
Claude Code combines instructions from several locations. It reads broader instructions before the more local ones. They need to agree, because loading a file later does not reliably resolve a conflict.
The broadest is the user-scope file in your home directory. These are your personal rules that apply across all of your projects.
Next is the project-scope file, either at the root of the repo or inside its dot-claude folder. This one gets committed to git, so it's shared with your whole team. Everyone's agent reads the same rules.
The local file holds your personal notes for this project. Add it to Git's ignore list so those notes are not included in a commit.
There are two useful additions here. An at-sign followed by a path imports another file into your instructions. That is how a CLAUDE dot M-D brings in an AGENTS dot M-D file: one line reading at-sign AGENTS dot M-D. The slash memory command opens the instruction files for editing, so you can add or fix a rule without leaving the session. It opens the auto memory folder too.
So what makes a good instruction file? Remember what it is for. It explains how to work in this repository, so the agent does not have to guess: the commands, the conventions, the layout, and the rules. Let's build one up. We'll start with a simple header naming the project.
First comes a build section with the exact commands. Here, that's how to run the tests and how to lint the code. Keep it short, aiming for under a couple hundred lines as a rule of thumb. Think of it as a cheat sheet of commands and standing rules. Leave detailed documentation in the project files.
Next comes a style section. For example, type everything, and run mypy in strict mode. Use headings and short lists to group related instructions. That makes the file easier for you to maintain and the rules easier to find.
Then comes a don't-touch section. Here, we note that the migrations folder is generated, so the agent should leave it alone. And here's the third principle. Be specific. Give exact commands and real paths, not vague wishes.
A concrete instruction gives the agent a clear action to take. Write clean code leaves many choices open. Run ruff check before finishing names a specific check. You can then look for its result in the session. Write rules you can check. Putting them in the file makes them available, but does not guarantee the agent will follow them.
Now let's see what happens when the window fills up. A long session gets there sooner than you would think, with big files and a lot of tool output. In the last video we saw that a request which no longer fits cannot be sent at all. So the harness has to make room, and it does that by compacting the conversation.
Compaction summarizes older conversation so the harness can replace a large amount of history with a shorter account. Recent material may also be kept separately. Claude Code does this automatically as the window nears its limit, and the slash compact command does it on demand. You can tell it what to keep, for example slash compact: "focus on the auth bug".
The system prompt and tool definitions remain available. They are separate from the conversation being summarized. The project instruction file is loaded again from disk. Saved notes and project files remain available, though the harness may need to read them again. For details left only in the conversation, you depend on what the summary kept.
A rule written only in chat can be lost when that chat is summarized. That is the practical difference between conversation history and an instruction file. A project instruction file can be loaded again after compaction or a clear. Put standing project rules there so you do not have to repeat them in every conversation.
Now let's look at what a large window costs. Every request sends the whole window again, but the provider can reuse work on an unchanged beginning of the request, called the prefix. That is prompt caching: the repeated text is still supplied, but its computation does not have to be repeated while that cache is usable. That is why a long session can still feel quick. Most of the window was processed on an earlier request.
If the cached work expires or the prefix changes, the model has to process the uncached input before it can answer. In the full attention pattern we saw earlier, each token position uses the positions before it, so a longer input means many more comparisons. When the window is very full, that is a lot of computation before the first output token. A bigger uncached input means more processing time and more input tokens to pay for.
There is a second cost, and it is about quality. Research shows that models do not use a long window uniformly. A well-known study called Lost in the Middle placed one relevant fact at different positions in a long context. Recall was best when the fact sat near the start or the end, and clearly worse when it sat in the middle. A more recent study from twenty twenty-five, covering eighteen models, found that performance grows less and less reliable as the input gets longer, even on simple tasks. More text in the window means more competing for the model's attention.
Fitting inside the window is only the first requirement. Long input can cost more to process, and relevant details can be missed. The next few habits help keep the context useful.
Old, unrelated conversation takes room that could hold useful project information.
So use slash clear between unrelated tasks. There's no point in dragging the previous task's context into a fresh one, where it only takes up space.
If you need to continue related work in a long session, use slash compact and name what the summary should preserve. Check that the important details survived before continuing.
Use slash context to audit what is actually filling the window when things feel crowded. It shows you where the space is going, and what percentage of the window is already used. That percentage makes the next decision more informed. If the window is mostly taken up by the task you are still working on, compact and keep going. If it is mostly old, unrelated work, clear and start fresh.
Remember that a short instruction file leaves more room for the real work, and it is in the window on every request. That's another reason to keep it lean.
Use slash clear for unrelated work, compact when you need to keep the thread of a long task, and keep the instruction file focused on standing rules. These habits help the agent work with the context it needs.
Running slash context is something you have to remember to do. There is also a way to keep that percentage in view all the time. Claude Code can show a status line under the prompt, and you decide what goes in it. This is the one I use. It shows the name of the session, which you set with slash rename, then the folder, the git branch with a count of the edited and the untracked files, the model, and how much of the context window is used. That last number turns yellow at half full and red at three quarters, so I notice it without looking for it.
The status line comes from a script. Claude Code gives it session information as JSON, including the folder, model, and context usage. The script prints the text that appears under the prompt. Later in the course you will run several agents at once, each in its own copy of the repository, called a worktree. The worktree name is in that JSON as well, and putting it on the line is how you tell the sessions apart.
You don't have to write the script yourself. Type slash statusline, describe the line you want, and a built-in setup agent writes the script and the setting for you. This is the first time in the course that you change the tool by describing the result you want, instead of editing a configuration file by hand.
What happens to the conversation when you clear the window? In a normal session, Claude Code saves the conversation on disk. Clearing the window starts a fresh conversation without deleting the saved session or undoing project files.
To jump back into your most recent session in this folder, start claude with dash dash continue, or just dash c. It loads that session's saved history. If you have started another session since clearing, use the resume list to choose the earlier one.
If you want an older session, dash dash resume gives you a list of your past sessions to pick from. And if you're already inside a session, slash resume switches you to another one without quitting.
Clearing the current window and deleting a saved session are different actions. You can use a fresh context for new work and return to a saved conversation when you need it.
Let's pull it together. The harness decides what is in the window. Before you type, it has already loaded the system prompt, the tool definitions, and the instruction files, and then the conversation fills in the rest.
Compaction shortens the conversation. Standing rules in an instruction file can be loaded again, so they do not depend on what the summary happened to keep.
Two memories cross sessions. There's the instruction file, CLAUDE dot M-D, which you write, and there's the auto memory, which Claude Code writes for itself.
The one thing to carry out of this video is that the model forgets, and managing what it must remember is your job.