# Engrim gives four coding agents one local SQLite memory layer > Source: > Published: 2026-09-07 06:33:11+00:00 # Engrim gives four coding agents one local SQLite memory layer **Timothy Gordon's open-source tool preserves project decisions across Claude Code, Cursor, Windsurf and Google Antigravity sessions.** By [RuntimeWire Staff](/author/runtimewire-staff) ยท Published Primary source: [GitHub](https://github.com/timgordontg/engrim) ## Why it matters Coding agents are becoming interchangeable interfaces over the same repositories. Engrim tests whether project memory can become an independent, user-owned layer instead of another model-specific feature. [Timothy Gordon](https://github.com/timgordontg?ref=runtimewire) released Engrim 1.3.0 on September 7th, extending his local memory engine across four AI coding environments: Claude Code, Cursor, Windsurf and Google Antigravity. The [open-source project](https://github.com/timgordontg/engrim?ref=runtimewire) gives those agents a shared, project-scoped store for architectural decisions, constraints, feedback and work in progress. Engrim keeps that material in SQLite on the developer's machine, retrieves a small selection when a session starts and searches it again as prompts arrive. Gordon describes himself as a researcher in quantitative finance, artificial intelligence and machine learning, with a background spanning software development, analytics and trading. He built Engrim around a frustration familiar to anyone using coding agents on work that lasts longer than one context window: clearing a session also clears much of the reasoning that produced the code. "Cross-session memory for Claude Code - so you can `/clear` aggressively and never lose the why," Gordon wrote in the project's [submission documentation](https://github.com/timgordontg/engrim/blob/main/SUBMISSION.md?ref=runtimewire). The document presents Engrim as a way to preserve the rationale behind decisions when developers clear sessions frequently. That makes Engrim a founder-maintainer's answer to a problem Gordon encountered in his own workflow. The project has no hosted account requirement or API key. Installation is a pair of terminal commands: ``` pip install engrim engrim setup ``` The [Python package](https://pypi.org/project/engrim/?ref=runtimewire) now lists version 1.3.0 as uploaded on September 7th; the preceding version, 1.2.2, was uploaded on August 12th. The new version turns a tool originally centered on Claude Code into a cross-agent memory layer, using native hooks where available and a Model Context Protocol server for other clients. ### The project owns the memory, not the agent Engrim's central design choice is to separate durable project knowledge from any particular model's conversation history. Gordon's repository puts the thesis bluntly: "The models are disposable utilities; your project's decisions are not." A developer can record a decision, such as choosing PostgreSQL for a service or rejecting a particular authentication scheme, and retain its rationale after switching agents. Engrim tracks which environment created each record and can reload memories produced through Claude Code, Cursor, Windsurf or Antigravity into a later session. The current implementation stores two distinct kinds of history. Curated memories hold decisions, facts, feedback, project state, user preferences and references. An append-only transcript log acts as a flight recorder, preserving activity without automatically dumping the full history back into the context window. That separation matters because unlimited retention can recreate the problem Engrim is trying to solve. A giant conversation archive may contain the correct answer somewhere, while still forcing the model to sort through stale or irrelevant material on every turn. Engrim instead builds a budget-capped memory pack. It combines SQLite FTS5 keyword retrieval with local static embeddings, then merges the rankings through reciprocal-rank [fusion](/models/openrouter/fusion). Its MCP server exposes tools for adding records, recalling them, building a context pack and reviewing recent transcripts for decisions that have not yet been saved. Users can also mark old records as superseded without deleting the history. A resume pointer identifies the next task for the following session. Before clearing, the `engrim review` command scans recent activity and warns when a likely decision may still be missing from curated memory. ### Gordon is betting against context-window accumulation AI labs have continued expanding context windows, giving coding agents room to ingest larger repositories and longer conversations. Gordon is taking the opposite operational approach: retain less material in the active prompt, while making the selected material more durable. Engrim's repository claims that Gordon tested the system across 105 sessions on a 50,000-line algorithmic trading codebase. According to the project, more than 153,000 tokens of accumulated work were reduced to an active memory pack below 1,000 tokens, with 186 unit tests passing and no regressions attributed to switching agents. Those figures come from Gordon's own test case and have not been independently benchmarked. They still clarify what Engrim is optimizing for. The target is continuity per token, measured by whether a new session receives the few decisions it needs without carrying the entire conversation that created them. Engrim says its records, logs and embeddings stay local and that it requires no API key. The project's [security documentation](https://github.com/timgordontg/engrim/blob/main/SECURITY.md?ref=runtimewire) also says Engrim collects no telemetry. Its default semantic-search mode downloads a small embedding model from Hugging Face on first use, caches it and then runs locally. Developers can set `ENGRIM_EMBED=off` to use a standard-library lexical mode without the model download. ### Local memory is already a busy category Engrim enters a growing group of projects trying to give coding agents memory outside their native sessions. [Diaspar](https://diaspar.dev/?ref=runtimewire) supports local SQLite and remote PostgreSQL storage through MCP. [Palimem](https://palimem.com/?ref=runtimewire) emphasizes scoped records, supersession and an audit trail. [Sessionmem](https://github.com/catfish-1234/sessionmem?ref=runtimewire) stores cross-session memory locally and adds automatic summarization. Other GitHub projects, including [Engram](https://github.com/bmbnexus/engram?ref=runtimewire) and [mcp-memory-sqlite](https://github.com/pavex/mcp-memory-sqlite?ref=runtimewire), also pair SQLite with MCP-based retrieval. MCP lowered the integration cost for this category. Anthropic [introduced the protocol in November 2024](https://www.anthropic.com/news/model-context-protocol?ref=runtimewire) as an open standard for connecting AI tools to external data and services. A memory engine can now expose one server interface to several compatible clients instead of building every connection from scratch. Engrim's differentiation rests on the lifecycle around that server. Gordon has built hooks to capture activity, inject memories at session start, retrieve records during prompts and review what may be lost before a context clear. The breadth of the integrations is easy to count. Retrieval quality, stale-memory handling and reliability across real projects will decide whether developers trust it with months of accumulated decisions. The project's [roadmap](https://github.com/timgordontg/engrim/blob/main/ROADMAP.md?ref=runtimewire) points toward a resident retrieval process, reranking, near-duplicate detection, export tools and feedback based on whether an injected memory proved useful in the subsequent conversation. Gordon is keeping the underlying bet consistent: store the durable parts of software work in a small local database, then let developers change models without explaining the project from the beginning each time.