If you have ever closed Claude Code halfway through a feature, opened Codex the next morning, and spent twenty minutes re-explaining what you were building, you already understand the problem that long-term memory for AI coding agents is trying to solve. The agent that helped you yesterday does not remember today — or, if it does, its notes live in one tool, on one machine, in a format no other tool can read. ai-memory is an open-source project that fixes that specific pain: one shared, long-term memory that follows you across coding agents, projects, and machines. At the time of writing it has more than 13,000 GitHub stars, and it is worth understanding before you wire another agent into your workflow.
This is not another “second brain” app, and it is not a hosted memory API that charges you per fact stored. ai-memory is a self-contained Rust binary, released under the MIT licence, that captures what your agents do, consolidates it into readable markdown pages, and hands it to the next agent — whichever vendor that agent comes from. In this deep-dive we cover what it is, what it can do, how it works, how to get started, and — honestly — where it will disappoint you. If you run a development team that now uses two or three different coding agents, this is the tool to evaluate first.
What ai-memory is
ai-memory describes itself in one line: “Long-term memory for AI coding agents. Quit Claude Code mid-task, start OpenAI Codex in the same directory, continue without re-explaining the architecture, the failed approaches, or the open questions.” That sentence is doing a lot of work, so let us unpack it.
Most coding agents already have some form of memory. Claude Code keeps notes. Cursor remembers things about your project. The problem is that each of those memories is siloed. The notes live on one machine, belong to one agent, and drop out of view the moment you switch tools or hand the work to a teammate. ai-memory removes those limits by sitting underneath all of them: more than twenty harnesses — Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi, Kiro, and others — feed one shared memory through lifecycle hooks and MCP registrations.
The source of truth is deliberately boring, and that is a compliment. It is a git-backed wiki of ordinary markdown files. You can grep it, open it in Obsidian, edit it by hand, or rsync it to another machine. The database is a derived index that can always be rebuilt from the files. There is no vector store to maintain and no content locked in a binary blob. For a business, that matters: your institutional knowledge is not held hostage by a vendor’s export button.
What long-term memory for AI coding agents actually gives you
The headline feature is the cross-agent handoff, and it is a typed protocol rather than a vague summary. Each handoff has an owner and is claimed exactly once, so two agents cannot both pick up the same half-finished task and diverge. Quit Claude Code mid-task, open Codex in the same directory, and the next agent picks up a handoff that says where you left off, what failed, and what is still open.
It can also carry the session, not just a summary. Starting an agent with ai-memory run gives the new agent the shared workstream plus a private, temporary local projection of the previous agent’s visible native history, for exact details the bounded startup packet omitted. The remote server receives only the harness and session identity — never the local transcript path or body. Direct harness launches behave exactly as before, so you are not forced into a wrapper to get value.
- It follows you across agents. One memory for Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and twenty-plus other harnesses, instead of a separate notebook per tool.
- It follows you across projects. A small profile of how you usually work — your package manager, test layout, architecture habits — reaches every new repository at session start, so you stop re-explaining yourself on each new codebase.
- It follows you across machines. Memory lives on a server you run — the same laptop, a homelab box, or anywhere else — so the project you left on the desktop is the project you resume on the laptop.
- It works for a team. Point everyone at one server and what one person’s sessions learn, everyone’s agents can retrieve. Knowledge is shared per project; personal handoffs stay personal. Multi-user auth, per-person attribution, and an audit log are built in, not a paid tier.
- It captures silently. Lifecycle hooks record prompts, tool calls, and session boundaries, sanitised at a typed privacy boundary before anything is stored. You do not have to ask it to remember anything.
- It ages memory without an LLM. Memory decays on a schedule you can tune per tier, and memory you actually use decays slower. Cold episodic notes can be compacted to their durable facts — file paths, error codes, decisions — instead of being dropped. Near-duplicates collapse into one, and likely contradictions get flagged, all with zero API calls.
The zero-LLM default is the detail that separates ai-memory from most of the memory tools it competes with. Capture, search, and handoffs all work with no API key. That is not a marketing claim about a free tier; it is an architectural choice. You can add an LLM later for an opt-in background “dream” pass that rewrites cold clusters of notes into single coherent pages while you are idle — it cancels as soon as you come back to work, and it never deletes a source — but the default path never needs one.
How ai-memory works under the hood
The pipeline is four stages, and the project states it plainly: capture, consolidate, recall, handoff. Agents emit sanitised observations through lifecycle hooks as you work. At session end, those observations become coherent markdown pages in the project’s wiki. At the next session, in any agent on any machine, the agent gets a bounded brief and can search everything — full-text, entities, links, and optionally vectors — fused into one ranking. Cross-agent handoffs then pass the baton explicitly.
Three design decisions are worth noting if you are evaluating this for a team. First, nothing is hard-deleted: the original stays in git, and the version chain lets you restore a page. That makes the “the agent remembered it wrong” failure mode recoverable, which is not true of fact-row stores. Second, access-weighted retention is always on because it can only keep memory longer — the parts that rewrite or drop content, such as compaction and per-tier decay curves, stay off by default until you turn them on. Third, the project publishes a measured write ceiling of around 700 writes per second rather than a guessed one, and it ships an audit log recording every mutation. Those are the signals of a project that expects to be trusted with production knowledge, not just demoed.
Platform support is broad: Linux and macOS are fully supported, Windows works via WSL2 with native Windows support still experimental, and there is a NixOS module. There is also an optional server-rendered management console for user administration, session inspection, and personal MCP API keys — but note it needs both a compile-time and a runtime opt-in, so do not expect it in a default binary build.
Why ai-memory is trending now
Timing explains the star count. The project was created in May 2026, and it is still being actively updated — its last commit at the time of writing landed on 24 October 2026, the day of this article. That is a young project with a fast-moving surface, which is both the opportunity and the risk.
The opportunity is that the problem it solves got dramatically worse in 2026. A year ago, a team standardised on one coding agent. Today, the same developer might use Claude Code for a refactor, Codex for a review, Cursor for a quick fix, and an open harness for a side project — and each tool starts from zero. The cost is not the re-explanation itself; it is the repeated mistakes. The failed approach from Tuesday gets retried on Thursday because Thursday’s agent never saw Tuesday’s dead end. A shared handoff that records what failed is worth more than a shared summary of what succeeded.
The second driver is cost. Every re-explained context window is tokens you pay for, and every repeated investigation is engineering time. A bounded startup brief — the project deliberately limits how much memory is injected at session start — is cheaper than dumping a whole wiki into context, and more reliable than hoping the agent re-discovers the architecture. Teams that measure agent spend usually find context, not model choice, is where the bill grows.
The third driver is the comparison with alternatives. Fact extractors such as Mem0 give you opaque fact rows. Temporal knowledge graphs such as Zep give you a graph database to run. Hosted memory APIs give you a monthly bill and a data-residency question. ai-memory’s pitch is files you own, zero required API spend, offline operation, and per-project team sharing — a combination none of those alternatives offers in one package. Whether that combination fits your team depends on how much you value owning the files versus having someone else run the service, which brings us to the honest limitations.
From our experience: honest limitations
We build with agent tooling every day at MTD Technologies, and the pattern we see is consistent: the tool is rarely the bottleneck; the governance around it is. ai-memory is no exception. Here is what to watch before you roll it out.
Memory quality is a discipline, not a feature. Automatic capture means automatic capture of bad sessions too — wrong conclusions, abandoned experiments, and outdated decisions all become pages that a future agent can retrieve with confidence. The decay, dedup, and contradiction-flagging machinery helps, but it is partly off by default and it is not magic. Budget time for someone to curate the wiki, the same way you would review documentation. An uncurated memory store becomes a confident liar.
Self-hosting is real work. One binary is genuinely easier than a graph database plus a vector store, but you still own the server, the backups, the bearer tokens, and the multi-user auth. The Docker quick-start ships without authentication unless you run init, and it binds to loopback only — fine on a laptop, not a team deployment. Do not expose a team server without reading the security documentation first, and treat the bearer token like a production credential, because it is one.
The support matrix is wide, not deep. More than twenty harnesses are listed, but the integration type varies — some are full support, some are MCP-only, some are hooks-only. Check the per-agent notes in the project’s support matrix for the exact tools your team uses before you promise anyone a seamless handoff. An MCP-only integration will not capture the lifecycle hooks that make the silent capture work.
It is young and moving fast. A May 2026 project with daily commits will change its configuration surface, its docs, and possibly its defaults. That is normal for a trending open-source tool, but it means you should pin a release, test upgrades in a scratch project, and not build internal runbooks that assume today’s flags are permanent.
When not to use it: if your team uses exactly one agent on one machine and never hands work between people, the built-in memory of that agent plus a well-kept project file will do. ai-memory earns its keep at the point where agents, machines, or people multiply. Below that threshold, it is overhead.
Getting started with ai-memory
On Linux and macOS, the documented path is two commands and no root access. First, install the binary — the install script downloads the release for your OS and CPU and checks it against the release’s published SHA-256 checksum, refusing to install on a mismatch:
curl -fsSL https://github.com/akitaonrails/ai-memory/releases/latest/download/install.sh | shai-memory setup
The setup step creates the data directory with a bearer token in an owner-only file, starts a per-user service (systemd user service or a launchd LaunchAgent), and wires MCP, hooks, and Agent Skills for every agent it finds — or the ones you name with --agent. It shows the plan, including where it found each agent, and asks first; answer yes, or type the numbers of the agents to wire. Use --plan to print the plan without changing anything, and re-running setup changes nothing, which makes it safe to re-run after installing a new agent.
- Install with the checksum-verified script above, then run
ai-memory setupand review the plan before confirming. - Restart your agents, then ask one of them: “What do you remember about this project?” — that first answer tells you whether the wiring worked.
- Start in a single project, not across your whole machine. Let one handoff succeed — quit one agent mid-task, resume in another — before you point a team at a shared server.
- Turn on the management console only if you need multi-user administration, and keep the bearer token out of chat logs, screenshots, and shared docs.
- Schedule a monthly memory review: prune stale pages, resolve flagged contradictions, and confirm the decay settings match how long your projects actually live.
Claude Code and Codex users can also wire the agent as a marketplace plugin instead — the binary is still installed as above — and Codex will ask you to trust the hooks. Windows users get a PowerShell equivalent, and Arch and Fedora users get native packages. Docker is available too, with the authentication caveat noted above.
Frequently asked questions
What is long-term memory for AI coding agents?
It is a shared store of what your coding agents have learned about a project — architecture, decisions, failed approaches, and open questions — that survives across sessions, agents, and machines, so the next agent does not start from zero. ai-memory implements it as a git-backed markdown wiki with a derived search index.
Is ai-memory free?
Yes. It is open source under the MIT licence, and its default capture, search, and handoff path uses zero LLM calls, so there is no API bill for the core workflow. You pay only for the machine you run it on, plus any optional LLM features you choose to enable.
Which coding agents does ai-memory support?
More than twenty harnesses, including Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi, and Kiro. Integration depth varies — some are full support, some MCP-only, some hooks-only — so check the project’s support matrix for your exact tools.
Does ai-memory send my code to a cloud service?
Not by default. Memory lives on a server you run, the source of truth is local markdown files, and the zero-LLM path makes no API calls. The ai-memory run handoff sends only harness and session identity to the remote server, never the local transcript path or body. Optional LLM features, if you enable them, will involve whichever provider you configure.
Should a small team self-host ai-memory, or wait?
Try it on one machine and one project first. If your team already switches between agents or hands work between people, the handoff alone justifies a pilot. If you use a single agent on a single machine, wait — the built-in memory plus a good project file will serve you until that changes.
The bottom line
ai-memory is the most convincing answer we have seen to a problem that is only going to grow: coding agents are multiplying, and none of them remembers what the others did. A git-backed markdown wiki, zero-LLM by default, claim-once handoffs, and team sharing in one MIT-licensed binary is a strong combination — provided you treat memory curation and server security as part of the job, not an afterthought. Start with one project, prove one handoff, and let the memory earn its keep before you scale it.
If your team is adopting coding agents and the context keeps getting lost between tools, talk to MTD Technologies about AI integration and automation — we build agent workflows that survive contact with real projects. You can also browse our AI Tools Directory for more tools we have reviewed, or contact us to scope a pilot.