Engrim ships a local SQLite memory store that survives switching between Claude Code, Cursor, Antigravity and Codex

Engrim, a local-first memory store for coding agents, reached the Hacker News front page on 7 September with 79 points on its Show HN submission. The project is on GitHub under the MIT licence, has 164 stars and was created in June, and its author reports a case study run against a 50,000-line trading codebase across 105 sessions.

What Engrim actually stores

Engrim keeps a project-scoped SQLite database at ~/.engrim/memory.db and treats each entry as a piece of episodic memory: an architectural decision, a user constraint, a piece of state the agent needs later. Raw conversation history goes into a separate Flight Recorder table, and the curated memory table is what the agent sees when a new session opens.

Retrieval is a hybrid of SQLite FTS5 keyword search using the porter stemmer and a static vector index built with the model2vec embeddings library, combined by reciprocal rank fusion. The stated aim is that a fresh session reloads under 4,000 characters of relevant context, rather than replaying the full history at every turn.

The point is that the store outlives the model

Every mainstream coding agent already has some notion of memory, and that is the problem the project addresses. Anthropic's Claude Code, Cursor, Windsurf, Google Antigravity and Codex CLI each keep their own record of what the project is, in their own store, and none of those records survives a move to a different tool. Engrim sits underneath all of them.

The wiring is per-agent. Claude Code is hooked through SessionStart and Stop. Google Antigravity uses PreInvocation and Stop hooks. Cursor and Windsurf talk to Engrim through the Model Context Protocol over stdio. Codex CLI has both hooks and an MCP server. The agent can write to memory itself when it decides something matters, or the developer can run engrim add to save a decision by hand.

The case study, and where the numbers come from

The README's headline number is a 99 percent cut in reloaded context cost, measured by the author on a working algorithmic trading codebase. The specifics: 153,000 tokens of work compressed into a memory pack under 1,000 tokens across 105 continuous sessions and 186 unit tests, with the author reporting zero regressions and zero architectural drift when switching between Antigravity, Claude Code and Cursor on the same repo.

Those are the author's own figures, from one codebase and one workflow. The value of the case study is that the workflow is spelled out, not that the ratio is a benchmark. Whether a team's codebase compresses that far depends on how much of its context is decisions worth keeping and how much is turn-by-turn noise a fresh agent does not need.

The trade-off for adopting it

Engrim is Python 3.10 or later and installs from PyPI. It publishes to a static local file, which is its whole design and also its whole constraint: sharing memory across a team means putting ~/.engrim/memory.db in version control, or building the sync tier the project does not ship. A team that already relies on a hosted memory service and wants central control gains nothing here. A team that wants to switch coding agents without teaching the next one what the last one already knew is the reader this is for.

Source

• timgordontg/engrim, MIT-licensed repository
• Show HN thread, 79 points on Hacker News as of 7 September 2026