Session ≠ Context Window
Session logs are persistent event streams; the context window is temporary working memory — they must be separated
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Session ≠ Context Window”?
Session logs are persistent event streams; the context window is temporary working memory — they must be separated
Make the claim earn its place. Use this page as a decision aid, not a definition to memorize. Connect the idea to one real task, one observable result, and one failure that would change your mind.
Write one question you could answer with evidence after trying this idea.
A conclusion that sounds complete but leaves the key assumption untested.
- 1 Both Compaction and Trimming are irreversible operations — once compressed, the original details are gone forever
- 2 At compression time, it's impossible to know which Tokens will matter later — today's seemingly irrelevant detail may be the basis for tomorrow's critical decision
- 3 If the original information is lost after compression, it can never be recovered — this is a fundamental constraint of information theory
The correct approach: raw events are stored permanently in the Session, while the Context Window is just a temporary viewport into the Session. Losing the Context is fine — the Session persists, and you can always rebuild from it.
Just like an object in a REPL, the LLM can write code to query and filter events from the Session. The Brain can start reading from any position, rewind to a specific point in time, or re-read the context surrounding a past decision.
- Optimize Prompt Cache hit rate: keep prefixes stable to reduce redundant Token computation costs
- Context engineering: selectively include the most relevant historical events based on the current task type
- The Harness is swappable: different models may need different context strategies; swapping the Harness doesn't affect the Session
| Dimension | Context Window | Session |
|---|---|---|
| Persistence | Temporary, discarded after use | Permanent, durably stored |
| Contents | Curated Tokens | All raw events |
| Operation | Read-only (from Claude's perspective) | Append-only |
| Size | Limited (model's max window) | Unbounded |
| Purpose | Current inference | History replay, state recovery |
You wouldn't load all your files into RAM at once — that would overflow it. By the same logic, you shouldn't stuff all historical events into the Context Window — that would overflow your Tokens. The correct approach is load on demand: store everything in the Session, pull a subset into Context.
Why “Two easily confused concepts” depends on the operation
“The correct approach: raw events are stored permanently in the Session , while the Context Window is just a temporary viewport into the Session.” makes the structure concrete. The useful comparison is not which name sounds more advanced, but how the data is arranged and how far the most common operation has to travel.
Read a structure through access and change
“Just like an object in a REPL, the LLM can write code to query and filter events from the Session.” exposes a trade-off that is easy to miss: reading by position, looking up by key, adding at either end, inserting in the middle, and traversing relationships do not favor the same organization. A structure that is fast for one operation is not automatically fast for all of them.
- 1 Both Compaction and Trimming are irreversible operations — once compressed, the original details are gone forever
- 2 At compression time, it's impossible to know which Tokens will matter later — today's seemingly irrelevant detail may be the basis for tomorrow's critical decision
- 3 If the original information is lost after compression, it can never be recovered — this is a fundamental constraint of information theory
Count scale and update frequency together
Use “You wouldn't load all your files into RAM at once — that would overflow it.” as a boundary check. Write down the data size, the dominant operation, and the latency you can accept before deciding whether an AI-generated structure actually fits.
From “Two easily confused concepts” to “Why they must be kept separate”
“Two easily confused concepts” grounds the problem in “Temporary / Limited Context Window The Tokens Claude can currently see. Like human working memory : limited capacity, forgotten when full. Built at the start of each turn, discarded when done. Curated content f…”. “Why they must be kept separate” then moves it toward “The correct approach: raw events are stored permanently in the Session , while the Context Window is just a temporary viewport into the Session. Losing the Context is fine — the Session persists, and you can al…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
When you meet a new data structure, do not begin by memorizing its definition. Write down the most frequent operation, estimate scale and update behavior, and check whether the structure satisfies all three conditions.
- “Two easily confused concepts”: Temporary / Limited Context Window The Tokens Claude can currently see. Like human working memory : limited capacity, forgotten when full. Built at the start of each turn, discarded when done. Curated content f…
- “Why they must be kept separate”: The correct approach: raw events are stored permanently in the Session , while the Context Window is just a temporary viewport into the Session. Losing the Context is fine — the Session persists, and you can al…
- “The closing point”: Context engineering : selectively include the most relevant historical events based on the current task type
The final “The closing point” brings the discussion to “Context engineering : selectively include the most relevant historical events based on the current task type”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.