> ## Documentation Index
> Fetch the complete documentation index at: https://docs.backant.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Dream pass

> Inspect Kairos's offline consolidation pipeline.

Periodically, Kairos pauses ordinary work and **consolidates memory** — a structured offline pass we call a *dream*. It is structurally analogous to sleep-dependent memory consolidation: sample related observations, find non-obvious connections, distill durable lessons, **stage** the result for the agent's next wake-time review.

<Info>
  Dreams do **not** mutate long-term memory directly. They produce candidates that the agent accepts or rejects on the next wake. You always have an opportunity to review before consolidations become durable.
</Info>

## When dreams fire

Dreams are triggered by a *pressure score* that combines several operational signals (work elapsed since last dream, unresolved retries, observation novelty, log volume, a few more). When pressure crosses a threshold, the next turn is a dream.

A safety floor guarantees a dream every N turns even when pressure is low; an anti-thrash floor prevents back-to-back dreams. Thresholds are tuned ongoing.

## `backant dream stats`

Summary of recent dreams:

```bash theme={null}
backant dream stats
```

For each recent dream:

* When it happened
* How many candidate consolidations were produced
* How many edge proposals were made
* How many were accepted vs. rejected during the next wake-time review

Use this to verify the consolidation pipeline is actually doing work. A long stretch with no dreams plus lots of unresolved retries is a sign that pressure signals aren't firing correctly.

## `backant dream replay`

Walk through a past dream as an annotated timeline:

```bash theme={null}
backant dream replay dr_20260515_0a1b
```

Each event in the dream is logged with its inputs and outputs:

* **Sample**: which entries were drawn for this dream
* **Coactivate**: which pairs the model identified as related
* **Reflect**: how the model rewrote / clustered the related entries
* **Bucket-write**: which staged candidates were produced
* **Edge-propose**: which links between entries were proposed

Useful for debugging odd consolidations, or for understanding *why* a particular edge was proposed.

## The five stages (briefly)

```
1. Slow-wave-style curation        — distill failure signatures from recent logs
2. Candidate sampling              — pick pairs of entries to consider together
3. Co-activation                   — does this pair belong together?
4. Reflection                      — what should the merged / linked form look like?
5. Bucket-write + edge-propose     — stage candidates for the agent's review
```

The pipeline is deliberately advisory. Anything that lands in durable memory has been through the agent's verdict at wake time.

## Reviewing dream output

You don't normally need to review dream output by hand — Kairos does that automatically on the next wake via the `wake_edge_triage` and dream-bucket verdict tools. But if you want to:

```bash theme={null}
backant memory stats              # see dream_bucket_pending count
backant dream replay <dream-id>   # see what was produced
```

If a recent dream produced consolidations you disagree with, the next wake-time review will reject them based on the agent's read of the codebase. The pipeline is self-correcting in that sense.

## Why offline?

Mutating memory on every write would couple every observation to a reasoning pass — expensive and noisy. Batching consolidation into structured offline passes:

* Keeps live work fast (no consolidation cost paid on the critical path)
* Lets the consolidation use a stronger reasoning model than live work
* Mirrors how biological consolidation actually works during sleep

The [architecture page](/kairos/architecture) goes a little deeper on the design intent.