Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs
github.com
github.com
Does it come with an uninstall script?
Everyone should start calling me a plunger because I often hear that i was right to push back.
Congrats on the launch!
I wanted to give a large loud shoutout to @mwpastore and @mannusilva for their very helpful contributions. I appreciate their efforts and also the warm welcome it received from the hn community in general.
It is awesome to see the collaboration happening, getting better all the time.
> Empirical Proof (The 105-Session Case Study)
Is this something you can benchmark against competitors? Lots of these memory plugins are cropping up and nobody knows how they compare.
It seems the meat of your work is in https://github.com/timgordontg/engrim/blob/main/src/engrim/m...
There is no lifecycle management or conflict resolution yet, and the models do the work of deciding when to use it.
I've been using another memory plugin [1] for the past couple months. Since this change, I almost never run session compaction. Instead, I opt to just make a new session, give the agent a task, and have it figure out what happened in previous session(s).
Decision summaries look really cool -- though the agent/model info probably won't be useful for me because I don't actually ever let agents commit code autonomously (even in branches).
- [1] https://ctx.rs/
Just to clarify on the decision summaries - I actually don't let agents commit autonomously either! The summaries exist so that when you spin up that fresh session, the agent doesn't just read the code, it reads the context. It saves you from having to re-litigate past architectural decisions or re-explain your preferences every time you start a new task.
Nice tool you shared, feel free to mess around with engrim and provide feedback. You may end up really liking it. My Claude to Antigravity swaps have been really efficient and honestly, Antigravity has really upped their game lately so moving around for me personally this has been a big boost.
I use them to produce candidates, but not make the decision, there's almost always something wrong in there and in need of an editorial pass. They tend to be overly verbose too, keep em short and sweet
Good call to be thinking about this, it is highly relevant. I think I ended up creating a good solution to this potential pitfall.
I especially like the provenance idea.
you can also work with the opencode sqlite database directly
I use the exported sessions for a number of things, "backups" is another, though it is more about building a complete data set of all my sessions than making sure they are not lost
i wrote a cli tool to query the opencode sqlite database. it's not great, i would want to improve it more before announcing it, but: it works for me and my agents. it was easy to write/understand. https://tangled.org/jauntywunderkind.bsky.social/opencoattai...
i also am working on bookmark features too! a skill and more cli, i'll add a tool too, but often i don't even use tools, just have the cli use the shell. it shows up nicely in it's own atuin, which is rad. but the otel isn't as good.
I prefer json to sql, because I need the json version for various reasons. Sqlite text searching is leaving a lot on the table compared to a Typesense based setup imo
I built engrim to establish a local-first, open standard for cross-model AI agent memory.
As context windows scale past 1M+ tokens, developers face rapid attention dilution: reasoning degrades, and token costs multiply exponentially with every turn. But if you clear your agent's session (/clear) to save money and speed things up, the agent suffers total episodic amnesia, forgetting architectural rules, past debugging steps, and micro-decisions.
Engrim replaces attention dilution with a 4,000-character curated episodic working memory pack. It decouples your project's intelligence from single-vendor proprietary cloud silos. You can switch seamlessly from Gemini in Google Antigravity to Claude 3.7 in Claude Code to GPT-4o in Cursor or Windsurf mid-project—your agents pick up exactly where the others left off.
A few architectural details: - Under the hood, it's a zero-latency hybrid retrieval engine combining SQLite FTS5 (BM25 keyword search) with static vector embeddings (model2vec) using Reciprocal Rank Fusion (RRF). - Memory retrieval is gated per prompt and filtered by a relevance floor, meaning only high-signal records enter your token window. - Provenance Tracking: It maps the origin of every memory entry via an `origin_agent` field (antigravity, claude-code, cursor, cli, user) across multi-agent setups. - 100% Local & Offline: Runs entirely out of a local SQLite database (~/.engrim/memory.db) with POSIX 0600 file permissions and zero cloud telemetry.
Empirical Proof: I production-tested this across 105 continuous sessions on a 50,000-line algorithmic trading system. Over 153,000 tokens of architecture and parameter-tuning logs were consolidated into an active memory pack under 1,000 tokens. That represents a 99%+ cut in reloaded context costs on session restarts with zero architectural regression.
Quickstart: It configures environment lifecycle hooks automatically (e.g., configures hooks.json for Antigravity, settings.json hooks and CLAUDE.md for Claude Code, and registers the stdio MCP server for Cursor and Windsurf):
pip install engrim engrim setup --all
I'm hoping this helps developers escape cloud lock-in and keep their data sovereign while putting an end to massive token bills. I'd love to hear your thoughts on the schema approach, the hybrid RRF engine, or how you handle episodic state across different AI tools!
I generally discourage my agents from storing memories locally because they don't travel; I'd much rather have a small in-repo document—whether it's an architectural decision or TODO or session log entry or runbook or environmental quirk or something else—that the prompt/CLAUDE.md/whatever can guide agents to grep and sed. Then I can dispatch work to a local agent, or a local agent running in a sandbox, or an agent running in a provider's cloud environment, or a GitHub agentic workflow running a headless harness, etc. and they all have access to it. Another benefit is that memory updates get PRs and reviews like everything else.
So what am I missing by not using something like engrim or gbrain?
If multiple agents are reading and writing to the same memory, I'd love to be able to see which agent created a memory, which agents later retrieved it, and how it propagated across sessions. A timeline or knowledge graph of that could be really useful, especially for tracking down stale or conflicting memories.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
How do you handle memory eviction when context windows get large? Are you doing semantic similarity cutoffs or just recency? The 80-line constraint is impressive—did you consider supporting structured recalls (e.g., "all conversations about X topic")? Or is that out of scope for the minimalist angle?
Building this locally vs. cloud-hosted changes the whole game for AI CLI tools. Would use this.
In fact, your comment just inspired me to push a quick update a few minutes ago: if you pull the latest version, running engrim setup will now auto-detect your ~/.codex folder and completely wire up the MCP server and hooks (SessionStart, UserPromptSubmit, etc.) natively. Give it a try!