Memory Consolidation · ships in v0.4+

The first memory layer that gets sharper the longer you use it.

Every chat tool you've owned gets noisier with time — history bloats, duplicates pile up, stale notes drown the good ones. Mnueron runs a nightly reflective pass over your store: merges duplicate clusters, retires superseded statuses, fixes dated relative time references, and writes a log of exactly what changed. Recall precision stays high while your data grows.

The problem

Memory accumulation is the same shape on every platform.

The first week of any memory tool feels great. Recall returns exactly what you asked for; the dashboard is clean. By month three, the same query returns eight chunks where four are duplicates from different sessions and two reference work that shipped weeks ago. Precision quietly drops while you're busy shipping.

Competitors mostly ignore this. Mem0 has decay scoring. Letta talks about "self-revising memory" but ships it as an opaque background loop. Zep tracks lifecycle metadata. None of them run a reflective passthat reads entries, merges duplicates, and gives you an audit log. That's the gap mnueron consolidation closes.

How it works

Five steps, each one cheap and inspectable.

The pipeline is deliberately split into a cheap pre-pass and a judgment phase. Most clusters never need an LLM — they're obvious exact duplicates that SQL handles for free. The LLM only runs on the genuinely ambiguous cases, which keeps cost predictable even on stores with millions of entries.

1

Scheduled or on-demand

Runs nightly at 3 AM local time by default. Trigger manually anytime with mnueron consolidate detect. Pick a different cadence (weekly, hourly, off) per namespace.

2

Cheap pre-pass

Lists namespaces, scans recent activity, and runs targeted memory_recall queries to surface duplicate clusters. Pure SQL + embedding similarity — no LLM cost yet.

3

LLM judgment on edge cases

For each cluster, a low-cost Haiku-class read decides: exact duplicate (delete redundant), superseded status (keep latest), complementary fragments (merge into one), or leave alone. The default-skip threshold is high — when in doubt, no action.

4

Proposals, not commits

First runs land everything in a review queue in your dashboard. Approve, reject, or edit each proposal. Once trust is established, flip auto-apply on per namespace.

5

Audit log

Every merge, delete, and rewrite is captured as a tagged memory (consolidation-log) you can recall by date. Patterns the pass noticed but didn't act on are surfaced too — they're often more valuable than the deletions themselves.

What it acts on

Four patterns it detects today.

Exact and near-duplicate clusters

Same answer captured into multiple chat sessions. Same status update saved on three different days. Same chunk imported twice from a Chrome extension.

Superseded statuses

"Pending Stripe config" + "Stripe configured" → keep the latest. "Waiting on review" + "Approved" → keep the latest. Dated decisions stay, dated status updates collapse.

Stale relative time references

"Ship next week" written six months ago becomes either a concrete date inferred from created_at, or — if the work is clearly done — gets retired entirely.

Procedural breadcrumbs

Short assistant chunks like "Now insert the Admin section" that aren't durable memory on their own. Tagged for archival, not deletion, so the surrounding transcript can still be replayed.

Safety model

Six guardrails. Nothing happens behind your back.

Autonomous deletion is the feature that loses people's trust fastest if it goes wrong. We default to conservative — the interesting thing isn't how aggressive the pass can be, it's how confidently you can let it run because every step is visible and reversible.

Hard cap of 50 actions per run

If the pass would delete more than 50 entries in a single run, it stops and emits a report instead. Bulk cleanup is a human decision.

Read before delete

Every entry the pass acts on is fetched in full (memory_get) and inspected — never deleted based on the preview alone. Logged in the audit trail.

Preservation rules

Entries tagged decision, architecture, plan, or stored in preferences-style namespaces are never touched. Anything that captures stated user preference or decision rationale is protected.

Dry-run mode

mnueron consolidate detect --dry-run prints what would happen without writing. Use it the first few times you change settings or thresholds.

Per-namespace policies

Set aggressive mode for noisy import namespaces (claude-cowork chunks) and conservative mode for decision logs. Same engine, different thresholds.

Reversible until purged

Deletions are soft for the first 30 days — entries move to a quarantine namespace you can restore from. After that, they're permanently dropped.
Tier comparison

Same engine. You pick the cadence.

The consolidation engine is identical across tiers. What changes is who runs it, where the review queue lives, and whether sync rides along on the same cycle.

Free Local

Run it yourself. The same engine the paid tiers use, no caps, just no scheduler.

  • mnueron consolidate detect
  • mnueron consolidate list / approve / reject
  • Review queue in local dashboard
  • Audit log in mnueron namespace
  • Manual trigger only
Install free
Popular

Personal · $10/mo

Scheduled nightly. Cross-machine. The setup the homepage band shows.

  • Nightly schedule, 3 AM local
  • Hosted review queue dashboard
  • Sync runs on the same cycle
  • BYOK or use Anthropic credit
  • Per-namespace thresholds
Start free trial

Team · $25/seat

Shared org consolidation across team namespaces, with admin policy controls.

  • Org-wide policies + retention rules
  • Per-member opt-in to auto-apply
  • Audit log retention 1 year
  • Slack / webhook digest of runs
  • SAML for enterprise
Contact sales
Real-world example

What the first production run looked like.

Below is the actual log from the first scheduled consolidation pass on a store with ~5,000 memories across nine namespaces. Lightly redacted, otherwise verbatim.

consolidation-log · 2026-05-25id: 7ba69936
Namespaces touched: default, web-claude, web-chatgpt, elevizio
Preserved:         mnueron, mnueron-plan, ops, preferences
                   (all decision/architecture/plan content)

Counts
------
deleted .... 22 (14 default + 5 web-claude + 1 web-chatgpt + 2 elevizio)
merged ..... 0  (no candidates needed new merged entries)
time-fixes . 0  (entries use absolute dates)

Patterns worth surfacing
------------------------
1. elevizio is ~99% claude-cowork chunk imports from 6 sessions.
   Many are short assistant turns ("Now insert X", "Let me check Y")
   that aren't durable memory. Could reclaim ~80% by archiving
   transcripts and keeping per-session summaries.

2. Same answer recurs across cowork sessions — found 2 exact-duplicate
   pairs (Stripe walkthrough; psql migration check). Almost certainly
   more exist that didn't surface in tonight's targeted queries.

3. default ns was test data — 14 of 16 entries were variants of a
   fabricated "John Smith from Stripe" test sentence.

4. Scheduled-task prompts are themselves becoming memories. Worth
   filtering <scheduled-task name=...> chunks at import time.

Safety
------
- Every deleted entry was read via memory_get first.
- 22 deletions, well under the 50-per-run cap.

Notice that "patterns surfaced" is usually more valuable than the deletions themselves — the pass surfaces structural issues humans can act on, not just rows to drop.

Set it up in 2 minutes

Step-by-step instructions for both manual and scheduled modes.

Read the runbook

Operator-grade runbook on GitHub: scheduling, monitoring, tuning, rollback.