timgordontg

A brief update from the creator. Version 1.4.0 live on GitHub and PyPI.

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.

Sure thing. If you find something related to an edge case, let me know specifically and I can try to work it into future improvements.

You are super welcome

Seriously, thank you so much.

just pulled in engrim merge <OTHER.db> - check v1.3.1 (sorry for duplicate reply - had another that was basically same topic) Trying to reply to everyone - thank you.

just pulled in engrim merge <OTHER.db> - check v1.3.1

Updated in v1.3.1

Yea of course, I love building things for fellow homies! Did you get a chance to check it out?

understood, my apologies dang. typing by hand from here on out.

it's just a standard sqlite file in ~/.engrim, so something like litestream or syncthing works fine. just have to make sure wal files get included if syncing live.

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.

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.

[flagged]

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.

Oh, thanks mom! I will make sure to put on my rain coat before going out to play.

Appreciate it! Plumbers are very important people. Thank you for the collaboration.

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!

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.

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.

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.

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!

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!