Why RecallNest?

Coding agents forget everything between windows. Your context — project configs, debugging decisions, entity mappings — is scattered across Claude Code, Codex, Kimi, Antigravity — and every other terminal you open — with no shared memory.

RecallNest is one LanceDB-backed memory layer that all of them read and write. Context stored in one window is recalled in another. Sessions checkpoint on exit and resume on start. Memory decays, evolves, and self-organizes — it is not a log you grep.

What a recall actually looks like

Query   : deploy rollback
Hits    : 5

#  ID       Score Category  Tier        Source  Date        Age  Retrieval Path
1  ee79037a 46.1% cases     peripheral  cc      2026-08-25  2d   vector
   [assistant] Rolled back to the previous image and pinned the digest so the next…
   prov : evidence/transcript-ingest
   imgs : 52 agent-made in this session · read sess=dca70d4a

Three things in that block carry most of the design:

• Source cc · Age 2d — this came out of a Claude Code window two days ago and you are reading it from a different terminal, possibly on a different machine. That is the premise the whole project is built on.
• prov : evidence/… — every row states which layer it sits on. A fragment scraped out of a transcript never gets to pose as a decision you actually made; moving to durable memory is a separate, gated step with its own evidence requirement.
• imgs : … — that session contained 52 images. Not one of them is in the database. The line exists so you know there is something to go look at, and producing it cost no model call, no vector, and no storage.

That last one is the approach in miniature: store what makes a thing findable, not everything that could ever be asked about it. The full reasoning — including the two places where the obvious implementation was wrong — is in Images: addressable, not embedded.

Core Capabilities

Access & Setup

Recall & Continuity

Memory Lifecycle & Governance

Reasoning & Structure

Visibility & Operations

Architecture

  CLIENTS                    ACCESS                      CORE ENGINE                    STORAGE
  ──────────────────────     ───────────────────────     ────────────────────────────   ──────────────────────

  Claude Code                MCP over stdio              Retriever                      LanceDB
  Codex                ───▶  44 tools, 3 tiers    ───▶   vector + BM25 + RRF     ───▶   vector + columnar
  Kimi · Antigravity                                     Classifier · 6 categories
  Doubao desktop                                         Context composer
                             HTTP API :4318              resume_context                 Jina embeddings v5
  your scripts · cron  ───▶  21 endpoints          ───▶  Decay · Weibull half-life ─▶   1024-dim, task-aware
                                                         Conflict · audit + merge
  phone app            ───▶  read-only gateway     ───▶  Capture: evidence → durable
                             :8791, token-gated

Internal Design

• L0 / L1 / L2 Dynamic Folding — every memory stores 3 granularity layers (one-liner / bullet summary / full content); retrieval dynamically selects which layer to return based on relevance score and token budget
• Weibull Decay + Emotion Modulation — memories decay along a parametric Weibull curve; importance scores modulate the half-life, and emotional salience extends it further (up to 30%)
• Vector Pre-filter + LLM Dedup — 90% of dedup decisions use cheap cosine similarity (>= 0.92); only borderline cases invoke LLM judgment, keeping costs low without sacrificing accuracy
• Category-Aware Merge Strategies — profile and preferences use merge-on-conflict (latest wins); events and cases use append-only (history preserved)
• Display Score vs Elimination Score — dual-track retrieval: tier floor prevents core memories from ever dropping out, while decay boost lets fresh memories surface temporarily without permanently displacing stable ones

Full architecture deep-dive: docs/architecture.md

Who Can Connect

The data layer does not know what your client looks like. RecallNest exposes the same LanceDB store through three outlets, so the right one is picked per client — not per protocol.

Two consequences worth stating plainly:

• Not tied to one protocol. A GUI chat app that supports MCP config connects the same way a terminal agent does. A client that can only issue HTTP requests still reads the same memory.
• Not tied to one machine. Because the MCP transport is stdio, the launch command is yours to define — point it at ssh and every client on every machine shares a single source of truth instead of each host growing its own database.