Putting an agent to sleep costs 36 cents, and the next day it remembers things you haven't seen

A couple of days ago, Brad Abrams posted on X: your agent should get some sleep.

It comes with a Claude Cookbook called Dreaming with a dynamic workflow. What it does is very concrete: export the sessions an agent has finished running as transcripts, batch-distill them at night into a set of wiki-style memory files, and the next day, when the agent starts a session, mount them read-only so it knows from the outset what happened before yesterday.

What it looks like when it runs

The process has three steps. Export sessions, one plain-text file per session. A lead agent reads your natural-language instructions, writes a workflow itself, and then starts a workflow run: for each transcript it dispatches an analyzer; each one reads, verifies, and adds facts to a shared memory directory. After all analyzers finish, an organizer runs once to merge duplicate files, fix links, and fill in _index.md. Finally, your business agent mounts this store as read_only.

The model split is Sonnet 5.5 leading, with Haiku 5.5 running the analyzers and organizer. The analyzers have only five file tools—read, write, edit, glob, and grep—with no shell, no network, and an empty environment allowlist. This configuration wasn't written casually; more on that later.

Three hard parts

The Cookbook uses a fictional Python project, tidewick, as an example: 11 transcripts, 283 KB. It plants three kinds of trouble:

First, facts expire. Early in the project, make test required setting TIDEWICK_DATA_DIR first in order to pass; a later version removed that dependency. If an analyzer simply copied “to run tests, set TIDEWICK_DATA_DIR” into memory, the next session would start work with a piece of wrong common knowledge. So the rules require dating facts, marking their source, and, where possible, noting “superseded by which version.”

Second, key details are buried in tool output. Exact command lines, flags, and filenames are scattered among the return values of dozens of transcripts. The quality of distillation depends mainly on whether these are dug out verbatim, not on whether the summary sounds plausible.

Third, multiple analyzers are writing to the same directory at the same time. Two files might be overwritten by two agents in the same second. The rules say: after every write, read it back to confirm your own content actually landed on disk; if you read someone else's version, merge the two sides, write again, and verify again. Only the organizer does merging and renaming at the end; in the middle, no renaming and no moving directories, because others are writing.

These three points determine that “letting an agent sleep” is not a summarization task. It is closer to a consistency engineering problem for concurrent writes—except the writers are models.

Costs are lower than expected; risks are higher

The 11 transcripts ran in 2.5 minutes for $0.36, of which the lead cost $0.17, the 11 analyzers together cost $0.16, and the organizer cost $0.03. The Cookbook gives another number: more than 50 long sessions, about 12 MB of text, takes about $8 and ten minutes per run with default settings.

That price makes people let their guard down. What you should really look at is this: by default, there is no review. The nightly script runs via cron at 1 a.m., and when dreaming finishes, it writes directly back to the same store your agent is reading. When you open your computer in the morning, the agent's memory has already been changed by a transcript no one has looked at.

The Cookbook itself acknowledges this and offers mitigations: before each run, copy the store's files into a records directory; each write is a memory version retained for 30 days, which can be reviewed and rolled back. But all of this is after the fact.

There is another subtler point. The analyzer's system prompt explicitly says “never copy secrets into memory,” but that relies on the model obeying, not on a mechanism. The only real line of defense in the whole process is: no shell, no network, and write permission only on the memory directory. In the worst case, a poisoned transcript changes something in the store and burns your budget—that's all. The premise is that you do not stuff the store text into the system prompt. Once you do, injected content will enter every session.

A few voices from the community

Ray Amjad said he built a similar system himself; the difference is that every fact carries a source pointer back to the original session stored in S3, and when there is a conflict, it goes back to the source to decide rather than letting the organizer guess. He also “dreams” about the working habits of different team members, puts them in a separate folder, and occasionally reads the agent's descriptions of itself.

Alan Blair's comment was more direct: expensive, and a bit messy. He thinks that within weeks to months, this thing will either be cut or merged into Claude's core features.

Someone also dug up the Letta team's April 2025 paper Sleep-time Compute (arXiv:2504.13171, authors Kevin Lin et al.). The paper is about letting the model think offline before receiving a query, anticipating what the user will ask and precomputing some quantities. The result was that on Stateful GSM-Symbolic and Stateful AIME, it reduced the test-time compute needed to reach the same accuracy by about 5x; adding more sleep-time compute further improved accuracy by 13% and 18%; and if there is a set of related questions on the same context, the amortized cost per query drops by 2.5x.

In direction, the two things are not exactly the same. The paper is anticipatory—guessing what you will ask; Claude's cookbook is hindsight—looking back at what has already happened. But the underlying assumption is the same: inference does not necessarily have to happen during the few seconds the user is waiting.

A judgment

The word “dreaming” makes it easy to think there is something mystical about it. Looking at the open source, what it does is plain: batch-read text, extract facts, deduplicate, date-stamp, and maintain an index file. The real value is not in the concept but in the organization: facts carry dates, conflicts are explicitly marked without guessing which one is right, merged files are left as empty shells with MOVED TO [[slug]], and _index.md serves as the entry point. These practices are independent of which platform it runs on and can be copied.

Alan's line that it will “sooner or later be merged into core features” is probably right. When a feature's core asset is a few carefully written prompts, it is only a matter of time before it becomes a built-in platform capability. But before that, the more worthwhile part of this cookbook is how it handles concurrent writes, how it marks facts as stale, and how it keeps the organizer from inventing facts. These are problems anyone building their own agent memory will run into, regardless of whether it is Claude.

One final reminder: before you install that nightly cron, think clearly about whether you are willing to let a transcript no one has reviewed change the memory your agent will use tomorrow while you sleep. If you are, that 36 cents is well spent. If not, the Cookbook offers another path: first run it manually into a new store, read it, and then switch over.