You can’t, unless you store the context somewhere that neither tool owns. That’s exactly the idea behind Engrim: a local SQLite database that stores decisions, constraints, and your project’s current state outside any agent, and re-injects them when you start each session — in Claude Code, Cursor, Windsurf, Antigravity, or Codex CLI, on the same repository.
Anyone using more than one agent knows the problem. You spend forty minutes explaining to Claude Code why the queue is Redis and not SQS, why that module stays untouched until the migration ships, and where you were right when you left off. Then you switch to Cursor for something else and explain it all again. Each tool has its own memory — CLAUDE.md, AGENTS.md, rule files, memory MCP servers — and none of them talk to each other.
Engrim is Tim Gordon’s answer: version 1.3.0, published on PyPI on September 7, 2026, MIT license, Python 3.10 or higher. It hit the Hacker News front page that same week — around 80 points and about 50 comments at the time of writing this note.
What is Engrim and where does it store your context?
Everything lives in a single SQLite file at ~/.engrim/memory.db. No cloud sync, no telemetry, no account. Search is hybrid: full-text with FTS5 plus static vector embeddings via model2vec, which runs on CPU and loads in about 30 milliseconds. If you don’t want embeddings, ENGRIM_EMBED=off leaves it in purely lexical mode.
Records are typed — decision, fact, feedback, state, user, reference — and scoped by project. The file is written with restricted POSIX permissions (0600) and *.db is in .gitignore by default.
The number that matters is the budget. engrim context generates a session startup package limited by character count, 4,000 by default (engrim context -b 4000). That cap is the real design decision: it’s not about “remembering everything”, it’s about deciding what deserves to take up 4,000 characters on startup.
Why don’t CLAUDE.md and AGENTS.md solve the agent-switching problem?
Because they’re single-tool files, and the problem shows up right between tools. AGENTS.md works fine as a shared convention for static instructions: how the project builds, what style is used, what stays untouched. What it doesn’t do is capture the state of a specific session — the decision you made twenty minutes ago, the reason you ruled out an alternative, the exact point where you stopped.
Engrim tackles that second layer. The author himself frames it as a complement, not a replacement: versioned architectural records in git remain the place for lasting documentation. What Engrim stores is what gets lost today when you close the session.
How do you install Engrim in Claude Code, Cursor, Windsurf, Antigravity, and Codex CLI?
Installation is a single command:
pip install engrim
Then let it detect what you have installed:
engrim setup
That auto-detects available environments — Antigravity, Claude Code, Cursor, Codex CLI, Windsurf — and configures each one. If you’d rather go one at a time:
engrim setup --claudeconnects theSessionStart,SessionEnd,Stop, andUserPromptSubmithooks in~/.claude/settings.jsonengrim setup --agyconfigures hooks in~/.gemini/config/hooks.json, deploys a skill to~/.gemini/config/skills/engrim/, and registers the MCP serverengrim setup --cursoradds Engrim to~/.cursor/mcp.jsonengrim setup --codexconnects hooks in~/.codex/hooks.jsonengrim setup --alldoes all of the above
Windsurf is the only manual case. Add this to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"engrim": {
"command": "engrim",
"args": ["serve", "--mcp"]
}
}
}
All setup commands accept --dry-run, which prints what would change without touching your configuration. Use it. These commands edit files that other tools write too.
Through MCP, agents receive four tools: engrim_recall, engrim_add, engrim_context, and engrim_review.
What does a typical day look like?
The author calls it continue-as-clear, and it’s worth understanding because it inverts the usual habit of stretching a long session until it degrades.
You capture decisions as you make them:
engrim add -t decision -s "Queue stays on Redis; SQS migration blocked until Q4"
You leave yourself a pointer to the next task, tagged as such. Then, before clearing, you review what you missed:
engrim review
review inspects transcript logs looking for decisions you made but never recorded. If it comes back clean, you run /clear without ceremony — the memory gets re-injected on the next prompt. Two commands round out the picture: engrim recall -q "database" for hybrid search, and engrim supersede --id 12 --status superseded for when a decision stops being true, which matters more than it sounds. A memory store that only accumulates ends up being wrong.
Does agent memory actually work?
This was the sharpest objection on Hacker News, and it’s the right one: some people have seen LLMs dump garbage into memory and then pull it back in irrelevant contexts.
The author’s answer is that Engrim doesn’t try to be autonomous. Memory is meant to be hand-curated and treated as contextual reference, not as authority for decision-making. He describes the store as a desktop notebook at the session level. If you’re expecting a system that watches you work and infers what matters, this isn’t it, and the design doesn’t pretend otherwise.
Two things the thread raised stay open: what happens when multiple agents write at once, and how the store tells finished work from an abandoned plan when a session dies midway. Neither has documented answers yet.
What do the author’s numbers say, and what don’t they?
Engrim’s README reports 105 continuous sessions on an algorithmic trading codebase of 50,000 lines, with over 153,000 tokens of work consolidated into less than 1,000 tokens — a claimed reduction of more than 99% in context reloaded per restart, and zero regressions across 186 unit tests.
Read it as what it is: the author’s own case study on a single project. It hasn’t been independently reproduced, and one codebase in one domain with one working style isn’t a benchmark. The mechanism is obviously sound — a 4,000-character package costs less than reloading 200,000 tokens, and you don’t need a case study to see that — but that specific percentage belongs to his project, not yours.
It’s worth keeping proportion too: a Hacker News front page measures attention, not adoption. Single maintainer, no releases page. If you build a workflow on this, keep it simple enough to fall back to your CLAUDE.md files without losing much.
One more detail if you read the README carefully: its examples name models that are already old. What you should take is the pattern, not the concrete model strings.
Claude Code vs Cursor? With Engrim you stop having to choose
If you use a single agent, you probably don’t need this yet — CLAUDE.md and the tool’s own memory cover you. If you regularly move between two or three on the same repository, this is the first thing I see aimed directly at the handoff, not at one agent remembering better.
It installs with one command, stores everything in a file you can delete, and --dry-run shows you first what it will touch. It’s a cheap experiment.
If what you’re after is persistent memory within Claude Code and nothing else, we already covered that route once: Claude-mem: give Claude Code the memory it’s missing.
GitHub - timgordontg/engrim: The Universal Cross-Model Episodic Memory Standard. Local-first, project-scoped SQLite memory engine for Google Antigravity, Claude Code, Cursor, Windsurf, and Codex. Zero cloud lock-in. · GitHub Cursor mcp memoria agents-md open-source windsurf