Live data from Hacker News

Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

github.com

41–50 of 70 posts

Re: Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

#41
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/

Re: Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

#42
post #37

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…

[dead]

Re: Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

#43

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 co…

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.

Re: Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

#44
post #34

Earlier quoted context omitted.

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

Re: Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

#47

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…

[flagged]

Re: Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

#48
post #17

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]

Re: Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

#49
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.

Re: Show HN: Engrim – A universal, local-first SQLite memory engine for AI CLIs

#50

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 de…

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…

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.
Post reply on HN