It does now! Good call. I actually just pushed an update based on your comment that adds engrim uninstall to cleanly unwire the hooks, MCP servers, and skills across all environments. Thanks for keeping me honest!
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).
Thanks! And I totally agree with your workflow, fresh sessions are the best way to avoid context degradation.
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.
gbrain is an awesome project, but yeah, that was exactly the itch I was trying to scratch! I wanted something that felt as fast, portable, and bulletproof as a single .db file. Zero background daemons or cloud dependencies—just fast, hybrid queries.
Thanks! Exactly. We have M-series chips and massive NVMe drives sitting mostly idle while we pay a 'cloud tax' to store string data. Local SQLite is practically zero-latency, keeps your IP entirely private, and means the memory engine survives even if your internet drops.
Great question, and I just updated the README to clarify this! It's a mix. If you're using connected agents (Antigravity, Claude Code, Cursor) via MCP, they have the engrim_add tool and will automatically log major architectural decisions as they make them. But you also have the manual engrim add CLI command for when you have an 'aha!' moment and want to drop a constraint into the project's brain yourself.
don't let them decide on memories like you shouldn't really be having them write skills or agents.md files
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
i've had long-running coding-agent jobs die. I'd like to see the 105-session benchmark include an unclean exit halfway through a task: what does the next agent know was completed versus merely planned? Recovering architectural decisions and recovering unfinished work seem like different tests.
I hit this in session 101 after a crash: boot hooks sweep the orphaned transcript into a [RECENT] tail, and separating settled decision records from WIP state tells the new agent what was finished vs what died mid-flight.
Good call to be thinking about this, it is highly relevant. I think I ended up creating a good solution to this potential pitfall.
No, I am not an LLM. I do use LLMs to help draft replies as I am a busy person living in the real world. Really glad you like the provenance feature tracking which agent (or human) made which decision ended up being one of the most useful parts of the whole system for me.
Other busy people in real world are then subjected to your generated content. Why bother generating then. Just write down the same thing you prompted llm with
It all boils down to whether the product (code , documentation, whatever) is polished, easy to understand and works as advertised. Beyond that, I don't give a rats ass about whether the intelligence that created it was human or artificial
To all the people who didn’t flag the article but seem intent on flagging all Tim’s responses to questions, please stop. You’re making it quite annoying for those of us that want to see those responses.
you dont need to, export the sessions and render them to markdown, a nice thing is that OpenCode already understands project locality, so use a .sessions for in you repo and get project specific memories (probably want to summarize them down, do other massaging, but a script and skill is sufficient)
I do not follow you. Are you exporting yours sessions manually? How are you performing insertions and queries? How does your agent know the session schema? How does OpenCode 'understand' anything when it is just a dumb app? Are you using some OpenCode memory skill? Do you have a write up of your workflow?
I am not sure we are talking about the same thing. I am talking about a way to automatically create memories, for agentic use. This involves knowing when to create, amend, and delete memories. Are you handling these tasks? This is the core of agentic memory management. Your responses seem to indicate a different use case, like making backups.
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 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 hope you don't mind me asking you some ELI5 questions because I'd like to understand how this fits in with everything else.
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?
Permanent docs definitely belong in git. This is just the desk scratchpad for messy session context so you can /clear freely without cluttering commit history or burning tool calls on grep. Anti Gravity has a large enough context window that seems to be less needed than Claude Code but the real value now with engrim is if you are using multiple services, your project is relevant when switching services. This was born from my long haul Claude Code development sessions and morphed into its current state from swapping around CLI services on the same projects.
Ahh, interesting. I have an issue today where my GitHub agentic workflows keep blowing through the context window that my local models can support; it ends up spending most of its runtime compacting over and over again. I've done all the usual stuff to slim down the fixed context and prevent it from slurping up too many files but it's still a recurring issue. Now I'm wondering if I can put engrim in the gh-aw container (or in the DinD sidecar it uses on ARC) and teach the headless claude harness how to use it, possibly even: "keep persistent context in engrim and use `/clear` instead of `/compact`". I'll play around with it. Thank you!
Have you thought about adding an observability layer on top of the shared memory?
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.
Really nice approach. Local-first + SQLite is the right call for offline-first agent memory without the overhead of a full embedding db. Two quick thoughts:
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.
Yes! Because the Codex CLI supports the Model Context Protocol (MCP) and lifecycle hooks, it actually worksperfectly out of the box.
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!
> Run engrim setup without arguments. It automatically detects installed environments on your machine and configures them all
Does it come with an uninstall script?
It does now! Good call. I actually just pushed an update based on your comment that adds engrim uninstall to cleanly unwire the hooks, MCP servers, and skills across all environments. Thanks for keeping me honest!
Thanks and no problem.
Everyone should start calling me a plunger because I often hear that i was right to push back.
Congrats on the launch!
Appreciate it! Plumbers are very important people. Thank you for the collaboration.
Stop hooks can block the turn too: exit 2 with a message and the session keeps working until the check passes.
Congrats on releasing!
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/
Thanks! And I totally agree with your workflow, fresh sessions are the best way to avoid context degradation.
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’m currently using gbrain as provider-agnostic memory but miss how lightweight SQLite is in practice, so this is interesting!
gbrain is an awesome project, but yeah, that was exactly the itch I was trying to scratch! I wanted something that felt as fast, portable, and bulletproof as a single .db file. Zero background daemons or cloud dependencies—just fast, hybrid queries.
I like this local-first concept. you have already good desktop resource.
Thanks! Exactly. We have M-series chips and massive NVMe drives sitting mostly idle while we pay a 'cloud tax' to store string data. Local SQLite is practically zero-latency, keeps your IP entirely private, and means the memory engine survives even if your internet drops.
What triggers a memory getting written in practice? is it on me to remember engrim add?
Great question, and I just updated the README to clarify this! It's a mix. If you're using connected agents (Antigravity, Claude Code, Cursor) via MCP, they have the engrim_add tool and will automatically log major architectural decisions as they make them. But you also have the manual engrim add CLI command for when you have an 'aha!' moment and want to drop a constraint into the project's brain yourself.
Does agent memory actually work as a concept yet? I've only seen LLMs commit garbage to memory and recall in irrelevant contexts.
You need "dreaming" phase;large context high quality llm to prune and condense the memory.
But does it actually work, or is it something made up because it sounds cool.
It's an improvement, but obviously you're still limited with effective context size, and everything over it is marginal improvement.
don't let them decide on memories like you shouldn't really be having them write skills or agents.md files
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
i've had long-running coding-agent jobs die. I'd like to see the 105-session benchmark include an unclean exit halfway through a task: what does the next agent know was completed versus merely planned? Recovering architectural decisions and recovering unfinished work seem like different tests.
I hit this in session 101 after a crash: boot hooks sweep the orphaned transcript into a [RECENT] tail, and separating settled decision records from WIP state tells the new agent what was finished vs what died mid-flight.
Good call to be thinking about this, it is highly relevant. I think I ended up creating a good solution to this potential pitfall.
Very cool. Does it work with SQLite-sync so you can work across laptop and desktop for example?
OP appears to be an LLM. Project looks very interesting though.
I especially like the provenance idea.
No, I am not an LLM. I do use LLMs to help draft replies as I am a busy person living in the real world. Really glad you like the provenance feature tracking which agent (or human) made which decision ended up being one of the most useful parts of the whole system for me.
Other busy people in real world are then subjected to your generated content. Why bother generating then. Just write down the same thing you prompted llm with
Oh, thanks mom! I will make sure to put on my rain coat before going out to play.
It all boils down to whether the product (code , documentation, whatever) is polished, easy to understand and works as advertised. Beyond that, I don't give a rats ass about whether the intelligence that created it was human or artificial
nice, zero cloud lock-in for agent memory is exactly what i want. how do you handle conflicts when two agents write to the same sqlite store at
To all the people who didn’t flag the article but seem intent on flagging all Tim’s responses to questions, please stop. You’re making it quite annoying for those of us that want to see those responses.
"Switzerland of AI memory" :-/ ?
i'm guessing it's a metaphor for neutrality. except it's a metaphor that isn't really aging well ...
Tim, could you expand on this part?
> 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.
OpenCode?
already has a full sqlite based memory store of everything. :)
But it is not in a format optimised for the task. What kind of a query would you execute, LIKE across all your sessions?
you dont need to, export the sessions and render them to markdown, a nice thing is that OpenCode already understands project locality, so use a .sessions for in you repo and get project specific memories (probably want to summarize them down, do other massaging, but a script and skill is sufficient)
I do not follow you. Are you exporting yours sessions manually? How are you performing insertions and queries? How does your agent know the session schema? How does OpenCode 'understand' anything when it is just a dumb app? Are you using some OpenCode memory skill? Do you have a write up of your workflow?
opencode export -h
you can also work with the opencode sqlite database directly
I am not sure we are talking about the same thing. I am talking about a way to automatically create memories, for agentic use. This involves knowing when to create, amend, and delete memories. Are you handling these tasks? This is the core of agentic memory management. Your responses seem to indicate a different use case, like making backups.
yeah. you don't even need to export.
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.
Pi?
Hi HN,
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 hope you don't mind me asking you some ELI5 questions because I'd like to understand how this fits in with everything else.
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?
Permanent docs definitely belong in git. This is just the desk scratchpad for messy session context so you can /clear freely without cluttering commit history or burning tool calls on grep. Anti Gravity has a large enough context window that seems to be less needed than Claude Code but the real value now with engrim is if you are using multiple services, your project is relevant when switching services. This was born from my long haul Claude Code development sessions and morphed into its current state from swapping around CLI services on the same projects.
Ahh, interesting. I have an issue today where my GitHub agentic workflows keep blowing through the context window that my local models can support; it ends up spending most of its runtime compacting over and over again. I've done all the usual stuff to slim down the fixed context and prevent it from slurping up too many files but it's still a recurring issue. Now I'm wondering if I can put engrim in the gh-aw container (or in the DinD sidecar it uses on ARC) and teach the headless claude harness how to use it, possibly even: "keep persistent context in engrim and use `/clear` instead of `/compact`". I'll play around with it. Thank you!
Have you thought about adding an observability layer on top of the shared memory?
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.
[flagged]
Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.
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.
Really nice approach. Local-first + SQLite is the right call for offline-first agent memory without the overhead of a full embedding db. Two quick thoughts:
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.
Codex?
Yes! Because the Codex CLI supports the Model Context Protocol (MCP) and lifecycle hooks, it actually worksperfectly out of the box.
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!
Thanks for being responsive. I'll try it.