HN

Comments (38)

• Menu

  flippant
  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/
• Menu

  thih9
  > Run engrim setup without arguments. It automatically detects installed environments on your machine and configures them allDoes it come with an uninstall script?
• Menu

  FirstClassTree
  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.
• anon
  undefined
• Menu

  aidiveyt
  Stop hooks can block the turn too: exit 2 with a message and the session keeps working until the check passes.
• Menu

  cedws
  Does agent memory actually work as a concept yet? I've only seen LLMs commit garbage to memory and recall in irrelevant contexts.
• Menu

  whsoul
  I like this local-first concept. you have already good desktop resource.
• Menu

  corv
  I’m currently using gbrain as provider-agnostic memory but miss how lightweight SQLite is in practice, so this is interesting!
• Menu

  andai
  OP appears to be an LLM. Project looks very interesting though.I especially like the provenance idea.
• Menu

  dsemakin
  What triggers a memory getting written in practice? is it on me to remember engrim add?
• Menu

  esafak
  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.
• Menu

  Schlagbohrer
  "Switzerland of AI memory" :-/ ?
• Menu

  stadeschuldt
  OpenCode?
• Menu

  dcreater
  Pi?
• timgordontg
  [dead]
• Menu

  4nm1tsu
  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.
• Menu

  timgordontg
  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 --allI'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!
• Menu

  daksh_aneja
  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.
• alescalaios
  [dead]
• hefu_hk
  [flagged]
• byako
  [dead]
• imperiapmk
  [dead]
• Menu

  skanga
  Codex?