LycheeMemory: A Memory Layer for LLM Agents That Runs on SQLite and LanceDB

The problem: agents forget between sessions, and vector stores alone do not fix it

An agent that answers a question well and then loses the answer by the next turn is not a memory system. The common workaround is to append every exchange to a vector index and retrieve the top-k nearest chunks. That works until the conversation gets long, at which point retrieval returns near-duplicates, stale facts and contradictory statements with equal confidence. LycheeMemory targets that specific failure. The README describes it as a compact memory framework built around three ideas: structured organization, lightweight consolidation, and adaptive retrieval. The audience is narrow and identifiable. It is for people running agent runtimes that accept plugins, MCP servers, or direct Python calls, and who want memory to persist across sessions without operating a separate graph database. The README's own framing of the project's position is "long-term memory infrastructure for LLM-based agents," which is a deliberate split from the group's other work: the LycheeMemory paper and 7B model are research artifacts, while this repository is the operational layer.

Compact Semantic Memory: SQLite plus LanceDB replaced Neo4j

The most concrete architectural change in the changelog is the 03/28/2026 entry: semantic memory was upgraded to Compact Semantic Memory, described as SQLite plus LanceDB, with the note "no Neo4j required." That tells you what the earlier design looked like and why the current one is easier to adopt. A graph database is a second service to install, secure, back up and version. SQLite and LanceDB are embedded: the README lists LanceDB as the vector database and the changelog pairs it with SQLite, so the storage footprint is files on disk rather than a daemon. The trade-off is real and the project does not hide it. Graph stores let you traverse relationships between entities; an embedded pair of a relational file and a vector index does not give you the same query surface. If your retrieval logic depends on multi-hop traversal between people, projects and events, this design is a step down from what a graph store offers. If your retrieval is semantic search over consolidated memories plus some structured filtering, the embedded pair covers it and removes an operational dependency. The project also added a Transformer memory reranker in the 05/08/2026 release, described as improving "evidence selection in semantic memory search," with the note that it shows positive hit@10 gains on LoCoMo and zero-shot results on LongMemEval-S, MSC-MemFuse and HotpotQA fixtures. Those numbers come from the project's own documentation and I have not reproduced them; treat them as claims with a linked write-up at docs/transformer_reranker_v0.md rather than as independent measurements.

The consolidation pipeline and the per-request control flag

Consolidation is the part that distinguishes this from a plain retrieval wrapper. The README names it alongside structured organization and adaptive retrieval as one of the three pillars, and the 07/07/2026 news entry gives the operational detail: OpenAI-compatible Chat Completions endpoints are available, and consolidation can be controlled per request with the `consolidate` or `store` flags. That is a meaningful design decision. It means memory writing is not a background job you have no say over. A caller can decide that this particular exchange is worth persisting and the next one is not. The cost is that the caller now owns that judgement, and the documentation excerpt does not specify what happens when `consolidate` is set on a request that also fails, or how the two flags differ. The README also mentions turn mirroring as part of the plugin workflow, which suggests memories are written as turns complete rather than only at session end. Mirroring every turn is the behaviour most likely to produce duplicate or near-duplicate entries, and the excerpt does not describe a deduplication step. That is the first thing I would probe in a real deployment.

Getting it running: pip, the CLI, and the plugin install guides

The 04/03/2026 entry states that installation is `pip install lycheemem`, and that the service can be started from anywhere with `lycheemem-cli`. Python 3.9 or later is required, per the badge in the README. Beyond that, the repository is organized around four integration paths, each with its own install document: openclaw-plugin/INSTALL_OPENCLAW.md for the native OpenClaw plugin, claude-plugin/lycheemem/INSTALL_CLAUDE.md for Claude Code (MCP plus hooks), hermes-plugin/lycheemem/INSTALL_HERMES.md for the Hermes runtime plugin, and the PyPI package for direct Python use. There is also an HTTP MCP server, listed as compatible with any MCP client. No release files were retrieved for this review, so I cannot quote a version number or a changelog entry for the latest tag. The practical consequence is that you should read the install guide for your specific runtime rather than assuming the four paths are interchangeable; the README explicitly labels them differently (native plugin, MCP plus hooks, runtime plugin, Python API), which implies different hook points and different failure surfaces.

Where the documentation is thin and where the design looks risky

Three gaps stand out. First, there is no release history retrieved, which makes it hard to judge how much churn to expect in the plugin interfaces. The changelog shows a rename (04/13/2026, LycheeMem to LycheeMemory), a storage backend swap, and two new plugin integrations inside roughly a month of entries, so the surface is moving. Second, the performance claims are self-reported. The 03/30/2026 entry says that on PinchBench with the OpenClaw plugin, LycheeMemory achieved roughly a 6 percent score improvement over OpenClaw's native memory while cutting token consumption by about 71 percent and cost by about 55 percent. Those are the project's numbers, published in its own README, and I have not run PinchBench. The token and cost reductions are plausible for a system that consolidates rather than replays raw history, but plausible is not measured. Third, the excerpt says nothing about multi-tenancy, encryption at rest, or how memories are scoped per user or per agent. For a component that stores conversational content on disk in SQLite and LanceDB files, that omission matters more than any retrieval benchmark. If you are building a single-user assistant, it is a non-issue. If you are building a shared service, it is the question to answer before writing code.

The alternative: a plain vector store with your own summarization step

The obvious comparison is not another memory framework but the thing most teams already have: a vector database such as pgvector or Chroma, plus a periodic summarization job you write yourself. The approaches differ in where the logic lives. With a plain vector store, you control the write path completely. You decide what gets embedded, when summaries replace raw turns, and how retrieval filters results. You also own every one of those decisions, including the ones you get wrong. LycheeMemory moves that logic into the framework: consolidation, adaptive retrieval and the reranker are library behaviour, and the plugin integrations wire it into an agent runtime without you writing the glue. The cost is that you inherit its opinions about what a memory is and when it is written. There is a second alternative worth naming for teams already on a graph-heavy stack: staying with a Neo4j-backed memory design, which the changelog implies was the earlier approach here. That keeps traversal queries available at the price of operating the database. The honest summary is that LycheeMemory trades control for a working default, and the trade is only worth it if the default matches how your agent actually talks to users.

Licence and the cost of staying current

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices intact and state significant changes. The README also points to a separate research line with its own artifacts: an ACL 2026 paper, an arXiv identifier, and a Hugging Face model under a different account. Those are not covered by this repository's licence, and the README does not describe a relationship between the model weights and the memory framework beyond shared branding. If you intend to use the 7B model, check its licence separately. On maintenance cost, the changelog is the best signal available: entries are frequent, the project renamed itself mid-stream, replaced its semantic storage backend, and added two runtime integrations in a single month of dated notes. That pace is good for feature coverage and bad for interface stability. Budget for reading release notes before upgrading, and pin a version in your requirements file rather than tracking the default branch. There is no retrieved release list here, so I cannot tell you how often tagged releases ship relative to commits. I am not a lawyer and none of the above is legal advice.

Editorial conclusion

LycheeMemory fits teams already running OpenClaw, Claude Code or Hermes who want conversational recall without standing up a graph database, and Python developers who want to call the library directly. It is the wrong choice if you need per-user isolation guarantees, a stable release tag, or a memory system you can audit without reading plugin source. Before adopting, verify three things on your own hardware: that the `consolidate` flag behaves as documented on your endpoint, that the LanceDB and SQLite files land where your backup policy expects, and that the plugin's turn mirroring does not double-write memories when a session restarts.

Official sources

1. Issues
2. License: Apache-2.0
3. LycheeMem/LycheeMem on GitHub
4. Project website
5. README