DEV Community: Open-Agentic-Brain-and-Memory

Introducing Agentic Brain: one memory for all your AI coding tools

Open-Agentic-Brain-and-Memory — Sun, 18 Oct 2026 16:49:10 +0000

Introducing Agentic Brain: one memory for all your AI coding tools

Claude Code, Cursor, Codex and the rest forget everything when a chat ends, and none of them know what the others learned. Today we are launching Agentic Brain: free, open-source (Apache-2.0), self-hosted memory for AI coding tools.

Tell one tool. Every tool knows.

Decide something in Claude Code on Monday, and Cursor already knows it on Tuesday. So does your other laptop. You never explain your project twice.

How it works

Capture. Agentic Brain reads your Claude Code, Codex, Antigravity, Cursor and Kilo Code sessions into one local SQLite store.
Distill. At night, brain dream turns what it heard into a wiki it keeps rewriting, and drafts lessons for you to approve.
Rank. Memories are ranked by relevance, then by proof: how often they were used and whether you said they helped.
Inject. Before you type, a briefing of at most 2,000 tokens is written into CLAUDE.md, AGENTS.md and GEMINI.md, inside its own markers. It is ready in 84 ms (p50).
Measure. brain eval quizzes it on your own history. If a change makes it remember worse, the change does not ship.

Any connected tool can also ask for older context over MCP with brain_recall, brain_remember and brain_context. A recall over 10,000 memories takes 28 ms (p50).

Only you can read it

Memory stays on your computer. If you turn on sync, it travels as one age-encrypted blob, a Release asset on your private GitHub repo, and the key lives only in your OS Keychain. There is no account and no server of ours. A local control panel lets you search, edit, pin and delete every memory, and brain export writes everything to plain JSONL.

How it scores

On LongMemEval-S, Agentic Brain reaches 94.2% end-to-end QA accuracy with a Claude reader and judge (93.4% with a GPT judge). On LongMemEval-M, with histories of about 1.27M tokens, it scores 83.0%. On LoCoMo it scores 86.6 against 89.3 for giving the model the whole conversation, which is about 97% of that score at roughly 18% of the tokens.

Limits, plainly

There is no Windows support yet. Sync replaces the whole blob, and multi-machine sync is merge-based. Claude Desktop and ChatGPT desktop are pull-only. It needs Node 22+ and runs on macOS and Linux.

Try it

Install Agentic Brain from the site, or read the source on GitHub. Bugs and ideas are welcome as GitHub issues.

Why Your AI Coding Assistant Forgets Everything When the Chat Ends, and How to Stop Re-Explaining Your Project

Open-Agentic-Brain-and-Memory — Sun, 18 Oct 2026 08:46:53 +0000

An AI coding assistant forgets context between sessions because each chat starts with an empty context window, and nothing from the last conversation is loaded back in unless something puts it there. The fix is a memory layer that saves decisions, fixes and preferences and loads them into each new session.

You've probably felt this. On Monday you tell Claude Code you're dropping Redis for SQLite. On Tuesday you open a new chat, or open Cursor, and it suggests a Redis client. You explain it again. This article covers why that happens, what a useful session memory holds, and how to get it back into the next chat without handing your code to someone else's server.

Why an AI coding assistant forgets context between sessions

It isn't forgetfulness. The model doesn't learn from your chat. It reads whatever is in its context window for that conversation and answers from that. When the chat ends, the window goes away. A new chat gets a new window with your system prompt, your open files and your first message in it, and that's all.

A bigger window doesn't fix this. It only changes how much you can fit into one conversation. A larger window still starts empty, and long sessions get slower and noisier as they fill up. What you want is persistent context: a small, curated set of facts that is there at the start every time.

The problem gets worse when you use more than one tool. Claude Code, Cursor and Codex each keep their own history, and none of them can see the others'. What you taught one is invisible to the rest. A second laptop makes it worse again.

What is worth remembering

The obvious idea is to save everything and feed it back. That fails quickly. Transcripts are long, repetitive and full of dead ends. Pasting them into a new chat uses up the window you were trying to protect.

Most of what you'd re-explain falls into three kinds of thing:

Decisions. "We use SQLite, not Redis, because this runs on one box." The reason matters as much as the choice.
Fixes. "The flaky test was a timezone issue in the fixture, not the parser." Next time you hit the same error, you want that answer in seconds.
Preferences. "Always use pnpm. Never npm." Small rules like this are the ones people get tired of repeating.

Each of these is a sentence or two. A few hundred of them still fit in a small briefing, which is the point. At Agentic Brain, we capture these three things from your coding sessions, rank them, and drop the rest.

Tag memories by project

A decision about one repo shouldn't leak into another. Agentic Brain files each memory under the project it came from, found by walking up from your working folder to the nearest .git. When you open a folder, that repo's history comes first. It isn't walled off, though. A recall can search one project or all of them, so a lesson from one codebase can still help in another.

How memory gets back into the next chat

There are two paths, and they work together.

A start-up briefing

When a session starts, a hook runs before you type anything. It picks the most relevant memories for the folder you're in and injects them as a briefing. Ours is capped at 2,000 tokens, and in our own timing it's ready in 84 ms (p50). The cap is deliberate. A briefing that grows without limit just recreates the transcript problem.

The same briefing reaches every supported tool: Claude Code, Cursor, Codex, Antigravity and Kilo Code (beta). So the SQLite decision you made in Claude Code on Monday is already known to Cursor on Tuesday.

Recall on demand over MCP

Two thousand tokens can't hold everything, and it shouldn't try. When the assistant needs something that isn't in the briefing, it asks. Agentic Brain exposes MCP tools for this: brain_recall, brain_remember, brain_context and a load-my-brain command. In our own measurements, recall across 10,000 memories takes 28 ms (p50). Search is hybrid, combining keywords with meaning, so "why did we drop the cache layer" can find a note that says "Redis removed".

Those figures come from our own benchmarks, so treat them as ours and not as an independent test. You can check how well recall works on your own history with brain eval, which scores it against what you've actually done.

Across machines

If you work on a desktop and a laptop, the briefing should match on both. At start-up, Agentic Brain merges in what your other machines have learned. You can read how the whole flow fits together on the Agentic Brain site.

Keeping it yours

Memory about your code is sensitive. It holds your architecture choices, your mistakes and sometimes your internal names. So where it lives matters.

Agentic Brain keeps memories in a local SQLite database on your machine. There's no account and no server of ours. For sync, memory is encrypted with age and stored as a Release asset in your own private GitHub repo. The key stays in your OS Keychain. Only you hold it, which also means nobody can recover your memory if you lose it. A leaked repo or token exposes nothing readable.

You also stay in control of the contents. A local control panel lets you read, edit, pin or delete any memory. If one is wrong, fix it. If you'd rather not start from old sessions, start fresh. It's free and Apache-2.0, built by Rohith, Chandan and Sushmita, so you can read the code too.

If you switch between AI coding tools or machines, try it on one repo for a week and see whether you stop re-explaining. Install Agentic Brain from the site.

Frequently asked questions

Why does Claude Code forget my project between sessions?

Claude Code reads only what's in the current context window, and each new session begins with a fresh one. Nothing you said earlier is carried over unless it's written down somewhere that gets loaded at start-up. A memory layer does that loading for you.

Can an AI coding tool remember decisions without uploading my code to a hosted service?

Yes. Agentic Brain stores memories in a local SQLite database and needs no account. If you sync between machines, the data goes up age-encrypted to your own private GitHub repo, with the key in your OS Keychain.

How many tokens should a session start-up briefing use?

Keep it small enough that it never crowds out your actual work. Agentic Brain caps the briefing at 2,000 tokens and fetches anything else on demand through MCP recall. That's a design choice we made, not a universal standard.

Does a bigger context window fix this?

No. A bigger window holds more within one chat, but the next chat still starts empty. You still need something that carries the important facts across sessions.

Can Claude Code and Cursor share memory?

Not on their own, since each keeps its own history. With a shared layer like Agentic Brain, both read from the same store, so a decision made in one is known to the other.

Why Your AI Coding Tools Should Share One Memory, Not Each Keep Their Own

Open-Agentic-Brain-and-Memory — Sun, 18 Oct 2026 08:00:44 +0000

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.