Two hours in, continuity snaps.
Long sessions with a stateless model follow a documented shape. A session starts sharp: the model tracks the current task, the decisions made so far, and the reasoning behind them. After some hours of work, commonly cited around the two-hour mark in long coding sessions, that tracking degrades. The model re-asks questions already answered, proposes code that contradicts what it wrote earlier, and loses track of decisions made only a few turns before. Practitioners have taken to calling this pattern "context rot," a term in wide enough use across 2026 discussion of long agent sessions to serve as a shorthand rather than a term coined here.
The pain is not hypothetical. One widely shared practitioner account describes losing a four-hour Claude Code session to exactly this pattern, then building a small, no-cost fix to avoid a repeat. Similar accounts recur often enough that the underlying problem, not just this one instance of it, is the fact worth taking seriously.
What native compaction keeps and drops.
The standard mitigation for a filling context window is compaction: a summarization pass condenses the transcript so the session can continue inside a smaller footprint. Anthropic's own documentation on the mechanism describes what a compaction summary retains: the request and intent behind the work, the technical concepts involved, the files touched, the errors encountered and how they were fixed, and the pending tasks and current state. It also describes what is necessarily discarded: the full tool outputs and the intermediate reasoning that produced the kept summary.
This is compression, not preservation. Everything the summary keeps is useful. Everything it drops is exactly the material (the dead ends explored, the backtracks taken, the reasoning steps between a question and its answer) that made the kept conclusion trustworthy in the first place. A model resuming from a compaction summary reasons from the same kind of lossy digest a reader gets from a changelog: the what survives; the why and the how mostly do not.
What people already do about it, by hand.
Practitioners have converged on a manual mitigation independent of any single tool: a small set of plain-text files, commonly a CLAUDE.md, a PROGRESS.md, and a TASKS.md, or similarly named plan, context, and task files, maintained by hand alongside the code specifically to persist task state outside the conversation. The pattern recurs across independent write-ups, which suggests it fills a real gap rather than reflecting one team's habit.
The pattern deserves to be taken seriously rather than dismissed. A hand-maintained set of files is a crude, untyped, unlinked version of the same underlying move a shared substrate makes structurally: write state somewhere durable, outside the window, so a later session can pick it up. See CLAUDE.md and filesystem-as-memory for a closer look at this comparison. The difference is discipline against structure: a flat file persists only as well as someone remembers to update it, and offers no types, no links, and no way to query it short of reading it in full.
Inverted.
On substrate memory, the same event looks different. Integration (the decisions made, the reasons behind them, and the links between one finding and the next) is written to the shared graph as the work happens, rather than assembled from the context window afterward. The context window holds working memory only; the record of what mattered already lives elsewhere by the time a compaction would run.
This does not make native compaction lossless. The in-window summary compaction produces is still the same kind of condensed digest described above. What changes is what is at stake when the digest is produced. A session boundary, whether a fresh session, an account switch, or a mid-session compaction, no longer threatens the project's accumulated state, because that state was never held only inside the window being compacted. Cold start and post-compaction recovery become the same operation: read back the graph.
A session boundary, in this arrangement, is inexpensive: what is lost is a scratch working area, and what is needed next is already written down in a form built for retrieval. The same property is part of what makes horizontal coordinationacross many small-context agents practical, since each agent's session boundaries are equally cheap to cross.
Recovery, concretely.
The recovery path is short enough to describe concretely. A new or resumed session runs three calls in sequence.
| Step | Description |
|---|---|
| declare_focus | States which branch or thread the session is picking up, so the briefing that follows is scoped rather than generic. |
| get_briefing | Returns a synthesized packet assembled from the graph: project state, conventions, open work, and recent peer activity, curated for a cold start rather than handed over as raw entries. |
| targeted search | Follows up on anything the briefing packet references without fully resolving, using the graph's typed structure rather than re-reading a transcript. |
An early demonstration of the arc, dated 2026-05-12, resumed a session after an account switch, with no chat memory carried over and the project's local prose files (of the kind described above) five days stale and confidently wrong about a launch date. Recovery took roughly five tool calls and about 25,000 to 30,000 tokens of reading, across two response turns, with no additional time asked of the person supervising the session. The session absorbed a launch-posture correction before producing any output built on the stale framing.
This is the same mechanism that lets cross-session recognition happen turn by turn: recognizing a prior decision is the recovery arc running at the scale of a single lookup rather than a full cold start.
Why this is hard to copy.
Four properties, taken together, are what make the recovery arc above routine rather than exceptional. Existing approaches to model memory generally satisfy some of the four and not all.
| Property | Description |
|---|---|
| typed | Entries are navigable by kind, a decision, a finding, a supersession, rather than located by matching strings in a document. |
| live-written | Integration is written to the graph as the work happens, so it is already there by the time a compaction or a new session needs it, rather than produced from context about to be discarded. |
| cross-vendor | The record survives a change of client, model, or account, because it lives outside any one of them. |
| cold-start-optimized | A synthesis step built and tuned for orientation already exists, rather than being assembled ad hoc from whatever the new session happens to read first. |
Memory stores built primarily for retrieval are typically typed but not live-written: they extract structure from a conversation after the fact rather than having it already integrated by the time a compaction or a new session needs it. The hand-maintained flat-file pattern described above is live-written but neither typed nor cold-start-optimized: the file updates as the work happens, but a new session still has to read and re-parse it in full rather than receive a synthesized packet.
Common questions.
Does this mean compaction stops losing anything?
No. The in-window summary a compaction pass produces is still a condensed digest of the window it replaces, for the reasons described above. What changes is what depends on that summary: the project's accumulated state lives in the substrate, not only in the window, so losing detail inside one compacted window does not put it at risk.
Is every cold start this fast?
The numbers above describe one dated demonstration, not a guaranteed figure. The shape generalizes: a short, bounded sequence of calls rather than a full transcript re-read, though the exact tool-call count and token total vary with how much a given session needs to catch up on.
Why not just avoid compaction by keeping sessions short?
Keeping sessions short, and compacting proactively before quality degrades, are both common practitioner disciplines for managing a window's contents. The inversion described here is architectural rather than a discipline: it changes what a compaction event puts at risk, rather than asking someone to time it more carefully.