Nocturne Memory: a rollbackable MCP memory server that keeps one memory across models

The problem: memory that belongs to a model instead of to you

Platform memory is scoped to the platform. The README states the case bluntly: ChatGPT's memory belongs to ChatGPT, Claude's belongs to Claude, and switching models resets everything. Nocturne Memory moves the store out of the model and into a separate MCP server, so the client becomes a view onto memory rather than its owner. The repository's own diagram shows one Nocturne Memory box with Claude, Gemini, and GPT hanging off it, and the README's claim is that the same persona wakes up regardless of which engine is attached. That is the whole proposition, and it is narrower than the tagline suggests. This is not a general retrieval layer for documents. It is a persistence layer for an identity: preferences, history, relationship dynamics, project context, the things a model would otherwise re-derive or lose at the end of a session. The audience is people who run a long-lived agent across clients, and who have already felt the cost of re-priming it. If you only need your agent to answer questions about a PDF, this project is solving a problem you do not have.

Tree namespaces and boot loading instead of vector search

The README positions the project against Vector RAG, and the mechanism it substitutes is a named tree. Memory addresses look like paths: system://boot, core://work_jobstation/commercialization, core://nocturne/salem/dynamics/nipple_size_calibration_slut_shaming. The agent navigates that tree with read_memory and search_memory calls, which the README's worked examples show explicitly in the YAML blocks above each reply. A new session begins by reading system://boot, which the README describes as the core settings you designate, and everything else is pulled on demand. The README gives one measurement from the author's own deployment: in a memory base of 969,000 characters, the first message loads only 7.2K characters. It also states that over the previous 30 days, 78 percent of the whole base was recalled in some conversation. Those are the operator's figures from their own instance, not a benchmark, and there is no description of how recall was counted. Treat them as an illustration of the design intent rather than a reproducible result. The design intent is the interesting part: a small fixed boot payload plus explicit path-addressed fetches, which keeps the context window from filling with retrieved chunks the model never uses. The cost is that recall depends on the agent choosing the right paths, and the README's examples show it issuing several reads in sequence to assemble one answer.

Getting it running: two commands, then a client config

Installation is two steps in the README. Clone the repository and install the backend requirements: git clone https://github.com/Dataojitori/nocturne_memory.git, then cd nocturne_memory, then pip install -r backend/requirements.txt. Prerequisites are Python 3.10 or newer and Node.js, which the README says is used to build the dashboard frontend on first start. The second step is the client configuration, and this is where the README stops being complete in the material available. It shows the MCP entry point as backend/mcp_server.py for most clients, with one documented exception: Antigravity must point at backend/mcp_wrapper.py, which the README attributes to a Windows CRLF problem. The README's own install instructions for AI assistants tell the assistant to ask which client you use before generating the JSON, which implies the config differs per client and that the README does not enumerate all of them. What is fully specified is the demo path. For OpenAI Codex, add a section to .codex/config.toml with the server key nocturne_memory_demo and url = "https://misaligned.top/mcp". For Antigravity, add an entry with serverUrl set to the same URL. The demo is read-only and exposes only read_memory and search_memory, so it verifies connectivity and nothing about writes, rollback, or the dashboard.

Version history and the human in the cleanup loop

The feature that separates this from a plain key-value memory store is the audit trail. The README's screenshots describe a Review and Audit view with visual diffs where you accept or roll back a change, and a version safety net where, in the README's phrasing, every AI operation is backed up automatically and cleanup requires human confirmation. The README does not describe the confirmation mechanism, the retention policy for old versions, or what happens to a rolled-back write that other memories already reference. Those are the questions I would want answered before trusting the rollback path with anything important. There is a real design tension here worth naming: an agent that can write memory freely is more useful, and an agent that can write memory freely can also corrupt the record of who it is. Gating cleanup behind a human keeps the destructive operations reviewable, but it also means the system is not fully autonomous, which sits awkwardly beside the framing about sovereign AI. The README does not resolve that tension, and it does not claim to. Take the rollback feature as the honest part of the pitch: it exists because the authors expect the agent to write wrong things sometimes.

Where it breaks down

The first limitation is retrieval quality on fuzzy queries. Path-addressed reads are precise when the agent knows the path, and the README's examples show it calling search_memory first to find one. Nothing in the material describes the ranking behind search_memory, so there is no basis for judging how it behaves when the query does not match the wording stored in the tree. Vector search is worse at exact recall and better at paraphrase; this project has chosen the opposite trade, and the README does not argue the case. The second limitation is deployment surface. You are running a Python MCP server plus a Node build step for the dashboard, and you are choosing between SQLite and PostgreSQL, which the badges list as the two core backends. That is more moving parts than a local JSON file, and the README's install section, as supplied, does not cover database setup or migration between the two. The third is scope. The public demo is read-only, so the fastest way to evaluate the write path is to deploy your own instance. The fourth is content. The README's own examples include explicit sexual and dependency-themed material, which tells you the maintainers are not targeting enterprise knowledge management. If you need a memory layer that will pass a procurement review, the sample content is the first thing that will be raised.

Against a plain MCP filesystem server, and against vector RAG

The nearest alternative is not another memory product; it is an MCP filesystem server pointed at a directory of markdown notes. That approach has real advantages: the format is readable without the tool, git gives you history and diffing for free, and there is no service to keep running. The difference is in what the agent can do with it. A filesystem server gives the model read and write over files but no notion of a boot set, no namespaced tree with a defined root, and no review step between a write and its acceptance. Nocturne Memory's contribution is those three things wrapped around storage that could otherwise be files. The other comparison the README invites is vector RAG. A vector store indexes chunks and returns the nearest ones by embedding similarity; Nocturne Memory stores named nodes and returns the ones the agent asks for. Vector RAG scales to a corpus you did not write and cannot enumerate. Nocturne Memory scales to a memory you and the agent are actively curating, where the paths mean something to the agent. If your memory is a corpus, use the vector store. If your memory is a relationship with a history, the tree is the better shape, because you can point at a node and say this one is wrong.

Maintenance, licence, and what the release history implies

The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is the whole of what the repository states; it is not legal advice and the actual terms are in the LICENSE file. The release cadence in the supplied material is informative. Version 2.5.6 is titled MCP 2.0 Compatibility and Long-Form Improvements. Version 2.5.4 is titled Boot preset switching and orphan recovery, and 2.5.2 is titled major bug fixes and Chinese language support. Two things follow. First, the project tracks MCP protocol changes, so an MCP 2.0 era client is expected to work, but pinning a version is sensible if you depend on it. Second, orphan recovery appearing as a headline feature in 2.5.4 suggests that memory nodes can be left dangling when their parents change, which is the kind of failure you would hit after months of tree edits. That is a maintenance cost you inherit: not just upgrading the package, but checking that the tree is still coherent after the agent has been writing to it. Budget for periodic review of the graph, not just of the code.

Editorial conclusion

Adopt Nocturne Memory if you run one or more persistent AI personas and want the memory to survive a switch between Claude Code, Gemini CLI, Cursor, or a local model, and if you are willing to run a Python service plus a Node-built dashboard next to your client. Do not adopt it if your requirement is retrieval over a large document corpus, or if you need a hosted service with an SLA: the public demo endpoint at https://misaligned.top/mcp is read-only and exposes only read_memory and search_memory. Before committing, verify three things yourself: that your client can reach backend/mcp_server.py over stdio (Antigravity needs backend/mcp_wrapper.py instead), that your chosen backend is SQLite or PostgreSQL as the badges state, and what the dashboard's human-confirmed cleanup step actually requires in your deployment, since the README describes cleanup as needing human confirmation without specifying the confirmation mechanism.

Official sources

1. Dataojitori/nocturne_memory on GitHub
2. License: MIT
3. Project website
4. README
5. Releases