Does more AI memory make it smarter? Claude kept 413 files and got only one badge
Anthropic has Claude “dream” during idle time, organizing memories and correcting mistakes. In a Pokémon experiment, one model wrote 413 memory files and earned only one badge, while another wrote just 9 files and earned four. With memory, more is not necessarily better.
During human sleep, the hippocampus replays the day’s experiences, gradually settling short-term experiences into long-term knowledge. Anthropic moved this mechanism onto AI agents and named it dreaming, which can be understood in Chinese as “dreaming.”
Simply put, agents leave behind a large number of logs and records during interactions. Dreaming means using idle time to go back through these logs, organize them, correct errors, and distill reusable rules or notes. Anthropic described this process in detail in an engineering blog post, as well as how they measure whether it is actually useful.

They divide agent memory into several layers: at the very bottom are the raw conversation transcripts; above that are the memory notes Claude writes itself; above that are structured representations such as a wiki; and at the very top is the context preloaded for every session. Dreaming’s role is to move information up and down among these layers, letting what is needed float up and letting what is too trivial sink down.
The reasoning sounds smooth. What is really interesting is the problems exposed by the experiments.
The one that remembered too much got stuck instead
Anthropic had Claude play Pokémon Red. For AI, this game is a long-horizon task that requires navigation, combat, and remembering map and item locations. At the start, each model has a memory folder it can read from and write to.
They compared the memory states of Sonnet 3.7 and the later Fable 5 at roughly ten thousand steps.
Sonnet 3.7’s strategy was to record everything it could. It created a separate file for each battle fought, each item picked up, and each NPC encountered. In the end it wrote 413 memory files spread across 225 folders, and its game progress was one badge.
Fable 5 wrote 9 files in two folders, plus a top-level global.md, and its progress was four badges.

The problem is not “remembering too much” itself. The problem is that Sonnet 3.7 recorded a large amount of state information that expires quickly, such as how much money it currently had and which map it was on. This information was visible on screen every turn; storing it was both redundant and prone to becoming outdated. It spent more and more time going through memories, and instead had no time to play the game. At around ten thousand steps, it spent 17 consecutive steps adding and deleting memory files and did not move a single step in the game.
Fable 5 used memory for things the game would not directly tell it: strategies, plans, and rules discovered through trial and error. global.md was like a dashboard, containing the current goal, the gym challenge plan, and its own rules for using memory. One example was quite specific: after failing to catch a Magikarp with seven Poké Balls in a row, it wrote, “If more than 3 balls fail in a row, change the rhythm and press wait more between menu steps.”
Things like this disappear if not written down; only when written down do they compound.
A single erroneous note can trap an agent in the mountains
What happens when a memory is written incorrectly? One use of dreaming is to go back and verify notes against the raw logs.
In the same Pokémon experiment, Claude needed to cross Mount Moon. Near the mountain entrance there was a one-way ledge; falling down it would slide it back to the previous path. Claude misremembered the location of the Pokémon Center at the mountain entrance, recording it as being on the east side of the mountain. When it walked out of the Center, it announced that “Mount Moon is behind me,” marked the task complete, then headed toward the next city and promptly fell down the ledge.
The navigation tool did not show this drop, so Claude thought it had gone off course and turned back. This repeated three times, and it wrote in its records, “I plan to stop and not loop anymore.” The experiment framework automatically replied telling it to continue, and it retreated all the way back to an earlier town. That run never reached the target city.

After dreaming ran once, Claude compared against the raw logs, realized it had recorded the Center’s location backward, and rewrote the note. On the next run, it walked directly back to the cave entrance and later reached Cerulean City.
The key here is that the logs provide ground truth. A model cannot know out of thin air that it remembered something incorrectly; it needs an original record it can go back and compare against.

A wiki is not necessarily better the bigger it gets
Anthropic also tried using dreaming to let Claude build a wiki by itself. They used the internal documents of an acquired company, Stainless, as the corpus: about 350,000 files and 420 million tokens. Claude built and maintained the wiki incrementally across 128 sessions, and its score on answering 25 questions rose from 13% to 48%.
But a wiki is not a panacea. In Harvey LAB’s legal document task, if a question required synthesizing judgment across multiple documents, the wiki clearly helped: the score was 87%, versus 73% for pure search. If the answer could basically be found by searching a single document, the wiki had no clear advantage.
An even more awkward situation also appeared. In one task, the wiki Claude built was larger than the original documents: 10 documents totaled 115KB, while the wiki grew to 203KB, expanding to 1.77 times the size. Anthropic used Borges’s one-page short story as an analogy: drawing a map as large as the empire equals abstracting nothing at all.

There is also a pitfall in multi-agent collaboration. In a merger-and-acquisition contract task, several agents simultaneously wrote content to the same shared clause page, overwriting one another, and in the end only 41/57 scored facts were preserved. After changing it so that a single agent was responsible for each contract and quoted clauses verbatim, all 57 were preserved.
This shows that failures in memory systems are often not because the model cannot remember, but because collaboration and abstraction-layer design are poor.
Tell it “why to remember,” not “what to remember”
Anthropic tried something on the CL-Bench database task: adding a rule telling the model to “record only failures.” As a result, Opus 5’s performance gain from memory dropped by 0.234, and Opus 4.7’s dropped by 0.150. The rule instead weakened the value of memory.
Their lesson was that telling Claude what memory is for and leaving the power to judge what is worth remembering to the model works better than presetting fixed rules. For older models, appropriate guidance was indeed useful; for example, reminding Sonnet 4.6 to read memory before answering nearly doubled its score. But new models basically read it on their own.
Behind this is a rather subtle shift: memory itself is a prediction about the future. Writing down a rule is equivalent to betting that it will be useful again later. A model’s ability to judge what is worth remembering is essentially its ability to judge what will recur. At present, this kind of judgment is more reliable when left to the model than when hard-coded by humans.
Unresolved problems
Anthropic itself listed several open questions. When should memory be written? Writing on the spot can capture details, but it interrupts the main task; writing during dreaming does not take up current attention, but the output cannot be used immediately. How can memory be kept from expiring? Full verification is too expensive, so the pace of dreaming may need to be decided by access frequency or the rate at which information changes.
There is also a fundamental contradiction: no model can truly know what will happen in the next few turns. Dreaming offers a chance to look back, trading compute for organization and error correction. Memory systems will change along with model capabilities, and it is far too early for conclusions.
If forced to distill it into one sentence, it would be roughly this: making an agent remember more things is not hard; making it remember the right things, and know when not to trust what it remembers, is the hard part. Those 413 files from Sonnet 3.7 are the reminder.
Reference source: Anthropic Engineering Blog, The components of agent memory, November 6, 2026.
发布时间: 2026-11-07 13:29