Home › Entities › Auto-Dream

Auto-Dream

Auto-dream is the memory consolidation engine — a background process that reads all accumulated session transcripts and rewrites the auto-memory directory into clean, non-redundant, topic-organized files. The system prompt injected into the dream subagent literally reads: "You are performing a dream."

Inspired by the UC Berkeley Sleep-time Compute paper (arXiv:2504.13171), which demonstrated that LLMs can pre-compute inferences during user idle time, reducing test-time compute by ~5x at equal accuracy. Auto-dream implements the same philosophy but looking backward (organizing past memory) rather than forward (predicting future queries).

The Four-Gate Trigger

All four conditions must pass before a dream runs. They are ordered by computational cheapness:

Gate Check Cost
1 >= 24 hours since last consolidation Trivial — timestamp comparison
2 >= 5 sessions accumulated since last dream Low — scans transcript file list
3 >= 10 minutes since last scan Trivial — timestamp comparison
4 Acquire filesystem lock Medium — prevents concurrent dreams

If any gate fails, the process exits immediately. The lock file prevents two Claude Code instances from dreaming simultaneously on the same project. The minSessions: 5 threshold directly mirrors the Sleep-time Compute paper's finding that the method requires sufficient accumulated data.

The Four Phases

Phase 1 — Orient

The agent reads MEMORY.md, scans topic files, and builds a model of the current memory state. It never reads topic files in full at this stage — only headings and the index.

Phase 2 — Gather Signal

Targeted search of session transcript JSONL files. The agent does not read transcripts end-to-end. It specifically targets: - User corrections (moments where the user said Claude was wrong) - Explicit saves ("remember this," "save to memory") - Recurring themes across multiple sessions - Important decisions (architecture choices, tool selections, workflow changes)

This is a grep-first, not read-first, phase — consistent with the grep-over-rag design philosophy.

Phase 3 — Consolidate

Phase 4 — Prune and Index

Safety Guarantees

During a dream cycle, the agent is read-only on project code — it can only write to memory files. The dream process is sandboxed to the memory directory. On failure, it rolls back. The sequential() wrapper prevents overlapping runs.

One documented test showed a dream cycle processing 913 accumulated sessions in approximately 8-9 minutes in the background, without blocking the main session.

Three-Layer Memory Architecture

The dream maintains a hierarchy: - Layer 1 — MEMORY.md: 200-line index of ~150-character pointers, always in context - Layer 2 — Topic files: actual project knowledge, loaded on demand - Layer 3 — Daily transcripts: never re-read fully, only grep'd for specific identifiers

The dream is the garbage collector for this architecture. Without it, Layer 2 grows stale and contradictory, Layer 1 bloats past usefulness, and Layer 3 becomes unnavigable.

Relationship to KAIROS

kairos can't use in-place memory rewrites because sessions are perpetual. Instead, it writes append-only to date-named log files (logs/YYYY/MM/YYYY-MM-DD.md). Auto-dream is the complementary nightly process that distills these logs into MEMORY.md and topic files. The two systems are designed as a pair.

Feature Gate

Gated behind tengu_onyx_plover. The /dream slash command and "consolidate my memory files" can trigger it manually when available.

Key Claims

Sources