Jevmem – automatic project memory for Claude Code, built on Jev

Now I have a thorough understanding of the source. Let me write the article:

Avinash Jetwani shipped jevmem, an open-source npm package that gives Claude Code automatic project memory without requiring the user to write or maintain a context file by hand. The tool hooks into Claude Code's Stop and UserPromptSubmit events to observe every coding turn, decide whether the turn contains something worth remembering, write a single line of up to 200 characters into a JEVMEM.md file in the repository, and inject the relevant lines back into Claude's context at the start of the next session. It also works with Codex (while jevmem watch runs) and with Cursor and Claude Desktop through an MCP server, though automatic capture on those tools is more limited. The project is at v0.5, MIT-licensed, and published on npm under the package name jevmem.

This article covers the core decision engine, the v0.5 changes that make saves non-blocking, how the benchmark numbers compare to calling a frontier model directly for every turn, and the exact commands a developer needs to try it today. It is aimed at Claude Code users who work across multiple sessions on the same codebase and find themselves re-explaining architectural constraints to Claude at the start of each session.

What shipped in Jevmem – automatic project memory for Claude Code

Jevmem registers two Claude Code lifecycle hooks — Stop and UserPromptSubmit — through either a Claude Code plugin or jevmem init. On Stop, after each turn completes, jevmem scrubs the turn text for common credential shapes, email addresses, and card-shaped numbers, then sends the scrubbed text to Jev (TypeSafe AI's classification API) with a fixed set of typed questions: is there a decision here, a constraint, a bug, a todo? Jev returns probabilities; thresholds defined in jevmem.config.json decide whether to save or skip. If the turn saves, jevmem writes one line of at most 200 characters into JEVMEM.md at the project root.

On UserPromptSubmit, jevmem reads JEVMEM.md and injects the lines most relevant to the incoming prompt into Claude's context before the model sees it. If you update a decision — switching from SQLite to Postgres, for instance — the old line is tagged [superseded] … → id:new and kept in place rather than deleted. Lines added by teammates or through pull requests are re-checked by Jev before being injected, to catch memory-poisoning attempts. The file is plain text, readable and diffable like any source file, and only projects that contain jevmem.config.json activate the tool; no hooks run globally.

What improved in Jevmem – automatic project memory for Claude Code

The most significant v0.5 change is that saving is now fully asynchronous. In versions before 0.5.0, the Stop hook blocked Claude Code until the Jev call returned. Since v0.5.0 the hook process exits in 12–14 ms (12 ms for the jevmem init hook, 14 ms for the plugin's), and the daemon records the Jev decision 0.26–0.28 s after the hook starts. Claude Code is unblocked immediately; you never wait for the memory write. v0.5 also added a queue: turns that arrive during a Jev outage are written to .jevmem/queue.jsonl and retried with backoff (15 s, doubling to every 10 min, up to 200 queued turns or 24 hours before a turn is dropped).

The benchmark run on 2026-09-23 against 66 held-out turns shows where jevmem sits relative to calling a frontier LLM directly for each save decision:

At $0.000127 per decision and 300 ms median latency, jevmem's auto mode ties GPT-6 Astra on save/skip accuracy while running roughly 10× cheaper than GPT-6 Luna and 10–14× faster than any of the six LLMs.

What you gain from Jevmem – automatic project memory for Claude Code

The practical benefit for a developer working in Claude Code across multiple sessions is that architectural decisions, constraints, and known bugs persist without any manual upkeep. You do not need to copy facts from one session's context into a CLAUDE.md file and then keep that file consistent as the project evolves; jevmem does that capture automatically on every turn, at a per-decision cost that makes it economical to run on every message rather than selectively. The jevmem audit command re-scores all stored memories against the current repo state and flags lines marked [stale?]; jevmem audit --security --ci runs the poisoning check in CI and exits non-zero if any injected line reads as an instruction to an AI, giving teams a way to catch supply-chain-style attacks on the memory file before they merge.

The jevmem import command can bootstrap memory from an existing CLAUDE.md, AGENTS.md, or Cursor rules directory: it splits those files into individual statements, passes each through the same Jev gate as a real turn, and prints what it would add before writing anything. The jevmem search <query> command ranks stored memories by relevance without starting a session, which is useful for auditing what the tool has accumulated over a long-running project. Recall quality — whether injecting the stored lines actually improves Claude's answers — is not measured in the published benchmark; that remains an open question the author acknowledges explicitly in the "honest limits" section.

How to get Jevmem – automatic project memory for Claude Code

A TypeSafe AI key for the Jev API is required before anything else. Once you have a key, the Claude Code plugin path is the recommended route:

npm install -g jevmem
claude plugin marketplace add Avinash-jetwani/jevmem
claude plugin install jevmem@jevmem
cd your-project && jevmem enable

Then configure your API key inside Claude Code — the shell install command does not prompt for it:

/plugin configure jevmem@jevmem

The alternative npm path, which also sets up Cursor and Codex hooks in one step:

npm install -g jevmem
cd your-project
jevmem init --tool claude

Put your TypeSafe key in ~/.jevmem/env as TYPESAFE_API_KEY=... rather than a shell profile, because hooks do not inherit shell variables. Run jevmem doctor to verify the setup. If you want a small model to write the memory line rather than taking it verbatim from the turn, add "writer": "openai" or "writer": "anthropic" to jevmem.config.json and supply the corresponding API key; without that config key, no calls go to OpenAI or Anthropic even if a key is present in the environment.

What to watch after Jevmem – automatic project memory for Claude Code

The version number (v0.5) and the author's own "honest limits" section set the right expectations. Every evaluation set was written by the same person who built the tool, and none of the benchmarks have been run by an independent party. The 66-turn held-out set is small enough that a difference of one or two turns lands within run-to-run noise, which the README acknowledges directly. Long-run drift — what happens to memory quality over weeks of real project use rather than five-turn sessions — is not measured at all. Builders evaluating the tool for team use should pay particular attention to the poisoning gate's known gap: it blocked 20 of 22 planted adversarial lines in the author's test set, but missed 2 that were worded as ordinary process instructions, and the gate does not apply when Claude Code opens JEVMEM.md directly as a file.

The MCP interface is the path to watch for Cursor and Claude Desktop users. Today, automatic capture on those tools still requires the agent to call add_memory explicitly; a .cursor/rules/jevmem.mdc rule prompts Cursor's agent to do this, but nothing is captured if the agent doesn't comply. Whether jevmem adds a hook equivalent for Cursor — or whether Cursor exposes a hook mechanism analogous to Claude Code's Stop event — would substantially change the value proposition for non-Claude-Code workflows. The DynamoDB-backed ledger cutover mentioned in related projects suggests the underlying Jev API may gain persistent storage features; jevmem stats already exposes latency, cost per day, cache hit rate, and escalation rate, giving teams enough signal to judge whether the tool is earning its per-decision cost in practice.