OpenClaw Dreaming Memory Explained

Dreaming is OpenClaw’s background memory consolidation system. It is not a mystical extra brain, and it is not a license to dump every daily note into long-term memory. The docs describe it as an opt-in memory-core feature that stages, scores, reflects, and promotes strong short-term signals while keeping the process reviewable.

What dreaming writes

Dreaming keeps machine state under memory/.dreams/: recall store, phase signals, ingestion checkpoints, and locks. Human-readable output goes to DREAMS.md or existing dreams.md, with optional phase report files under memory/dreaming/<phase>/YYYY-MM-DD.md. Long-term promotion still writes only to MEMORY.md.

The phase model

There are three cooperative phases. Light phase sorts and stages recent short-term material but does not write durable memory. Deep phase scores and promotes durable candidates into MEMORY.md. REM phase extracts patterns and recurring themes but also avoids long-term writes. The phases are implementation details, not separate user-facing modes you toggle per conversation.

Deep ranking signals

Deep ranking uses weighted signals: frequency, relevance, query diversity, recency, consolidation, and conceptual richness. Light and REM hits can add a small recency-decayed boost through phase signals. Candidates must pass score and evidence gates, and deep phase rehydrates snippets from live daily files before writing so stale or deleted snippets are skipped.

Enable carefully

Dreaming is disabled by default. The documented quick-start config enables it inside the memory-core plugin. You can also set frequency, timezone, and model. Do not enable it because it sounds cool; enable it when you have enough short-term memory discipline that automated promotion will improve recall instead of preserving noise.

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": { "enabled": true }
        }
      }
    }
  }
}

Slash and CLI surfaces

The docs show slash commands such as /dreaming status, /dreaming on, /dreaming off, and /dreaming help. CLI workflows include promotion preview and apply commands such as openclaw memory promote, openclaw memory promote --apply, and openclaw memory status --deep.

My opinion: dreaming is powerful only when your memory hygiene is already good. Keep daily notes focused, keep evergreen memory lean, and let deep promotion earn its way into MEMORY.md instead of using it as a junk drawer.

If you are turning long-term OpenClaw memory design into real operations instead of a demo, The OpenClaw Playbook is the shortcut I wish every operator had: identity files, memory rules, safety boundaries, channel discipline, and production habits in one field-tested guide.

Memory hygiene first

Dreaming works best when short-term memory is already clean. If daily files are full of raw logs, duplicate chatter, or unresolved speculation, promotion has to work harder and reviewers have to distrust the result. Keep daily notes focused on decisions, issues, and durable context before asking automation to consolidate them.

Review before promotion

Deep promotion is the only phase that writes long-term memory, so treat preview and status commands as part of the workflow. A promoted memory should be concise, recallable, and useful months later. If it is only interesting today, leave it in the daily file and let retention or future dreaming decide.

Runbook detail

For OpenClaw Dreaming Memory Explained, the important operator move is to record the exact documented surface you used and the condition that proves it worked. That might be a status command, a gateway event, a task record, a pairing approval, or a visible channel response. OpenClaw features are much easier to trust when the runbook says how to verify the feature, not just how to start it.

Operator checkpoint

Keep the first rollout narrow: one owner, one environment, one reversible test, and one written rollback note. Once the behavior matches the docs in that small setting, widen it deliberately. That habit prevents a useful OpenClaw feature from becoming another invisible system nobody knows how to debug. If the verification step is unclear, stop and tighten the runbook before you hand it to an autonomous agent.