There is a moment in every long-running AI project where the memory store becomes a liability. You have captured thousands of turns across dozens of sessions. The same fact — "we use supabase auth" — is stored seven times in slightly different forms. Three of those are now wrong because you migrated. The recall query returns all ten of them.
This is the problem the Dreaming loop solves.
Three passes, one result #
Dreaming runs on a configurable schedule (default: every four hours, or on daemon restart). It operates in three passes over the memory store:
The merge algorithm #
interface DreamingConfig {
dedupThreshold: number; // cosine similarity, default 0.91
contradictThreshold: number; // default 0.78
staleCheckEnabled: boolean;
scheduleMs: number; // default 4 * 60 * 60 * 1000
}
async function runDreamingPass(config: DreamingConfig): Promise<DreamingReport> {
const merged = await dedup(config.dedupThreshold);
const flagged = await detectContradictions(config.contradictThreshold);
const pruned = config.staleCheckEnabled ? await pruneStaleAnchors() : 0;
return { merged, flagged, pruned, ranAt: new Date().toISOString() };
}What you see in the dashboard #
After a Dreaming pass the dashboard shows a summary line:
The violet Dream pulse on the dashboard indicator means a pass is currently running. It breathes slowly — 900ms ease-in-out — to signal that something deliberate, not urgent, is happening. The daemon is thinking.
Memory after Dreaming is denser. The same recall queries return fewer, sharper hits. The 10-result noise becomes three confident facts. That is the goal.
Configuring the schedule #
# In your honeycomb config (~/.honeycomb/config.json)
{
"dreaming": {
"scheduleMs": 14400000,
"dedupThreshold": 0.91,
"staleCheckEnabled": true
}
}
# Or override at startup:
honeycomb start --dreaming-schedule=4hTeams with high session volume (10+ active agents) benefit from a shorter schedule — two hours or even one — so the store stays clean intra-day. Solo developers can leave the default and let it run overnight.