OpenClaw Memory: LanceDB vs MemoryRouter

OpenClaw's docs describe one plugin as an official external memory option. memory-lancedb keeps long-term memory in a local vector database. It recalls before a model turn and captures after a response, and the plugin itself costs nothing beyond the embedding calls it makes. For one agent on one machine, that is a fair answer, and the docs are candid about where it stops.

MemoryRouter takes the same decision from the other side. The mr-memory plugin keeps memory off the machine, in a vault your other tools can read. The tradeoff runs in both directions, and the choice is worth making on purpose. Here is how the two actually differ.

What the official plugin gives you

@openclaw/memory-lancedb is published to npm and installed with one command:

openclaw plugins install @openclaw/memory-lancedb

The install points plugins.slots.memory at the plugin, and only one plugin owns that slot at a time. Memories land in a LanceDB database at ~/.openclaw/memory/lancedb by default, with dbPath moving it, including onto S3-compatible storage.

Embeddings are yours to choose. The plugin shares the built-in memory's provider adapters, so openai is the default path, ollama keeps embeddings local, and a raw OpenAI-compatible endpoint works through the direct client config. Two OpenAI models have built-in dimensions; anything else needs its vector size declared, and changing the model or dimensions changes the persisted index identity, so plan a re-embedding before you switch.

Recall and capture are flags. In the docs' quick-start example, auto-recall is on and auto-capture is off, so check that flag before concluding nothing is being saved. Once capture is on, it works inside limits: user messages longer than 500 characters are skipped, at most three memories are captured per turn, and text that reads like a prompt-injection payload or transport metadata is rejected. Incognito sessions skip automatic recall and capture entirely, and every memory is owned by one agent at the storage layer, enforced before ranking.

Your agent gets memory_recall, memory_store, and memory_forget, and the CLI gets an ltm namespace with list, search, stats, and a filterable query. One limit matters if you lean on cross-conversation search: this plugin's recall does not carry the protected private transcript authorization behind Remember across conversations, and openclaw doctor reports when that feature is unavailable.

Everything above was checked against the official plugin documentation on October 12, 2026.

What MemoryRouter gives you

The mr-memory plugin installs in two commands and works as a relay:

openclaw plugins install npm:mr-memory
openclaw mr <your-memory-key>

Recall runs through OpenClaw hooks, adding relevant memories before the model sees your turn, and at agent_end direct exchanges between you and the agent are captured. Tool calls, subagent output, and internal processing stay out, so tool chatter never becomes memory. Memory content leaves for MemoryRouter, which stores it and serves it back later. Inference and provider keys stay inside OpenClaw, where they already live.

Search covers raw exchanges and the higher-level reflections a background consolidation pass builds from them, filterable by tier and importance. The vault is not locked to OpenClaw. Claude Code and Codex read the same memories from their own sessions, and the Claude and ChatGPT chats you connect read them too. openclaw mr off returns the agent to stock defaults and leaves the vault in place. The OpenClaw page shows the upload flow and multi-agent setups in more depth.

Where the local option wins

Everything stays on the machine. The database lives in a directory you own, reads are local, and with Ollama the embedding step never leaves either. No subscription and no third party in the path. The plugin is maintained upstream. If the constraint is that conversation content stays on hardware you control, run this plugin.

Where the two diverge

The difference stops being about storage and becomes about reach. The LanceDB record belongs to OpenClaw. A second tool on the same desk cannot read it, and a second machine starts from zero unless you move files yourself. The vault is written once and read from every surface you connect, which is why people who run Claude Code in one window and OpenClaw in another end up here.

Then the operations. Local means you own the embedding path, the endpoint and its dimensions, including the re-embedding when a model changes. Managed means retrieval runs as someone else's service, and what you configure is the part that is about you: which vault and which key hold your data.

And the capture shape decides some setups on its own. The official plugin captures short declarative text, capped per message and per turn. The relay captures exchanges, so the reasoning that runs long stays in the record.

What each costs

The official plugin is free. Your marginal cost is whatever the embedding provider charges, which is zero if embeddings run locally and an API bill if they do not. MemoryRouter: $20 per month once the 14-day trial ends, with 200M memory tokens and no inference markup.

Run the same round trip either way

Before trusting real history to either stack, test recall once with a synthetic fact. Put the fact into a session, close it, and start a clean one that carries nothing. Ask for the fact back. When it arrives without you supplying it again, the path from store to prompt works, and that single round trip tells you more than any feature list.

Which one to run

The official plugin fits when the machine is the boundary: one operator, local files, offline tolerance, and OpenClaw as the only surface.

MemoryRouter fits when the boundary is you: several tools and more than one machine, with history that should follow you between them.

Create your MemoryRouter account, install the two commands, and let this week's decisions show up in next week's sessions.