> ## Documentation Index > Fetch the complete documentation index at: https://docs.memloom.dev/llms.txt > Use this file to discover all available pages before exploring further. # Features > What memloom does, in one pass memloom is one store with several distinct capabilities layered on it. This page is the tour; each section links to the page that explains the mechanism. ## Save runs a belief pipeline `save` doesn't just insert a row. With an API key configured, every incoming memory runs through the belief pipeline: * **Exact duplicate** → merged, nothing stored twice. * **Same fact, reworded** → the memory becomes a **new version** of the existing belief (the old version stays in history). * **Contradiction** → both memories stay active and a **conflict** is recorded for you to resolve. memloom never silently overwrites what you believed before. * **Genuinely new** → added. See [Memory types & versioning](/concepts/memory-types) and [Conflicts](/concepts/conflicts). ## Hybrid recall `recall` ranks results with three retrieval arms fused together: vector similarity (meaning), Postgres full-text search (exact words: file paths, error codes, config keys), and entity anchoring (things the query names). One query searches your saved memories **and** your ingested files, in one ranking. See [Retrieval](/concepts/retrieval). ## An assistant grounded in your store The viewer's assistant tab chats over your memories and files. The model decides when to search (via the same hybrid recall), answers only from what it found, and cites passages you can open: each answer lists its sources with a jump into the graph. Pick any tool-capable OpenRouter model from the composer, with prices and context windows shown. Attach a file to a chat with **+** and it becomes searchable in that chat only, deleted with it. See [The assistant](/concepts/assistant). ## Context: your files, searchable and cited `memloom context add ./docs` ingests `.md`, `.txt`, and `.pdf` files (directories recurse). Files are chunked along their real structure (markdown headings, ALL-CAPS titles, numbered points), so a chunk is one definition or one section instead of a blind 1,000-character window. Every result from a file says where it came from: `from lecture-notes.pdf › LIMITS OF FUNCTIONS > 2. DEFINITION (p. 1)`. Documents are mirrors: re-adding an unchanged file is a no-op, a changed file replaces its chunks. See [Extractors & chunking](/guides/extractors). ## One graph over memories and context `memloom index` extracts entities (people, projects, tools, concepts) from memories and context chunks and links everything through them. The viewer renders it: memories as circles, entities as purple circles, documents as diamonds that expand into chunk squares on click. A 300-page PDF stays one node: chunk-level links roll up into one weighted document → entity edge. The graph is yours to correct: the extraction vocabulary is a registry you can extend, review, and prune, and every entity can be renamed, retyped, merged into another, or deleted from the schema tab. See [The graph](/concepts/graph). ## Version history for every belief Every memory is a version chain. Rewording a fact, editing it with `memloom update`, or resolving a conflict appends a version; nothing is ever destroyed. `memloom history ` (or the `memory_history` MCP tool) walks the chain. See [Memory types & versioning](/concepts/memory-types). ## Human-in-the-loop conflicts When two memories can't both be true, memloom keeps both and asks *you*: in the viewer, the CLI, or through an agent using the MCP tools. Every resolution (keep new, keep existing, keep both, merge) is reversible. See [Conflicts](/concepts/conflicts). ## Import your Claude Code history into that same store `memloom import sessions` reads your local Claude Code sessions, redacts secret-shaped strings, and distills each session into typed memories through the exact belief pipeline described above. Every imported memory keeps provenance back to the session file and line range it came from. `memloom connect claude-code` makes capture continuous: a session-end hook distills each session as it finishes, bounded by a daily budget so nothing runs unattended, and a prompt-time hook recalls relevant memories into every Claude Code prompt, so the agent uses what it knows without being asked to. Imported or hand-saved, it's the same store: a recall doesn't care whether a memory came from typing `memloom save` or from a session you closed months ago. See [Session distillation](/concepts/distillation) and [Import](/cli/import). ## Every client, one store | Surface | What it's for | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **CLI** (`memloom save/recall/...`) | You, in a terminal | | **MCP** | Claude Desktop, Claude Code, Cursor: agents that save and recall as they work | | **Viewer** (`memloom ui`) | Browsing: graph, assistant, memories, documents, schema, conflicts, console | | **HTTP API** (`127.0.0.1:4319`) | Anything else: scripts, editors, your own tools | | **Postgres wire** (`127.0.0.1:54329`) | Inspecting the raw data with Drizzle Studio or psql (embedded tier; on `MEMLOOM_PG_URL` inspect your server directly) | All of them talk to one daemon that owns one store, so an agent's save is instantly visible in the viewer and your CLI recall sees what the agent ingested. See [Architecture](/concepts/architecture). ## Local-first, yours The store is a folder: `~/.memloom/data`. Copy it to back it up. Delete it to start over. The only network calls are to the embedding/LLM provider you configure. Without a key, memloom runs fully offline in a reduced mode. See [Configuration](/guides/configuration) and [Self-hosting](/guides/self-hosting).