ai-memory: Long-Term Memory for AI Coding Agents

AI coding agents forget everything the moment you close the terminal. Quit Claude Code mid-task and open Codex in the same folder, and you're re-explaining the architecture, the approaches that already failed, and the open questions — from scratch. ai-memory is one developer's answer to that: a free, open-source memory server that sits underneath whichever coding agent you're using and survives the switch.

It's mostly built by one person, it ships new releases almost daily, and — unusually for a project this active — every number in this piece is something you can go check on GitHub or Docker Hub yourself. It's a familiar shape for this series: Aider, another AI coding tool run largely by one developer, followed the same one-person, ship-fast pattern.

What ai-memory actually does

Per its own GitHub description, the pitch is direct: "Quit Claude Code mid-task, start OpenAI Codex in the same directory, continue without re-explaining the architecture…" The mechanism, laid out in the README, is a small Rust server you run locally (or on a homelab box) that hooks into whichever agent you're driving.

First-party support currently spans more than 20 tools, including Claude Code, Codex, Cursor, Gemini CLI, and OpenCode, with MCP-only support for a few more like VS Code Copilot and Zed.

Two design choices stand out. First, the memory itself isn't locked in a database — it's a git-backed folder of plain markdown files, meant to be grepped, edited by hand, or opened in Obsidian; the SQLite index underneath is explicitly a rebuildable derivative, not the source of truth. Second, capture and search work with zero API calls by default (full-text search over the markdown), with vector search and LLM-generated summaries as opt-in extras rather than requirements.

That's a deliberately unglamorous architecture for a project living in the AI-agent-tooling space. The README explains why the network story matters for teams: multiple people can point at one server and get per-project sharing with per-person attribution and audit logs, not a shared undifferentiated blob.

One name, real contributors, one very active repo

The LICENSE file is MIT, with the line "Copyright (c) 2026 Fabio Akita." That's Fabio Akita, a Brazil-based developer whose GitHub bio reads "Agile Senior Vibe Coder." He lists an affiliation with Codeminer 42 and has 20.6k GitHub followers — not an anonymous account, but also not a funded startup team.

He's not doing this entirely alone, though. The commit history credits outside contributors like abhisheksharma2411, rafaelkenedy, and fuxicodex fixing Windows CI timeouts and test flakiness, alongside akitaonrails himself and a claude co-author tag on several commits — a byline the README backs up directly, noting the codebase is "built collaboratively with Claude Code (Anthropic Claude Opus 4.7)" against a documented plan.

The repo's own numbers, checked directly on the repo page, are the kind that are hard to fake: 7.7k stars, 520 forks, 1,961 commits on the main branch, with 13 open issues and 12 open pull requests — a small, live backlog rather than a dormant star-farm.

This isn't his only project in the space. His pinned repos include ai-jail, a companion OS-sandbox for AI agents that per its own README "runs AI coding agents in an OS sandbox: bubblewrap plus Landlock, seccomp, and limits on Linux" (1.3k stars, GPL-3.0, zero open issues), plus other agent-tooling utilities like ai-usagebar and llm-coding-benchmark — evidence this isn't a one-off side quest but a pattern of shipping small, focused agent-tooling utilities — the same solo-shipping pattern that took ECC from a hackathon project to GitHub's trending page.

The release cadence is the real story

What's unusual isn't the star count — plenty of AI-tooling repos hit that. It's the shipping pace. The releases page shows ten tagged releases between September 6 and September 21, 2026 — v2.1.0 through v2.4.0, including one same-day patch release (v2.2.0 and v2.2.1, both on September 12) — for a project maintained mostly by one person. The Docker Hub image backs that up independently: 10K+ pulls, and at the time of this check it had been "Updated 26 minutes ago." That's a platform-reported number, not a badge the maintainer wrote himself.

The commit log makes the pace concrete rather than abstract. The ten most recent messages on the day this was checked include things like a fix widening "the PowerShell-hook connect deadline for slow Windows CI," a schema-version bump "for the renumbered claim migration," and a fix that excludes an internal sessions/ folder "from the reviewer's recent-page context" — the unglamorous maintenance work of a real tool with real edge cases, not a project coasting on its initial launch attention.

The engineering reasoning is public, and it's specific

The design-decisions.md doc is a rare thing: a maintainer writing down why he rejected the obvious alternatives, not just what he built. On choosing markdown-in-git over a database as the source of truth: "Backup/move story is trivial - git clone or rsync a directory. The user explicitly asked for this." On why Postgres wasn't the default: "Postgres is a real-deployment-only pain." On why the MCP tool surface stayed narrow instead of exposing dozens of tool calls to the agent: "basic-memory has ~25 tools, agentmemory has 53. Both have user confusion as a result" — a direct, named comparison against competing open-source projects in the same space, not a vague claim.

The project also publishes its own retrieval-quality numbers rather than just asserting the search works. Its benchmarks doc, run against the LongMemEval-S dataset through an in-repo, reproducible harness, reports a hit@5 score of 0.823 for the current local-embeddings default — up from 0.617 for the pre-2.0 full-text search, a +20.6 point improvement the doc attributes to two specific changes: stripping stopwords from FTS queries, and switching to an in-process embedder with corrected masked-mean pooling. It's a self-reported benchmark — there's no independent third party re-running it — but the methodology and the harness are both in the repo for anyone to rerun themselves, which is a meaningfully higher bar than a marketing claim with no numbers attached at all.

What doesn't fit the highlight reel

A few things keep this from being a clean success story.

Native Windows support is still explicitly marked "experimental" in the README, and multiple recent commits are fixes for Windows-specific CI timeouts — a platform still being stabilized in public, not one that's done.

There's no hosted product and no pricing: this is self-hosted, MIT-licensed software with no visible monetization plan, which is a real difference from the paid-tier stories in this series. There's no revenue number to report here because there isn't one to find.

And a project shipping a new tagged release almost every other day, with 13 open issues asking for things like an auto-improve dedup fix and a builtin login page for human sessions, is a project still actively finding its edges rather than one that has settled into a stable 1.0 shape.

What this generalizes to

The transferable habit here isn't "build a memory layer" — it's publishing the reasoning alongside the code. Most open-source AI tooling ships a README full of feature bullets and stops there. ai-memory ships a design-decisions.md that names the two competing projects it studied and quotes the exact tool-count numbers that made it choose a narrower interface, plus a benchmarks/ folder with a runnable harness instead of a "fast and accurate" claim with nothing behind it. For a solo builder shipping fast with Claude Code or any other agent, that's a cheap thing to add and a hard habit to keep once the star count starts climbing: write down not just what you built, but the specific number from the specific alternative you rejected — so the next person evaluating your project doesn't have to take your word for it.