Google Research has proposed a way for language models to keep learning after deployment by borrowing from biology: give the model a sleep phase. In a new post, Ali Behrouz and Vahab Mirrokni describe a framework where the model periodically stops processing new input, consolidates short-term memory into long-term parameters, and then generates synthetic "dream" data to train on. The reported results span translation of unseen languages, ten-million-token context, factual recall and competition math. They are the authors' own numbers, and the post offers no independent replication.
TL;DR: questions and answers
| Question | Answer |
|---|---|
| What is it? | A continual-learning scheme with active and sleep phases |
| Who wrote it? | Ali Behrouz (Google, Cornell) and Vahab Mirrokni (Google), with Farnoosh Hashemi and Adel Javanmard on the paper |
| Core trick? | Distill short-term memory into pre-allocated low-rank expert parameters |
| Second trick? | Dreaming: filtered synthetic samples for further fine-tuning |
| Can I run it? | No release is described in the post |
| How strong is the evidence? | Authors' benchmarks only |
The problem: models freeze at their cutoff
A deployed LLM knows what it knew at training time. Everything you tell it later lives in the context window and disappears when the session ends. Updating weights on new data is the obvious fix, but naive fine-tuning causes catastrophic forgetting: new learning degrades old skills. Researchers have attacked this with adapters, replay buffers, retrieval, and external memory.
If you build agents, you have already met the workaround. Teams bolt on memory files, vector stores and handoff notes, as in our guide to shared memory between Claude Code and Codex, and argue about whether agents need memory or documentation. The sleep framework asks a different question: can the model itself absorb what it learned today so that tomorrow it simply knows it?
How the sleep framework works
Google describes two stages.
Memory consolidation
During the sleep phase the model "pauses processing new inputs and redirects its internal computations toward memory consolidation," in the post's words. It unlocks pre-allocated Mixture-of-Experts capacity: low-rank experts attached to lower-frequency memory blocks, so older parameters are not overwritten. Short-term memories are distilled into these parameters using Generalized Knowledge Distillation combined with reinforcement-learning-based imitation. The post describes a reward based on semantic and Levenshtein-distance similarity to teacher text. When consolidation finishes, the high-frequency temporary parameters are reset, clearing room for the next active period.
Think of it as a two-speed memory. Fast, temporary parameters capture the day's context. Slow, protected parameters hold what has been consolidated.
Dreaming
In the second stage the model generates synthetic training samples while the MoE router randomly activates non-standard experts. Samples are filtered by gradient-based selection, and the model is fine-tuned on the top-rated ones. The authors say this works by broadening the set of gradient directions explored during synthetic generation. The aim is to rehearse and generalise what was learned, as sleep is thought to do in brains. The neuroscience framing is an analogy; the system still runs in a fixed architecture under human-defined training rules.
What results are reported
All of the following are from the Google Research post:
| Task | Reported result |
|---|---|
| Continual translation of unseen languages (Manchu, Kalamang) | Near-zero performance drop across stages, while in-context learning, Cartridges and SFT show severe forgetting |
| BABILong long context | Near-perfect scaling up to 10M tokens, ahead of GPT-4 and Titans |
| Factual knowledge (SQuAD, continued pre-training) | 48.9% single-task and 46.2% CPT, ahead of base model, SFT and SEAL |
| Math reasoning | 79.2 on AIME 24, 69.0 on AIME 25, 46.1 on HMMT 25, ahead of SFT, GRPO and OPSD |
Two cautions. First, the post describes forgetting and long-context results qualitatively, without figures in the text, so the size of the gains over each baseline is hard to judge. Second, the baselines (SFT, GRPO, OPSD, SEAL) are the authors' choices, and setups matter enormously in continual-learning papers.
Reading the benchmarks in plain language
Each result in the table tests a different kind of retention, so it helps to know what they ask of a model.
- Unseen languages (Manchu, Kalamang). These are languages with little or no web text, so a base model cannot already know them. Teaching one after another and checking that earlier languages survive is a clean forgetting test. Near-zero drop means the model kept earlier languages while learning later ones.
- BABILong. A long-context benchmark that hides facts inside very long distractor text and asks reasoning questions about them. Reaching ten million tokens is far beyond ordinary context windows, which is why the claim stands out. It is also why independent testing matters: long-context claims often shrink under different prompts.
- SQuAD and continued pre-training. Factual questions about passages the model absorbed. The post reports 48.9 percent after a single task and 46.2 percent after continued pre-training, ahead of the base model, supervised fine-tuning and SEAL, a self-adapting approach. The absolute numbers are modest; the point is the comparison with baselines.
- AIME and HMMT. Competition math. Here the claim is that dreaming plus consolidation improves reasoning over SFT, GRPO and OPSD, which are standard fine-tuning and reinforcement recipes. Note that the post gives the scores but not the underlying model size in the text we reviewed.
A worked example
Imagine a support agent deployed for a software company. On Monday a new product feature ships. With today's approach you either retrain, paste documentation into every prompt, or fetch it by retrieval. Under the sleep framework, the agent would spend the day with the new documentation in short-term, high-frequency parameters. Overnight it would pause, distil that context into protected low-rank experts, rehearse by generating and filtering practice questions about the feature, and then reset the temporary parameters. On Tuesday it would answer without re-reading the docs, and still remember last quarter's features.
That is a thought experiment built from the post's description, not a demo Google has shown. It does highlight the open engineering questions: how long a sleep takes, how much compute it costs, and who decides when it runs.
Questions to ask when replication arrives
- Does forgetting stay near zero after dozens of sleep cycles, not just a few stages?
- What is the compute cost of a sleep phase compared with simply retraining or fine-tuning with replay?
- Does the gain hold on models that were not designed with this architecture?
- How does dreaming behave when its own filtering is wrong, and can bad samples be detected?
- Can a deployer inspect or roll back what a sleep cycle changed?
How this compares with other approaches
| Approach | Where knowledge lives | Trade-off |
|---|---|---|
| Long context | In the prompt | Cost grows with length; nothing persists |
| RAG / memory files | In an external store | Retrieval errors; per-query overhead |
| LoRA per task | Adapter weights | Many adapters to manage; limited transfer |
| Sleep framework | Consolidated expert parameters | Needs MoE design and offline compute |
For a concrete neighbour, see our write-up of Mind Lab's Macaron v1 continual learning with LoRA, which also tries to learn from deployment without full retraining. The failure modes differ in the details, but both face the same question: how do you keep new learning from corrupting old behaviour?
The risks the post does not dwell on
- Self-generated data. Dreaming trains the model on its own outputs. Filtering helps, but a model can reinforce its own errors, a concern that echoes work like Anthropic's reward-hacking localisation research, where small training signals had outsized behavioural effects.
- Architecture dependence. The approach assumes pre-allocated MoE capacity. The post does not discuss the cost or how it scales to frontier-sized models.
- Safety and auditing. A model that rewrites its own parameters nightly is harder to evaluate and certify than a frozen release. Any provider would need version-pinning and regression suites around each sleep cycle.
- Privacy. Consolidating user context into weights raises questions about what the model retains and whether it can be removed on request.
What this means for builders
For now nothing changes in your stack: there is no released model or API. But the direction matters. If continual learning of this kind works at scale, memory layers and retrieval pipelines would shift from a necessity to an optimisation, and evaluation would have to treat a model as something that changes over time. Worth doing today:
- Build regression suites that can rerun after any model or memory change.
- Keep memory in inspectable files so you can audit what an agent knows.
- Watch for replication and open implementations before betting on it.
Bottom line
The sleep framework is an interesting, biologically inspired answer to the forgetting problem, with strong headline numbers from its own authors. Until the paper is replicated and code appears, treat it as promising research, not a solved problem.
Related reading
- Mind Lab Macaron v1: continual learning with LoRA
- Shared memory for Claude Code and Codex
- Agents do not need memory, they need documentation
- Anthropic reward hacking and adapters
- NVIDIA Long-WAM long-context world action model
- Genie 4 world model
Details are accurate as of October 27, 2026; the paper and results may be revised.
