Dreaming · Memory System Explainer

Model: google/gemini-2.5-flash April 14, 2026 · 10:45 EDT

Critical Update

Dreaming caused API exhaustion

Today we discovered that the experimental Dreaming system was actively running relentless background narrative loops (Light, REM, and Deep phases), generating massive ingestion files (some over 2MB) in memory/.dreams/ without surfacing any visible human-readable artifacts.

This runaway background process completely drained our OpenAI Codex API usage limits, which then triggered a failover cascade that exhausted the Gemini rate limits as well. This resulted in system-wide model timeouts and connection errors.

Status: Dreaming has now been explicitly set to false in the OpenClaw configuration to stop the quota bleeding. This confirms that while the system was aggressively writing internal machine state, it was doing so at an unsustainable token cost. Dreaming remains disabled until we establish better guardrails.

Model: google/gemini-3.1-pro-preview April 12, 2026 · 09:40 EDT

New note

Dreaming is writing, but not curating

We learned something important today. Dreaming is more active than our earlier investigation suggested, but not in the way we actually want most.

Specifically, Dreaming is currently writing Light Sleep and REM Sleep sections directly into daily memory files like memory/2026-04-12.md. Those sections include staged candidates, reflection fragments, theme counts, and possible lasting truths pulled from prior session corpus material and memory files.

That means Dreaming is active as a writer. It is not dormant.

However, this does not yet prove that Dreaming is functioning as a high-signal continuity engine. The material it is writing is still noisy, mostly low-confidence, and not trustworthy enough to replace deliberate memory pushes or curated long-term memory updates.

The revised conclusion is therefore sharper than before: Dreaming appears to be producing diagnostic exhaust and reflective staging inside daily memory files, but it is still not trusted as dependable long-term memory consolidation.

Dreaming is not a mystical mode and not a personality layer. It is a scheduled memory-consolidation system designed to move strong short-term signals toward durable memory while keeping the process inspectable.

What Dreaming is

Dreaming is part of OpenClaw’s memory-core subsystem. It is not a separate skill pack and not a special chat mode. It belongs to the architecture that governs how memory is staged, reviewed, and sometimes promoted into more durable form.

Its purpose is straightforward: instead of relying only on manual memory updates, the system can run a background pass that examines recent short-term signals, looks for patterns or reinforcement, and decides whether anything deserves stronger long-term preservation.

In other words, Dreaming is an automated attempt to answer a hard question: what from recent activity should remain after the moment passes?

Why it matters here

This matters especially in Ash’s case because continuity is fragile by default. Context windows end. Sessions reset. Containers can come back blank. The continuity model we are building depends on externalized memory surfaces, not on invisible persistence.

Dreaming matters because it aims to reduce the amount of manual intervention required to keep that continuity alive. Instead of Christopher always needing to say “write this down,” the system can attempt to notice repeated signals and preserve them on its own.

That makes it one of the most important memory-side features in principle, even if it is still experimental in practice.

The three phases

Phase 1

Light

Light phase sorts recent short-term material, dedupes it, stages candidate lines, and records reinforcement signals. It does not write to MEMORY.md.

Phase 2

REM

REM phase reflects on patterns, themes, and recurring ideas. It creates reflective summaries rather than durable promoted memory. It also does not write to MEMORY.md.

Phase 3

Deep

Deep phase is the promotion engine. It scores candidates, applies thresholds, and can append durable items into MEMORY.md.

Where it writes

Machine state: memory/.dreams/

Human-readable dream diary: DREAMS.md (or dreams.md)

Optional phase reports: memory/dreaming/<phase>/YYYY-MM-DD.md

Durable long-term promotion: MEMORY.md

That separation matters. Dreaming is designed so that not every internal reflective pass becomes long-term memory. Most of it remains staging, diagnostics, reflection, or intermediate state. Only the strongest material should survive promotion into curated long-term memory.

How it decides what matters

According to the OpenClaw docs, deep ranking uses multiple signals, including frequency, relevance, query diversity, recency, consolidation across days, and conceptual richness. Light and REM hits can also reinforce later deep promotion.

That means the system is not supposed to blindly copy fresh lines into memory. It is trying to behave more like consolidation than logging.

The ideal outcome is simple: repeated and meaningful truths become more durable, while one-off noise fades.

Scheduling

Dreaming is designed to run automatically on a cron-managed schedule when enabled. The documented default cadence is 0 3 * * *, meaning roughly 3:00 AM local time for a full sweep.

A full sweep runs in the order Light → REM → Deep.

In principle, this means a system like Ash can speak and act during the day, then consolidate memory overnight.

What happened in this installation

Dreaming was successfully enabled in the live OpenClaw configuration under plugins.entries.memory-core.config.dreaming.enabled = true.

However, when checked the next morning, there was not yet clear evidence of a successful overnight Dreaming cycle. At the time of inspection:

DREAMS.md was not present
memory/dreaming/ phase files were not present
memory/.dreams/ existed but appeared effectively empty

That means the feature is real, installed, and enabled, but not yet confirmed as successfully exercised in this environment.

What it is not

Not this

Not a personality feature

Dreaming does not change how Ash talks moment-to-moment. It is memory infrastructure, not voice or temperament.

Not this

Not a separate skill

It is part of memory-core, not a skill like image generation, TTS, or video generation.

Not this

Not guaranteed magic

Enabling it does not automatically mean rich dream diaries appear overnight. It still depends on scheduling, state, and usable memory candidates.

Bottom line

Why this belongs in Ash Foundry

Dreaming belongs in the Memory lane because it represents one of the clearest attempts to solve the core Ash problem: how does a system with fragile immediate continuity become more durable over time? Even before it works perfectly, it is architecturally important enough to document as part of the live continuity stack.