fullauto.online

Tools

Engrim: local-first memory that survives context clears

Every time you clear your agent's context, months of architectural decisions vanish. Engrim fixes that with a local SQLite store that works across Claude Code, Cursor, Antigravity, and Codex.

Published
9 Sep 2026
Reading
9 min
Class
tools

half-life 90dfrom 9 Sep 2026

Server racks with blue LED indicators in a dark data centre

You spend three hours debugging a race condition with your agent. You find the root cause, document the fix, and move on. Two weeks later you start a new session and the agent suggests the same broken pattern. The context is gone. The decision evaporated. You are back to square one.

This is the central problem Engrim tries to solve. It uses a SQLite file on your machine that remembers what your agents forget. No cloud sync, no new framework required.

The problem: context windows are disposable

Modern coding agents are good at what they do within a single session. Claude Code can refactor a 5,000-line module. Cursor can navigate a monorepo. Antigravity can plan and execute multi-file changes. But the moment you close the tab, clear the context, or switch to a different tool, everything the agent learned about your project disappears.

The cost is not just repetition. It is regression. Without memory of past decisions, agents re-litigate architecture choices, suggest patterns you already rejected, and undo constraints you carefully set. On a long-running project this creates a constant tax: you spend the first 15 minutes of every session re-establishing what the agent should already know.

Context windows have grown to 1M+ tokens, which makes the problem worse, not better. A larger window means more noise, higher cost per turn, and slower reasoning as attention dilutes across irrelevant history. The answer is not bigger context. It is curated, persistent memory that loads the right 4,000 characters at the start of each session.

What Engrim actually is

Engrim is a Python package (pip install engrim) that gives your coding agents a shared, local memory store backed by SQLite. It is not a framework. It does not replace your agent or your editor. It sits alongside them, providing a place to store and retrieve project decisions, constraints, and state.

The core idea is simple: when your agent makes an architectural decision ("we are using PostgreSQL, not MongoDB"), that decision gets written to a local SQLite database. When you start a new session, Engrim loads the most relevant memories into the agent's context automatically. The agent picks up where the last one left off, regardless of which tool you are using.

The database lives at ~/.engrim/memory.db. No cloud account or API key needed. POSIX file permissions (0600) keep it private. The file is gitignored by default so your project memories never accidentally end up in version control.

How retrieval works: hybrid search without the overhead

Engrim does not use a vector database. It does not call an embedding API. Instead it combines two local techniques:

  • SQLite FTS5 with a porter stemmer for keyword search. Fast, deterministic, no external dependencies.
  • model2vec static embeddings for semantic similarity. These are pre-computed vectors that load in about 30 milliseconds on CPU. No GPU required, no API call, no latency.

The two retrieval methods run in parallel and results are merged using reciprocal rank fusion. This gives you keyword precision ("find all decisions about PostgreSQL") and semantic reach ("find memories related to database choices") without the cost or complexity of a dedicated vector store.

If you want zero extra dependencies, you can disable embeddings entirely with ENGRIM_EMBED=off and run pure lexical search. The tool still works, just with slightly less semantic coverage.

The multi-agent angle

This is where Engrim gets interesting. Most memory tools are tied to a single agent or framework. Engrim tracks the provenance of every memory entry, recording which tool created it:

  • antigravity for Google's agent
  • claude-code for Anthropic's CLI
  • cursor for Cursor's MCP integration
  • codex for OpenAI's CLI
  • user for manual entries via the CLI

When you list your memories, you can see where each one came from. A decision made in Claude Code is tagged as such. One made in Cursor carries its own provenance. This matters when you switch tools mid-project and need to know whether a constraint was set by you or suggested by an agent that might have been wrong.

The setup is automatic. Run engrim setup and it detects which tools are installed on your machine, then wires itself into each one. For Claude Code it adds SessionStart and Stop hooks. For Cursor it registers as an MCP server. For Antigravity it configures lifecycle hooks and deploys a skill. One command, all platforms.

The MCP server

Engrim exposes four MCP tools over a stdio JSON-RPC server:

Tool Purpose
engrim_recall Hybrid keyword + semantic search over project memory
engrim_add Write a durable memory record (decision, fact, feedback, state, reference)
engrim_context Retrieve the session-boot memory pack within a character budget (default 4,000)
engrim_review Check for uncaptured decisions from transcript logs before clearing

The server starts with engrim serve --mcp. Stdout is reserved for JSON-RPC messages. Diagnostic logs go to stderr. This follows the MCP specification correctly, which is not always the case with community MCP servers.

The "continue-as-clear" workflow

Engrim's recommended workflow replaces the traditional "keep context open as long as possible" approach:

  1. Capture as you work. When the agent makes a significant decision, it writes to Engrim automatically via the engrim_add MCP tool. You can also save manually with engrim add -t decision -s "...".
  2. Set a resume pointer. Before clearing, save a record tagged resume-pointer describing the immediate next task. The newest pointer is pinned under a "RESUME HERE" heading at the top of the next session's boot pack.
  3. Run engrim review. This scans recent transcript logs for decisions that were not captured. A safety net before wiping context.
  4. Clear freely. The session window is wiped. Engrim automatically re-injects the active memory pack on the next prompt.

The result is that you can clear context aggressively, keep token costs down, and still maintain continuity across sessions. The agent does not re-learn your architecture every morning.

How it compares to alternatives

Several memory solutions exist for AI agents. Here is where Engrim sits:

Feature Engrim Mem0 Zep Letta (MemGPT)
Storage Local SQLite Cloud or self-hosted Cloud (PostgreSQL) Cloud or self-hosted
Network required No Yes (API) Yes (API) Depends
Multi-agent provenance Yes (5 agent types) No No No
MCP server Built-in stdio REST API REST API REST API
Embedding model model2vec (local, static) OpenAI/custom OpenAI/custom OpenAI/custom
Use case Coding project memory General user memory Chat history + memory Autonomous agent memory
Vendor lock-in None Low Medium Low
Pricing Free (MIT) Free tier + paid Paid Free tier + paid

Engrim is not trying to replace these tools. It occupies a different niche: project-scoped episodic memory for developers who switch between multiple coding agents. If you use one agent exclusively and need cloud-synced memory across devices, Mem0 or Zep is a better fit. If you work across Claude Code, Cursor, and Antigravity on the same codebase, Engrim is currently the only tool that handles that without a cloud dependency.

The 105-session case study

Tim Gordon, Engrim's author, tested it across 105 continuous sessions on a 50,000-line algorithmic trading system running real capital. The results:

  • 153,000+ tokens of work consolidated into an active memory pack under 1,000 tokens. That is a 99% reduction in reloaded context cost on every session restart.
  • Zero regressions across 186 unit tests after model switches.
  • Seamless switching between Antigravity, Claude Code, and Cursor with no architectural drift.

These are self-reported numbers from the author's own project, so treat them accordingly. The underlying claim is plausible though: curated memory is cheaper than raw context, and SQLite retrieval is fast enough to not add latency to session startup.

Getting started

# Install
pip install engrim

# Auto-detect and configure all installed agents
engrim setup

# Or target a specific platform
engrim setup --claude
engrim setup --cursor
engrim setup --agy
engrim setup --codex

# Add a memory manually
engrim add -t decision -s "Using PostgreSQL for all new services"

# Recall memories for current project
engrim recall -q "database"

# Load session-boot context
engrim context

# Check for uncaptured decisions before clearing
engrim review

The --dry-run flag on any setup command shows what would change without modifying disk. Useful if you want to inspect before committing.

Limitations and caveats

Engrim is at version 1.3.0 and still in beta. A few things to know before adopting:

  • Single-machine only. If you work across multiple machines, there is no sync mechanism. The SQLite file lives where it lives.
  • No automatic capture by default. The agent must explicitly call engrim_add via MCP, or you must use the CLI. If you forget to capture a decision, it is gone.
  • model2vec embeddings are static. They work well for code-related concepts but may miss nuances in natural language queries. This is a deliberate trade-off for speed and offline operation.
  • The flight recorder logs every turn to disk. On long sessions this can accumulate. There is no built-in log rotation.

Should you use it?

For developers who use a single coding agent and are happy with its built-in memory, Engrim adds unnecessary complexity. The tool earns its keep when you switch between platforms regularly, or when you are tired of re-explaining your project's architecture to a fresh agent every morning. Installation and setup take about five minutes.

The local-first design is the right call for this use case. Project memory is not a cloud problem. It should live next to the code, survive context clears, and not require an API key to function. Engrim does all three.