Thread

1. anthuswilliams · 1790353553 · focus · HN ↗

   One interesting quirk of the AI-written READMEs these days is how they can include every detail on how it works, thoroughly document every optional flag, known limitation, experimental result, and still not communicate the essence of the project and the problem it solves.

   I have read through the project and I still don't understand what this thing is for and why it is to be preferred over the harness's native memory management tools.

   1. avinashjetwani · 1790356682 · focus · HN ↗

      Fair point on the README. Short version of what it’s for:

      Coding agents forget project decisions across sessions. You say “use Postgres, not SQLite” on Tuesday; Thursday a fresh chat invents SQLite again. jevmem watches each turn (Claude Code hooks; Cursor/Codex via agent/MCP), asks Jev a few typed save/skip questions, and appends keepers to JEVMEM.md in the repo. Change your mind later and the old line is marked superseded, not deleted. Next session those lines get injected back into context.

      Vs Claude Code’s native memory: native is Claude deciding what to write into its own auto-memory / MEMORY.md under the local project store. That’s free and local. jevmem is different on purpose: the file lives in the repo (git-friendly, shareable), save/skip is a small typed gate rather than free-form “Claude, remember this,” and superseding is first-class. Tradeoff is real: scrubbed turn text goes to TypeSafe’s Jev API (and optionally an LLM to write the line), and full auto-capture is Claude Code only today.

      Not claiming it’s always better than native. Prefer it when you want a repo-owned decision log that survives sessions without you prompting “remember that.” Prefer native (or nothing) when you want zero third-party traffic.

Unofficial Hacker News client; not affiliated with Y Combinator.