ProductNot yet confirmed elsewhere1 publisher2 min readPublished
Anthropic's dreams job merges duplicate agent memories into a second store
Anthropic's dreams job reads an agent's memory store and 1 to 100 past sessions, then writes a reorganized copy. The original is never modified, so a team can review the copy and discard it.
The Product Desk
What happened
- A dream runs asynchronously and typically takes minutes to a few hours, depending mainly on how many transcripts it is given.
- The output store's ID appears in the dream's outputs array only after the workflow clones the input store, so a running dream can briefly report an empty array.
- During the research preview, the documentation lists nine supported models, including claude-opus-5-5 and claude-sonnet-4-6.
- The dream resource reports four token counters: input, output, cache read and cache creation. All four read zero in the example response while the job is pending.
Why it matters
- decision Attaching the finished store, either in place of the input store or alongside it, is the step that changes what the agent remembers next, so someone has to sign off on the review before it happens.
- constraint Instructions steer a synthesis pass, so line-level corrections go through the Memory Stores API on the output store after the run.
- capability The pipeline runs as a session whose events can be streamed and which is archived when the job ends, so a reviewer can see what a dream read and wrote.
A team that has run an agent through many sessions ends up with a memory store that repeats itself and sometimes contradicts itself [1]. Anthropic's documentation explains it this way: agent writes are local and incremental [1]. A dream also surfaces new insights from the transcripts it reads, on top of merging duplicates and replacing stale entries [2]. In our view those insights are the entries to read first. A merged duplicate can be compared with the input store, and a new insight has nothing there to compare with.
Instructions are the other control, and they work as a retention policy. The documentation says the optional field is applied throughout the pipeline, including what to merge or drop [7]. Its example is "Focus on coding-style preferences; ignore one-off debugging notes." [12] Whoever writes that sentence decides what the agent stops carrying into later sessions.
Cost is the open item. The portion of the documentation we reviewed does not state a price per dream. Because the session count is adjustable [4], a first run on a handful of sessions will show through the usage counters what a job consumes before a team commits to a large one.
To decide how far to trust an output store, sort its changes on two questions. The first is whether a wrong entry could be spotted by reading the store alone or only by going back to the transcripts. The second is whether a wrong entry would change what the agent does in its next session.
If a wrong entry is easy to spot and low in consequence, skim the output and attach it in place of the input store [11]. If it is easy to spot and high in consequence, read every entry before attaching anything. If it is hard to spot and low in consequence, attach the output alongside the input store [11]. If it is hard to spot and high in consequence, keep the input store live, since the documentation says a dream never modifies it [3], until someone has checked the entries against the transcripts.
What to watch
- Whether Anthropic publishes a per-dream price once the research preview ends.
- Whether the list of nine supported models changes as the preview continues.
- Whether users report that surfaced insights hold up when checked against the source transcripts.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence40
- Adoption
- Insufficient
- Hype gap−5
- Incentives
- Insufficient
- Confidence70
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Agents write to their memory stores as they work, but these writes are local and incremental, so over many sessions a memory store accumulates duplicates, contradictions, and stale entries.
- [2]
A dream reads an existing memory store alongside past session transcripts, then produces a new, reorganized memory store with duplicates merged, stale or contradicted entries replaced with the latest value, and new insights surfaced.
- [3]
The input memory store is never modified by a dream, so the output can be reviewed and discarded if the result is unwanted.
- [4]
A dream is an asynchronous job that takes a pre-existing memory store and 1 to 100 sessions, which are past transcripts Claude mines for patterns and insights.
- [5]
The output store ID appears in the dream's outputs array shortly after the dream starts running, once the workflow has cloned the input store, so a running dream can briefly report an empty outputs array.
- [6]
During the research preview, the supported models are claude-opus-5-5, claude-fable-5-1, claude-opus-5, claude-fable-5, claude-opus-4-8, claude-opus-4-7, claude-sonnet-5-5, claude-sonnet-5, and claude-sonnet-4-6.
- [7]
The optional instructions field steers what the dreaming pipeline synthesizes and is applied throughout the pipeline: what to read closely, what to merge or drop, and how to structure the output store.
- [8]
The pipeline is a synthesis pass over the inputs, not an editor applied to the text of the store, so imperative directives that target specific lines, such as 'change sentence X to Y', generally produce no change; targeted edits to individual memories go through the Memory Stores API on the output store directly.
- [9]
Dreams run asynchronously and typically take minutes to a few hours, driven by the number of input transcripts.
- [10]
Once a dream is running, its session_id field points at the underlying session running the pipeline, whose events can be streamed; the session is archived, not deleted, when the dream reaches a terminal state, so the transcript remains available.
- [11]
When a dream's status reaches completed, the output is an ordinary memory store in the workspace that can be reviewed with the Memory Stores API or in the Console, then attached to future sessions in place of or alongside the input store, or discarded by deleting or archiving it.
- [12]
The documentation's example instructions string is "Focus on coding-style preferences; ignore one-off debugging notes."
- [13]
The dream resource includes a usage object with input_tokens, output_tokens, cache_read_input_tokens and cache_creation_input_tokens, all shown as 0 in the example response with status pending.
ReportedSupportedSource: Claude Platform documentation, dreams page example responseView cited source - [14]
The documentation lists nine models supported for dreams during the research preview.
Sources
1 independent publisher whose own reporting we read for this story.
- platform.claude.comIn the documentation
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.