AI coding assistant persistent memory is a store of your decisions, fixes and preferences that outlives any single chat, so the next session starts with what the last one learned. Most tools now keep some version of this. The catch is that each keeps its own, and if you use more than one tool or more than one machine, those copies drift apart.
The quiet cost of re-explaining your project every Monday
You open Claude Code on Monday and type the same paragraph you typed last week. The repo uses pnpm, not npm. Redis is gone and SQLite replaced it. Migrations run through a script, never by hand. The assistant nods, and then you do it all again in Cursor an hour later.
No single repetition hurts. The cost is that it never stops. As an illustration, not a measurement: if you spend ten minutes briefing tools at the start of a session and open four sessions a day, that is forty minutes a day. Time your own briefings for a week and use your number, not ours.
There is a second cost that is harder to see. When you are tired, you skip the briefing. The assistant then suggests npm, or reaches for Redis, and you spend a review cycle undoing it.
Why AI coding assistant persistent memory breaks across tools
Per-tool memory has an obvious appeal. It ships with the tool and needs no setup. The problem shows up the day you add a second tool.
Say you tell Claude Code that the team dropped Redis for SQLite. That fact now lives in Claude Code's notes. Cursor never saw the conversation, and Codex never will. Each tool builds its own partial picture of the project, and the pictures disagree.
Silos also go stale. A decision you reverse in one tool stays alive in the others, and nothing tells you. You end up with three assistants holding three versions of your architecture, and you are the only thing keeping them in sync.
Rules files are the usual workaround. CLAUDE.md, Cursor rules and AGENTS.md are all useful, and we use them. But they are files you maintain by hand, one per tool, and they only hold what you remembered to write down. A fix you made at 11pm and never documented is not in any of them.
What a memory layer you own should do
If memory is going to be shared, the question becomes who holds it. Our view is that you should. Here is what we think that requires.
File memories by project
A memory about your billing service should not show up while you edit a side project. Open Agentic Brain & Memory (OpenAB) tags each memory by project, found by walking up from the current folder to the nearest .git. Open a repo and that repo's history comes first.
Stay searchable across projects
Walls between projects have a cost too. You solved a flaky-test problem in one repo in March, and you want that answer in another repo in October. Recall should be able to search one project or all of them. OpenAB also keeps a map of up to 20 projects in the global CLAUDE.md, AGENTS.md and GEMINI.md files, so a tool knows what else exists.
Be bounded and fast
Memory that floods the context window is worse than no memory. A start-up hook injects a briefing of at most 2,000 tokens, ready in 84 ms (p50). On-demand recall over 10,000 memories takes 28 ms (p50) through MCP tools such as brain_recall and brain_context. Both figures come from OpenAB's own measurements, published on the OpenAB site. You can score recall on your own history with brain eval instead of taking our word for it.
Be readable, editable and deletable
You should be able to see every memory, fix the wrong ones, pin the important ones and delete the rest. A local control panel does that. Memory you cannot inspect is memory you cannot trust, and wrong memories are worse than missing ones.
Stay on your side of the wire
At OpenAB, we built it so there is no account and no server of ours. Memory sits in a local SQLite database. To sync across machines, it is encrypted with age, and the key stays in your OS Keychain. The encrypted blob is stored as a Release asset in your own private GitHub repo. A leaked repo or token exposes nothing readable. The flip side is real: only you hold the key, and if you lose it, nobody can recover your memory.
Start from your past AI work, or start fresh
Some people have months of Claude Code and Cursor history with useful decisions buried in it. Others want a clean slate, maybe because old sessions contain dead ends or things they would rather not keep. Both are fair, and neither should be forced.
OpenAB lets you do either. You can seed memory from past AI work, then prune it in the control panel. Or you can begin empty and let it fill as you work. Because you own the store, the choice is yours and so is the cleanup. Nothing is locked in a vendor's database, so changing your mind costs you a delete, not a support ticket.
Today it covers Claude Code, Cursor, Codex and Antigravity, with Kilo Code in beta, which makes five tools in total. It is free and open source under Apache-2.0, built by Rohith, Chandan and Sushmita. If you want to see how the pieces fit before installing, start with the overview of how a shared memory layer works, then Install OpenAB and see what your first briefing contains.
Frequently asked questions
What is persistent memory in an AI coding assistant?
It is saved knowledge about your project, such as decisions, fixes and preferences, that carries over from one session to the next. AI coding assistant persistent memory means you stop re-explaining the basics at the start of every chat.
Why do AI coding assistants forget everything between chats?
A chat starts with an empty context window, and the model only knows what is placed in it. Unless a tool saves something and puts it back at the next start, the earlier conversation is gone. OpenAB does that saving and re-injecting step for every tool, as a short briefing at session start.
Does Claude Code have persistent memory?
Claude Code reads CLAUDE.md files, which give it standing instructions you write and maintain. That helps, but it is a file you edit by hand, and other tools do not see it. A shared memory layer adds captured decisions and fixes across tools on top of that.
How do I share memory between Claude Code and Cursor?
Use one memory store that both tools read from, rather than separate notes in each. With OpenAB, both connect to the same local database through a start-up hook and MCP tools. Something you tell Claude Code on Monday is available to Cursor on Tuesday.
Can I import my past AI conversations into a shared memory?
Yes. OpenAB lets you start from your past AI work or start fresh, and you decide which. After the import you can read, edit, pin or delete anything in the control panel.
Can I delete memories I no longer want kept?
Yes. Every memory can be read, edited, pinned or deleted from the local control panel. Because the data sits in your own SQLite file and your own private GitHub repo, deleting it is in your hands, not a vendor's.
Is my code or memory sent to the cloud?
There is no OpenAB account and no server of ours, so nothing goes to us. If you turn on sync, the memory goes into your own private GitHub repo as an age-encrypted blob, and the key never leaves your OS Keychain.
How is this different from a rules file?
A rules file holds what you chose to write down, for one tool. OpenAB captures decisions, fixes and preferences as you work and shares them across tools. The two work well together: keep rules for hard constraints and let memory cover everything you would forget to write.
Top comments (0)