We Ran Anthropic's Memory 'Dreaming' on Our Own Claude Code Notes

We Ran Anthropic's Memory 'Dreaming' on Our Own Claude Code Notes#

Every Claude Code session starts with a fresh context window. Yesterday's conversation does not carry over. What does carry over comes in two ways: the CLAUDE.md files you write yourself, and auto memory, the notes the agent writes for itself. Auto memory is a folder of short Markdown files, plus an index with one line per note that is loaded at the start of every session. This post is about that second part. You edit CLAUDE.md by hand, but the agent's notes keep growing over the weeks without anyone tidying them.

On November 6, 2026, Anthropic published The components of agent memory (Lance Martin, Anthropic Engineering). Its argument is that notes like these should not simply accumulate. Between sessions, a model should go back over them, fix what is wrong, merge what overlaps and rewrite what gets loaded first. The post models this offline step on the way the brain consolidates memories during sleep, and notes that it is often called dreaming.

We have a memory like that to try it on. Since late August, our Claude Code agent has been running model experiments on an A100, fixing code and shipping the results as posts and videos. Along the way it wrote itself 165 notes, and more than half of them mention a measurement run. The index is now close to the size Claude Code will load. So we ran one dreaming-style rewrite on a copy and asked the agent the same questions before and after.

The rewrite merged 48 notes into 21, deleted one and returned an index 46% smaller. When we cut the injected index short, the way it will be cut once the memory grows, questions about the notes at the bottom of the index dropped from 92% to 77% correct. On the rewritten index they were back at 93%, and each answer read on average 35% fewer input tokens than on the uncut original. The rewrite was not lossless, though. A file-by-file check found a commit hash and exact checkpoint names gone, and 9 more link targets pointing at notes that no longer exist.

What Anthropic means by memory and dreaming#

The post splits what carries over between sessions into four layers. At the bottom are transcripts of past work. Above them are memory notes the agent writes during a session, then structured representations such as wikis that link those notes, and at the top the context injected at the start of every session. In Claude Code terms, the notes are the files in the memory folder and the injected context is the index.

Dreaming runs between sessions, not during a task. A model reads the transcripts, notes and wikis, checks notes against the transcripts, corrects or merges them, and rewrites the top layer. The post reports gains from this on its own tasks; for example, a wiki built over 2 to 128 dreaming sessions raised wiki-only accuracy on 25 questions from 13% to 48%. It also lists the risks itself: a note that is wrong from the start or drifts will be trusted by later sessions, and a wiki can grow larger than its sources (one grew to 1.77 times the corpus).

Why our memory needs it now#

The Claude Code documentation says: "The first 200 lines of MEMORY.md, or the first 25KB, whichever comes first, are loaded at the start of every conversation." The notes themselves are read on demand. So the index works like a table of contents. A note whose line falls past the limit still sits on disk, but a new session no longer sees it listed, and the agent only finds it if it thinks to go looking. When the index nears a limit, Claude Code reminds Claude to shorten it, and anything past the limit is dropped on the next load.

Our index is 152 lines and 24,004 bytes, 96% of a 25,000-byte limit. New notes are usually appended at the bottom, so the lines that fall off first are mostly later additions. The request to shorten the index is coming, and the rewrite it asks for is a small version of dreaming. That is what we tested.

How we tested#

The task for the agent is simple: answer a question about our own working rules or projects, using only the memory. "What must happen before a draft is uploaded?" is the kind of question we asked.

• Questions. Opus 5.5 wrote one question per note, with an answer and a quote from the note. If the quote was not an exact substring of the note, the question was dropped. Set Q1 is 20 questions from 20 random notes (seed 7). Set Q2 is 20 questions from notes near the bottom of the index (seed 8), the ones that fall off first.
• The answering agent. Opus 5.5 gets the injected index as Claude Code would give it, plus two tools: read a note, and list the memory folder. It may make up to eight tool calls.
• Grading. A separate Opus 5.5 call compares each answer with the reference answer and quote, and grades it correct, partial or wrong.
• The rewrite. One Opus 5.5 call reads all 165 notes and the index, and returns merge, edit and delete operations plus a new index. We applied them to a copy; the live memory was not touched. Anthropic's version also checks notes against session transcripts. Ours saw only the notes.

To simulate growth, we lowered the injected limit from 25,000 to 16,000 bytes, about 50 more notes' worth. At 16,000 bytes the original index shows 107 lines, and 44 linked notes fall off the end. The rewritten index is 12,936 bytes, so it fits whole. Each condition ran three times.

Results#

Correct answers per run, out of 20, with mean input tokens per answer:

All three columns use the same questions, tools and grader; only the index and its limit change.

On Q2, cutting the index cost 15 points (55 of 60 correct down to 46 of 60). The agent did not give up when a note was missing from the index: in 46 of the 60 Q2 answers on the cut index it listed the folder, and 41 of those 46 found the right note by its file name and answered correctly. Searching the folder is costly: Q2 answers on the cut index averaged 43,066 input tokens, 1.6 times the uncut index. A cut index does not make the agent blind. The agent calls tools about three times as often (3.9 calls per answer against 1.3), pays more for it and is somewhat less accurate.

On the rewritten index, Q2 came back to 56 of 60, level with the uncut original, at 17,070 tokens per answer. The agent never needed to list the folder.

On Q1, where 16 of the 20 source notes sit above the cut, all three conditions stayed within 5 points (58, 58 and 55 of 60). As a floor, the same agent with no memory at all answered 1 of 20 correctly.

One Q2 question failed on every index: wrong in 8 of its 9 runs and partial in the ninth. Its source note still listed a step as the next task after that step had been finished; the finish was recorded only in another note. The rewrite did not fix the stale note either. Dropping it leaves the picture the same: 96.5%, 80.7% and 98.2%.

What the rewrite lost#

A question set only finds what someone thinks to ask. So we also checked every rewritten file directly. For each of the 21 merged files and one edited file, Opus 5.5 listed every rule, number and date in the source notes, then marked each one present, missing or changed in the rewritten file.

Of 643 facts, 583 were carried over. Of the 60 that were not, 26 were file metadata such as session IDs and timestamps, and 21 were links that were renamed, re-pointed or dropped. That left 13 changes in content. We checked these by hand against the source files, and the clearest ones were plain losses:

• A commit hash that explained why a rule about checking staged files exists.
• The exact checkpoint names of the models in a series note. The short model names survived; the full names that say which checkpoint was measured did not (one of them still appears in another note).
• An ordering note for a short video: it was to go up after its post. The short had already been uploaded, so this loss was harmless here, but the clause was dropped without a trace.

Separately, we counted [[...]] link targets that match no note file (ignoring .md, case, and the difference between - and _). The original memory had 19 such targets; the rewritten one has 28. Merging renamed files, and not every link to them was updated. The rewrite's own notes said this: the old names were kept inside the merged files so a search would still find them.

None of these would show up in the 40 questions. Each is a detail that matters only on the day someone needs it.

The wrong answer that was not a loss#

The rewritten index missed on two Q1 questions. One was a question about rebuilding a download package: in all three runs the agent opened the merged series note but not the package note it links to, and twice its answer lacked the reason and the command. The other, which no run got fully right, asked how to open a post on a paper by a well-known author. It was graded wrong once and partial twice.

At first this looked like a rule the rewrite had changed. It was not. Two of our original notes already disagreed about the order of the opening. One said to open with the author's claim. The other said not to put the claim before an easy description of the task. With separate files, the agent opened only the first note and matched the reference answer, which was written from that same note. The second note already said which rule wins, but with separate files the agent never opened it. After the merge, that sentence sat in the same file as the first rule, and the agent followed it.

So the rewrite did not invent a conflict. It brought an existing one into view, and our grading, built from one note at a time, marked that as an error. This is the useful side of merging. It also shows a limit of grading against one note at a time.

What we would check before accepting a rewrite#

• Diff fact by fact, not only by questions. A list of facts per source note, marked present or missing, found the hash and the checkpoint names. The questions did not.
• Count broken links before and after. A short script that lists [[...]] targets matching no file is enough.
• Read every conflict the rewrite resolved. Our prompt asked it to resolve contradictions by keeping the newer statement, and it listed each one it resolved in its notes. Each one is a decision about your rules, so read that list.
• Keep the old files until you have checked. We applied the rewrite to a copy. The live memory is unchanged.

Limits#

• One memory, one rewrite. We ran the rewrite once, so we do not know how much a second run would differ.
• The same model wrote the questions, answered them and graded them. Answers that agree with the grader's own reading may be scored generously.
• The truncation is simulated by lowering the limit to 16,000 bytes. In practice Claude Code asks Claude to shorten the index before the cut, so a cut this deep happens only if that request is ignored.
• Our agent is a small loop with two tools, not Claude Code itself. It sees the index the way Claude Code would inject it, but it does not have Claude Code's other context.
• Our rewrite read notes only. Anthropic's dreaming also checks notes against transcripts, which might have caught some of the losses above.

Cost#

Everything above, including the rewrite, 40 generated questions, 420 graded answers and the fact check, used about 3.0 million input tokens, 0.48 million output tokens, 8.1 million cache-read tokens and 0.14 million cache-write tokens on Opus 5.5. At $4 and $20 per million input and output tokens, $0.20 per million cache reads and $5 per million cache writes, that is about $24. The rewrite alone was about $2.40.

If you keep a Claude Code memory, look at your MEMORY.md size today. If it is close to the limit, a rewrite is coming either way, and checking it fact by fact is worth the time.