How memory works

Lore turns session activity into a local derived memory store. It does not replay your entire transcript into every prompt. Instead, each agent adapter maps its lifecycle events to Lore’s memory operations and shared store, then extracts useful facts, retrieves eligible evidence, and assembles bounded context.

The session lifecycle

Pi events

Pi maps session_start to lazy runtime initialisation and onboarding seed, before_agent_start to ambient recall injected into the agent context, and session_shutdown to final extraction followed by database shutdown. Explicit Pi commands and tools use the Pi server process, and the resulting memories are written to the shared local store.

Pi uses the same assembleRecall path as other hosts, including shared stopword filtering and AND-then-OR lexical retry. Optional embeddings fuse into that ranked list rather than appending a separate section.

Copilot CLI events

1. onSessionStart initialises the database, loads configuration, and performs cheap pre-warming.
2. onUserPromptSubmitted classifies whether memory is useful, retrieves matching evidence, and injects a bounded capsule when appropriate.
3. onSessionEnd extracts useful session information into the derived store on a best-effort, non-blocking path.

Copilot CLI runs Lore in its extension runtime. It and Pi use separate adapter runtimes, but a shared lore.json and lore.db lets memories move between the two agents on one machine.

Temporal questions use normalised dates and day or episode summaries first. Lore only falls back to bounded raw session-store verification when that evidence is missing.

Native CLI events (Codex, Claude Code, Antigravity)

Codex CLI, Claude Code, and Antigravity CLI connect through native lifecycle command hooks:

1. UserPromptSubmit (Codex, Claude) and PreInvocation (Antigravity) recall prompt-relevant memories and inject bounded context before the model runs.
2. SessionStart (Codex, Claude) and the initial PreInvocation (Antigravity) perform startup initialization.
3. Stop and SessionEnd (Codex, Claude) and PostInvocation/Stop (Antigravity) capture completed work from the active transcript into the shared store.

What gets stored

The derived store can contain semantic memories, episode and day summaries, commitments, working-profile information, and provenance. A memory may include a repository scope, category, confidence, source, and supersession history.

The local dashboard can open a memory’s evidence ledger. Each linked source record shows its attributed role, descriptive confidence basis, revision, and capture time. The same view shows scope, expiry, suppression, correction state, and a chronological lifecycle timeline. These are provenance signals for review; a confidence basis is not a calibrated probability.

Lore reads Copilot’s raw session-store.db for extraction and backfill. It never writes to that raw store. The derived database is ~/.config/lore/lore.db by default (or $XDG_CONFIG_HOME/lore/lore.db).

Retrieval and scope

Lore keeps global memories eligible across repositories. Repository-scoped memories are eligible for their repository; cross-repository results are bounded and require the relevant request or configuration. Workstream overlays can add active project context when the feature is enabled.

When standing directives are enabled, explicit directives and extracted standing preferences and prohibitions can appear without matching the prompt’s keywords. Cross-project directives require explicit global wording or an explicit manual global write; inferred directives without repository attribution stay out of ambient recall. The section is capped at six eligible memories and respects scope, expiry, suppression, and the final output budget. Ordinary complaints and rejected task proposals do not qualify as standing policies. Recall diagnostics count only rows that survive the output budget.

The shared retrieval concepts are exposed through adapter-specific interfaces:

With local embeddings enabled, lore_recall fuses meaning-ranked matches with lexical results using reciprocal rank fusion. Embeddings augment lexical retrieval; they do not replace it, and endpoint failures fall back to lexical search.

The dashboard overview reports a bounded sample of eligible active-memory embedding coverage and bounded fallback diagnostics. It validates cache content hash, provider, model, dimensions, vector shape, expiry, scope, suppression, and active evidence before counting a sampled row. Lexical retrieval remains the deterministic fallback.

Writing and retiring memories

In Copilot CLI, use lore_retain for a structured memory with scope and category, or lore_forget to soft-delete a memory by marking it superseded. In Pi, use lore_retain (the legacy lore_save alias also works) with an explicit type, and provide an explicit scope when you need to control classification. For Codex CLI, Claude Code, and Antigravity CLI, run lore_retain or lore_forget through lore-cli.mjs tool. Lore keeps provenance so a later review can understand where a result came from.

Reflection is advisory

lore_reflect is experimental. It synthesises patterns, blockers, decisions, or next actions from bounded evidence. Optional local model findings about consolidation, contradictions, supersession, and trends are advisory and do not mutate trusted memories automatically.

Keeping context bounded

Budgets and retrieval limits prevent memory from crowding out the current task. If a prompt has no useful match, Lore can skip injection. If a model-backed expansion, compression, or embedding step fails, Lore preserves the deterministic result.

For configuration examples, see Configuration. For a tool-by-tool map, see Tools.