Short version. Dreams is an async, idle-time, single-store rewriter triggered through one API call. KDCube has a multi-layer memory architecture, an LLM-driven reconciliation primitive that does the same kind of work, and as of release 2026.5.13.117 the cron + background-job substrate to fire it off the turn path. What's not yet shipped is the wiring — a bundle that schedules the reconciler on cadence.

1. What Dreams actually is

A dream in the Anthropic API is a top-level resource. You create one with client.beta.dreams.create(...), passing two kinds of inputs — a memory_store and an array of sessions (transcripts to mine) — plus a model (claude-opus-4-7 or claude-sonnet-4-6) and free-text instructions that constrain the curation pass. The job is asynchronous, typically running for minutes to tens of minutes, and exposes a normal lifecycle: pending → running → completed | failed | canceled. While it runs, its session_id points at the underlying session executing the pipeline, so you can stream the pipeline's own events the same way you'd stream any session.

From the docs themselves: "A dream reads an existing memory store alongside past session transcripts, then produces a new, reorganized memory store: duplicates merged, stale or contradicted entries replaced with the latest value, and new insights surfaced. The input store is never modified, so you can review the output and discard it if you don't like the result."

The architectural call-outs that matter: (a) the input store is immutable — the output is a separate store you choose to attach (or discard); (b) the consolidation runs off the agent's turn path, in idle time you schedule; (c) the unit being consolidated is one flat memory store at a time. Limits at preview: 100 sessions per dream, 4 096-char instructions, billed at standard token rates.

2. KDCube's memory model is layered, not flat

We covered the model in detail in "Memory is not one bucket". The condensed version, with the bits that matter for consolidation:

• Timeline (artifact:conv.timeline.v1) — append-only event log per conversation. Source of truth for everything else.
• Working summary per turn (ws:<turn_id>.conv.working.summary) — goal/outcome/facts/refs, indexed for react.memsearch.
• Turn fingerprint (artifact:turn.fingerprint.v1) — compact FSP record per turn: objective, topics, assertions, exceptions, facts, assistant signals. Pre-distilled.
• Compaction memory — when context pressure rises, [COMPACTED PRIOR CONVERSATION MEMORY] and [INTERNAL MEMORY DIGEST] blocks replace older raw turns. Raw artifacts are never deleted — only the visible projection compacts.
• Objective memory buckets — thematic, cross-conversation, user-scoped. Each bucket has a topic centroid, an objective text, and a thin timeline of slices. This is the layer most directly analogous to a Dreams memory store.
• Active set (conversation.active_set.v1) — per-conversation pointer at the currently selected buckets, with a since_last_reconcile counter.

Crucially, KDCube already has the consolidation worker. In app/ai-app/src/kdcube-ai-app/kdcube_ai_app/apps/chat/sdk/context/memory/memories_reconciler.py there's an objective_reconciler_stream — an LLM-streaming function that fuses new turn fingerprints into thematic MemoryBucket timelines, marks obsolete buckets disabled, and proposes new ones. It is the spiritual counterpart to a dream: "read what's accumulated, decide what's still true, write the new shape."

3. Side by side

4. What the May 13 release changed

Until recently, the honest answer to "could KDCube do something like Dreams?" had a real caveat: the reconciler existed as a primitive, but the platform didn't ship a clean way to run it off the agent path. That caveat is smaller now.

Release 2026.5.13.117 finalized three pieces that together make idle-time consolidation a straightforward bundle author task:

• @cron with span (system | process | instance) and enabled.cron.<alias> gating — so a bundle can declare "run this every six hours, system-wide, only when this tenant flag is on."
• Proc-owned scheduler with per-job Redis locks and a reconcile loop — exactly the runtime guarantee you want for an expensive consolidation pass that must not double-fire across replicas.
• Bundle background job stream (kdcube_ai_app/infra/jobs/stream.py) — a generic async progress/log channel for off-turn jobs, addressable from admin UI and the chat surface. Dreams' "stream the pipeline's session events" pattern translates one-to-one.

Add the recent on_props_changed hook for reactive bundle props, dynamic per-resource config overrides, and canonical enabled.* feature gates across bundle/api/mcp/widget/cron — and you have a workable surface for shipping memory consolidation as an opt-in bundle skill with its own admin controls.

5. What "Dreams for KDCube" actually looks like

Concretely, the design that maps cleanest onto KDCube's existing primitives:

1. A bundle declares @cron(expr="0 3 * * *", span="system") on a consolidation handler. The cron span is system so only one replica fires per tenant.
2. The handler queries the per-user ConvMemoriesStore for any user whose since_last_reconcile counter has crossed a threshold (or scope: all users idle for > N hours).
3. For each such user, it calls objective_reconciler_stream with their accumulated turn fingerprints — and writes the reconciled bucket set to a shadow artifact id, not the live active set.
4. Progress is published through the bundle background job stream, so admins can watch the pipeline run and review the diff (added buckets, retired buckets, contradiction resolutions).
5. An admin action (or an automatic threshold) promotes the shadow set to active. The raw timeline and the pre-reconciliation bucket set both remain — recovery is a single pointer flip.

What you get that Dreams doesn't give you: tenant-scoped scheduling, hot-reload of the consolidation logic itself, granular budgets, per-user reconciliation cadence, and a shadow-store review pattern that's stricter than "discard the output." What Dreams gives you that this doesn't: a hosted runtime where someone else owns the long-running job, the SLA, and the bill.

6. Why we ended up with the same shape

Both teams independently converged on the same realization: memory accumulates, and the only honest fix is to let an LLM look at the accumulation and rewrite it. There's no clever indexing trick, no embedding distillation, no rule-based dedup that holds up against six months of real use. Eventually you have to ask the model to read what's there and decide what's still true.

The interesting design choices are the ones around it: what's the input format (raw transcripts vs. pre-distilled fingerprints), what's the output (a new flat store vs. a shadow bucket set), what's the trigger (explicit API call vs. scheduled cadence), and what's the safety net (immutable input + review vs. shadow promotion). Different tradeoffs, same core mechanism.

We'll ship the reference consolidation bundle in the next release. If you want to track that work or push on the design, file an issue or drop into GitHub Discussions.