> 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!
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.
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.
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
Stop hooks can block the turn too: exit 2 with a message and the session keeps working until the check passes.
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.
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.
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.
"Switzerland of AI memory" :-/ ?
i'm guessing it's a metaphor for neutrality. except it's a metaphor that isn't really aging well ...
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?
Pi?
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.
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?
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!