For the last few months I've been jumping between Claude Code, Cursor, OpenCode, Codex CLI and Gemini CLI almost every day. Not because I'm chasing the latest shiny thing, but because each of them is good at something different. Claude is great at architectural discussions, Cursor feels natural when I'm already inside the editor, Codex is excellent for quick terminal work. Switching between them just became part of my workflow.
What surprised me wasn't how different they were, but how isolated they were from each other.
I'd spend an hour discussing a refactoring with Claude Code, agree on a new structure, rename a couple of components, decide to split a service into smaller modules and even explain why we were doing it. Then I'd open the same project in Cursor to continue working.
As far as Cursor was concerned, none of that had happened.
The code reflected some of those decisions, of course. But the reasoning didn't. The trade-offs didn't. The little implementation details that never make it into commit messages didn't either.
At first I thought this was just another context window problem. Bigger context windows would help, I thought. Or maybe better memory. Or maybe chat history shared between IDEs.
The more I worked with these tools, the more I realized that none of those ideas actually solved the real problem.
The problem isn’t only that AI forgets.
The problem is that knowledge created during development usually never becomes part of the project.
They're not.
Conversations are temporary. Projects aren't.
If an hour-long discussion with an AI results in an important architectural decision, why should that decision remain trapped inside a chat session? Six months later neither I nor the AI will remember it, and the next person joining the project definitely won't.
That realization completely changed how I started thinking about "AI memory".
I stopped asking how to preserve conversations and started asking a different question:
How do we turn useful conversations into project knowledge?
Once you look at it that way, the solution becomes surprisingly obvious.
The knowledge has to become part of the project.
Not part of Claude.
Not part of Cursor.
Not part of some proprietary database that only one tool understands.
Part of the repository itself: Markdown files, architecture notes, ADRs, implementation documentation and project conventions — things that can be versioned, reviewed, searched and edited without depending on a specific AI model.
Things that can be versioned, reviewed, searched, edited and read without needing a specific AI model.
That idea eventually became RMS Memory. RMS Memory is an open-source MCP server built around this idea.
https://github.com/max-ramas/rms-memory-mcp
Despite the name, I don't really think of it as a "memory" system anymore. It's closer to a shared knowledge layer that sits between the project and whichever AI agent happens to be working on it today.
Instead of trying to preserve chat history forever, it continuously captures useful project knowledge, stores it as Markdown and makes it available through MCP.
The interesting part is what happens after that.
I can start implementing a feature in Claude Code, continue it in Cursor, open Codex CLI to review something and later ask Gemini to work on a completely different part of the project.
They're all different tools.
Different models.
Different conversations.
But they're reading the same knowledge.
That's a very different idea from sharing chat history.
The chat doesn't matter anymore.
The project does.
One thing I also discovered is that this approach doesn't replace code indexing tools at all.
I've been using RMS Memory together with Codebase Memory, and they complement each other surprisingly well.
Codebase Memory understands the structure of the codebase. It knows where symbols are defined, how modules are connected and what depends on what.
RMS Memory knows why those modules exist, why a certain decision was made, which conventions the project follows and what problems have already been solved.
One understands the code.
The other understands the project.
Together they give AI agents far more useful context than either one can provide on its own.
The other unexpected benefit is documentation.
I've never met a developer who genuinely enjoys writing documentation after finishing a feature. Usually you tell yourself you'll do it later. Then another task appears, then another one, and eventually the documentation falls behind reality.
AI changes that dynamic.
If an agent has already participated in the discussion and understands what just happened, writing down the important parts costs almost nothing. Updating an ADR, adding implementation notes or expanding the architecture documentation becomes a natural continuation of the work instead of a separate task that everyone keeps postponing.
That's probably the biggest shift for me.
RMS Memory isn't really about helping AI remember things.
It's about making sure that valuable knowledge stops disappearing into chat histories.
Once knowledge belongs to the project instead of a conversation, switching IDEs becomes trivial. Changing AI providers becomes trivial. Even replacing today's models with whatever comes next becomes much less painful.
The repository keeps accumulating knowledge.
The tools simply learn to use it.
I have a feeling that's a much more durable approach than trying to build bigger and bigger memories for individual AI assistants.
Installation
Getting started is simple.
If you already have Rust installed, you can install RMS Memory directly from crates.io:
cargo install rms-memory-mcp
Pre-built binaries are also available for major platforms in the GitHub repository:
Top comments (0)