avinashjetwani

That’s the hard problem, and I don’t pretend it’s solved. jevmem’s bet is a save/skip gate (Jev probabilities + fixed thresholds in config), not "log every turn." On a held-out set of 66 messages I wrote, save/skip was 98.5%; that is a single author-built run, and I have not measured long-run drift or whether injected lines actually improve answers. Trivial "used SELECT" lines should fail the content/importance gates; if they don’t in real use, that’s a bug I want labeled with `jevmem wrong` / `missed` so `fit` can retune. Happy to hear where deciduous draws that line too.

jergason read it right. Superseded lines stay in JEVMEM.md for history (and git blame), but recall only injects live lines: kind is not superseded, and there is no supersededBy. On UserPromptSubmit it ranks candidates and injects the top few above a relevance floor. So the file keeps the trail; the prompt gets the current answer. Pruning the file itself further is still open; audit can mark [stale?].

Fair. Short version: Claude Code (and friends) already keep session/auto memory, but it lives in the harness. jevmem’s job is a JEVMEM.md in the repo so decisions travel with the project across sessions and tools. After each turn, Jev scores whether anything is worth keeping (decision, constraint, bug, change of mind). Capture is fully automatic in Claude Code today; Cursor/Codex need the agent/MCP path (or jevmem watch for Codex). If the README buried the "why", that’s on me.

Good question — the file keeps history, recall does not. Superseded lines stay in JEVMEM.md (linked to the new id, so blame/history survive), but injection and decide only use live lines via store.active(). So the model does not get the old and new instruction together.

Separately, jevmem audit can flag live lines that no longer match the repo as [stale?]. Happy to make the "superseded = out of context" rule louder in the README if that was unclear.

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.

jevmem watches Claude Code, Cursor & Codex chats and keeps a JEVMEM.md in your repo up to date. After each message, Jev (TypeSafe) decides whether anything is worth remembering — a decision, a bug, a change of mind — and writes the keepers to that file. Reversed decisions get marked superseded.

Install: npm i -g jevmem (needs a TypeSafe API key)

Held-out check on 66 messages (23 Sep 2026) vs six frontier LLMs: save/skip 98.5% (tied with Astra); save+correct kind 95.5% (Astra 98.5%, Opus 97.0%); changes of mind 5/5; median 0.30s via Jev API (~0.6s end-to-end) vs 2.8–4.3s for the LLMs; cost $0.000127/decision. Single run by me — treat 1–2 message swings as noise.

Limits: early v0.4; fully automatic only in Claude Code today (Cursor/Codex via agent/MCP); messages go to the TypeSafe API with secrets stripped; if the API is down it skips.