Anthropic shows Claude agent memory lifts Opus 5.5 from 0.655 to 0.838 on CL-Bench
Anthropic published a research report on November 6, 2026 that measures how much Claude agents gain when they can keep written memory between sessions, and how an offline review process the company calls dreaming corrects and reorganizes that memory. On the database task of CL-Bench 1.0, where every question starts a fresh session and only a memory directory survives from one question to the next, Claude Opus 5.5 rose from a mean reward of 0.655 without memory to 0.838 with it. Claude Sonnet 5.5 moved from 0.644 to 0.833, and older models showed larger jumps from lower starting points.
The report, written by Lance Martin of Anthropic's engineering team, frames agent memory as knowledge Claude gains from experience and keeps between sessions as readable context. It deliberately excludes weight updates, in-context learning and the compaction that shortens long conversations. The memory in question is ordinary text: notes in a folder, linked wiki pages and a small file loaded at the start of every session, all of which a developer can open and inspect.
Beyond the benchmark, the study reports experiments with Claude playing Pokémon Red, a knowledge wiki built over a corpus of about 350,000 files and roughly 420 million tokens, and legal briefs graded on Harvey's LAB benchmark. The same mechanisms already ship to developers: memory stores are in public beta in Claude Managed Agents, dreams are available as a research preview behind an access request, and Claude Code loads the first 200 lines or 25 KB of its MEMORY.md file at the start of each session.
··········
CL-BENCH RESULTS FOR CLAUDE AGENT MEMORY ACROSS SIX MODELS.
The CL-Bench experiment tests memory as a form of prediction. Claude answers questions by looking up data, is then told the correct answer, and may write to a memory directory before the session ends. Because the next question opens a new session, any improvement has to come from what Claude chose to write down. Anthropic reports the mean reward on the database task for six models, with and without memory. The report does not define the reward scale beyond "mean reward" or state the number of tasks, and its chart covers 30 questions, so the figures are best read as relative comparisons between models and conditions.
........
Model | Stateless baseline | With memory | Absolute gain | Relative gain |
Claude Opus 5.5 | 0.655 | 0.838 | +0.183 | +27.9% |
Claude Sonnet 5.5 | 0.644 | 0.833 | +0.189 | +29.3% |
Claude Opus 5 | 0.564 | 0.828 | +0.264 | +46.8% |
Claude Opus 4.7 | 0.383 | 0.700 | +0.317 | +82.8% |
Claude Sonnet 5 | 0.306 | 0.610 | +0.304 | +99.3% |
Claude Sonnet 4.6 | 0.330 | 0.364 | +0.034 | +10.3% |
........
The gain columns are Data Studios calculations from Anthropic's published scores. They show two patterns. The newest models start higher and end highest, with Opus 5.5 and Sonnet 5.5 separated by only 0.005 after memory. Older models such as Opus 4.7 and Sonnet 5 nearly double or more than double their scores in relative terms, because their stateless performance is much weaker and memory lets them reuse confirmed answers. Sonnet 4.6 is the outlier at +0.034.
Anthropic describes the behavior behind these numbers model by model. Sonnet 4.6 generated theories it did not test; Opus 4.7 consolidated notes and separated confirmed from unconfirmed facts; Sonnet 5 marked answers as confirmed and wrote corrections; Opus 5 was the first model to close the full learning loop, recording rules together with evidence and warnings. Sonnet 5 read its memory before answering about nine times in ten, compared with fewer than half the time for Sonnet 4.6.
Instructions changed the results in both directions. When Sonnet 4.6 was told explicitly to read memory and test its theories, its score rose from 0.364 to 0.641, close to the gain of the stronger models. A fixed rule telling models to "record only failures" had the opposite effect on stronger models, cutting their memory gains by 0.234 for Opus 5, 0.150 for Opus 4.7 and 0.020 for Sonnet 4.6. Anthropic's guidance for frontier models is to explain what memory is for and let Claude write notes when asked or when something is clearly worth keeping, rather than prescribing how to use it.
··········
HOW ANTHROPIC LAYERS CLAUDE AGENT MEMORY: TRANSCRIPTS, NOTES, WIKIS AND INJECTED CONTEXT.
The report describes four layers. At the bottom sit transcripts, a searchable log of everything that happened in past sessions. Above them are memory notes that Claude writes itself, either by tagging salient events during a session or by saving files to a memory store. The third layer holds representations such as linked wiki pages that act as a map over the notes and source material. At the top is injected context, a small set of notes loaded into every new session so that Claude does not need to search for them.
Anthropic draws an analogy with human memory, in which the hippocampus captures experiences quickly and offline replay during sleep consolidates part of them into long-term knowledge. In the agent version, transcripts play the role of raw experience and dreaming is the offline replay. The company credits earlier work on sleep-time compute by Letta and UC Berkeley as a basis for the idea.
The top layer carries a specific cost. Injected notes consume tokens in every session, a wrong note spreads to every session that loads it, and longer instruction files reduce how closely Claude follows them, a point the report supports with Claude Code's own documentation. Anthropic's recommendation is to keep that layer small and index-like, with dreaming moving details down into lower layers and leaving links in their place. Claude Code's auto memory already applies this limit by loading only the first 200 lines or 25 KB of MEMORY.md.
··········
WHAT CLAUDE CHOSE TO REMEMBER IN THE POKÉMON RED EXPERIMENTS.
The Pokémon Red runs illustrate the problem of judging what to save before knowing what will be useful. Claude played the game with a memory folder it could read and write. Sonnet 3.7, after about 10,000 steps, had written 413 files across 225 folders totaling about 977,930 characters, logging encounters, items and non-player characters without much selection, and it earned one badge. Claude Fable 5 wrote 10 files with about 43,406 characters and earned four badges, so it kept roughly one twenty-second of the text while earning three more badges.
Anthropic's diagnosis is that Sonnet 3.7 recorded state already visible on screen, such as money and position, which goes stale quickly and duplicates what the agent can see anyway. It also spent turns reorganizing its memory: over one stretch of 17 steps it created six files, deleted nine and took no game actions. Fable 5 saved only information the game did not display, such as strategy, plans and rules it had tested, and used a global.md file as a dashboard holding its goal, its gym plan and its own rules for memory. Opus 5.5 also kept a small goal-tracking folder and finished the game.
··········
DREAMING AS A CORRECTION PASS FOR CLAUDE MEMORY NOTES.
Notes can be wrong when written or become wrong later, and later sessions tend to trust them. In one Pokémon run, a note placed the Pokémon Center on the east side of Mt. Moon. Acting on it, Claude fell off a one-way ledge three times, said it would stop after the third failure, was pushed on by the test harness's automatic reply and ended up back in Pewter City. A dreaming pass then compared the note with the transcript, corrected it, and the resumed run went back into the cave and reached Cerulean City at action 1,935. Neither the run with uncorrected memory nor the run without memory reached Cerulean City.
The report also shows dreaming filling gaps that a single session cannot see. A second pass across sessions repointed nine links that targeted a missing "escrow-agreement" page to an existing page and added three new pages: an index, an instructions email and an escalations page. That wiki grew from 38 entries and 225 links to 41 entries and 278 links. In a contract task, several agents writing into one shared table of terms overwrote each other's entries, and only 41 of 57 graded facts, or 72%, survived. When the instructions changed to one page per contract with terms quoted verbatim, all 57 facts survived and the share of brief criteria met rose from 72% to 100%.
··········
KNOWLEDGE WIKIS BUILT BY DREAMING ON A 420M-TOKEN CORPUS AND HARVEY LAB.
The largest experiment used a corpus from Stainless, a company Anthropic acquired in May: about 350,000 files and roughly 420 million tokens. Opus 5 agents ran 128 dreaming sessions in which they wrote or corrected linked pages, merged duplicates and checked claims against sources, coordinating through a shared log. The wiki grew from 103 pages and 766 links after two sessions to 222 pages and 12,893 links after 128. Answers to 25 questions were graded against criteria lists.
........
Setup (Opus 5, Stainless corpus) | Share of graded criteria met |
Wiki only, after 2 sessions | 13% |
Wiki only, after 128 sessions | 48% |
Search only | 53% |
Wiki plus search, early | 54% |
Wiki plus search, after 128 sessions | 61% |
........
The wiki on its own never matched plain search, but combining the two produced the best score and saved about 20,000 tokens per question, because Claude could start from a map instead of rediscovering structure on each query. Harvey's LAB benchmark, which asks Claude to write a legal brief from a document set, gave a mixed picture. On 24 merger questions that span several documents and require judgment or arithmetic, the wiki scored 87% against 73% for search alone. On a task with 57 criteria that were mostly findable by text search in a single deal memo, the wiki showed no clear gain. On a small 10-document, 115 KB corpus, the wiki grew to 68 pages, 255 links and 203 KB, about 1.77 times the size of its sources, with some pages left unlinked.
··········
USING CLAUDE MEMORY AND DREAMS IN MANAGED AGENTS AND CLAUDE CODE TODAY.
For developers, the research maps onto features documented on the Claude Platform. Memory stores in Claude Managed Agents are in beta on every model, on the Claude API, Claude Platform on AWS and Claude Models on Google Cloud (Anthropic managed), with the agent-memory-2026-07-22 beta header for store requests. Dreams remain a research preview available on the Claude API after an access request, and they require the dreaming-2026-04-21 header. A dream takes one memory store and between 1 and 100 past sessions, and writes a new, separate memory store; the input store is never modified, so teams can review the output before attaching it to future sessions.
........
Feature | Status | Key limits from Anthropic's docs |
Managed Agents memory stores | Public beta, all models | Up to 8 stores per session, 100 kB per memory, 10,000 memories per store |
Store attachment instructions | Public beta | Up to 4,096 characters |
Memory versions | Public beta | Kept 30 days; recent versions of live memories always kept |
Dreams | Research preview, by request | 1 to 100 input sessions; output is a new store |
Claude Code auto memory | Available | Loads first 200 lines or 25 KB of MEMORY.md |
........
Dreams are billed at standard API token rates for the selected model, and Anthropic says cost scales roughly linearly with the number and length of input sessions, so it recommends starting with a small batch. Dreams are not eligible for zero data retention or HIPAA. Memory stores attach only when a session is created, mount under /mnt/memory/, and default to read-write access. The documentation warns that an agent processing untrusted input could be manipulated into writing malicious content that later sessions read as trusted memory, and recommends read-only mounts for reference material and any store the agent does not need to change.
The study's design advice translates directly into configuration choices: store what the environment does not show, such as verified rules and plans, quote source material exactly where accuracy counts, keep the always-loaded file short and use it as an index, and schedule correction passes for information likely to change. Teams already using file-based memory in the terminal can compare these recommendations with our guide to Claude Code memory and CLAUDE.md files. Managed Agents are also offered through Google Cloud, as covered in our report on Anthropic-managed Claude deployments on Google Cloud, and the baseline gap between the two newest models is examined in our Claude Opus 5.5 vs Claude Sonnet 5.5 comparison.
··········
CLAUDE AGENT MEMORY RESEARCH: CONFIRMED FACTS AND OPEN QUESTIONS.
The published figures establish that persistent written memory raised every tested Claude model on the CL-Bench database task, that the newest models reach about 0.83 to 0.84 mean reward with it, and that the size of the gain depends heavily on how well a model reads, tests and corrects its own notes. The Pokémon, wiki and LAB experiments add evidence that selective memory beats exhaustive logging, that a correction pass can rescue a run misled by a wrong note, and that wikis help most on questions spanning many documents when combined with search.
Several points remain open. The CL-Bench results come from a single task family with an undefined reward scale and a chart of 30 questions, the Pokémon comparisons involve different models and step counts, and the wiki experiments are internal evaluations on corpora chosen by Anthropic, with no independent replication yet. The report itself lists unresolved trade-offs: notes written during a session draw attention away from the task, dreaming costs compute and its output is not immediately available, keeping every note current may be impractical, and wikis can accumulate errors or grow larger than their sources. Its own conclusion is that transcript search may remain the foundation, with representations built on top only where the extra compute pays back in accuracy or tokens saved.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
