# Jevmem Decides What to Remember in 0.30 Seconds. TypeSafe Sees the Turn. **Summary:** Jevmem makes project memory automatic and auditable, but its default path sends each Claude Code turn through TypeSafe. I would pilot it only where the recall gain justifies that data boundary. - Canonical: https://markhuang.ai/news/jevmem-memory-gate-typesafe-sees-turn - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-25 - Section: News - Tags: Jevmem, Claude Code, Coding Agents, Project Memory, Developer Privacy - Source: [Jevmem on GitHub](https://github.com/Avinash-jetwani/jevmem) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![Conversation fragments pass through a narrow decision gate before one selected card enters a project memory file](https://cdn.markhuang.ai/news/jevmem-memory-gate-typesafe-sees-turn/hero.webp) *Automatic memory looks like a tidy ledger on the far side. The important part is the gate every turn passes through first.* [Jevmem](https://github.com/Avinash-jetwani/jevmem) is a new MIT-licensed tool that records decisions, constraints, bugs, and todos from coding-agent conversations into a shared `JEVMEM.md` file. Its September 25, 2026 changelog lists version 0.4.5, and its author reports a median 0.30-second memory decision on 66 held-out turns. My read is that Jevmem solves a real annoyance with a trade I can inspect. A decision made halfway through a coding session can survive the session, appear in Git review, and follow the project across Claude Code, Codex, and Cursor. On the default Claude Code path, however, every completed turn goes to TypeSafe so Jev can decide whether it belongs in memory. That boundary matters more to me than the speed claim. I would not install Jevmem across a sensitive repository merely because its memory gate is cheap and fast. I would first decide which conversations may leave the machine, then measure whether the resulting memories improve later work. The project has measured admission accuracy. It has not measured recall quality. ## The useful idea is a file you can review Jevmem's best design choice is boring in the good sense. The durable result is a committed Markdown file, not an invisible memory store tied to one assistant or laptop. A saved line has a kind, identifier, timestamp, and confidence. When a later turn reverses a decision, Jevmem marks the old line as superseded instead of deleting it. Git history and code review can show the change. The automation differs by client. Claude Code gets automatic capture through a `Stop` hook and automatic recall through `UserPromptSubmit`. Anthropic's [hook reference](https://code.claude.com/docs/en/hooks) confirms that both events run once per turn, at the end and before the next prompt respectively. Codex capture is automatic only while `jevmem watch` is running; otherwise Codex and Cursor depend on agent-initiated MCP calls and repository instructions. The distinction matters because teams must test each client separately. A memory workflow that is automatic in Claude Code may become a convention that the agent has to remember in Cursor. ## The privacy boundary is wider than one saved line Jevmem's [security document](https://github.com/Avinash-jetwani/jevmem/blob/main/SECURITY.md) is specific about the default data path. On every Claude Code `Stop`, it sends the current user message, the previous two turns in truncated form, and up to 200 keyword-filtered live memory lines to TypeSafe's API. It may include the assistant reply when a broad heuristic sees a question, investigation, or bug report. Recall sends the new prompt and up to 60 live memories so Jev can choose what to inject. The tool scrubs common API-key shapes, private keys, email addresses, 16-digit numbers, and several credential formats before transmission. The same document names gaps: names, phone numbers, postal addresses, national identifiers, and unknown credential formats may remain. That candor helps, but a best-effort scrubber is not a policy boundary. Repository conversations can contain customer details, internal URLs, unreleased plans, or fragments of proprietary code without looking like secrets. Jevmem can set a `zeroDataRetention` flag, but its documentation says the applicable promise depends on the gateway or TypeSafe's terms and is not verified by the tool. If a saved memory uses the optional OpenAI or Anthropic writer, the source text for that memory also goes to that provider. I would review the TypeSafe and writer paths separately. > **Info:** > > My adoption rule: automatic memory should inherit the repository's data classification. If a turn is too sensitive for the configured memory provider, it is too sensitive for automatic capture. ## The benchmark tests the gate, not the benefit The published [benchmark](https://github.com/Avinash-jetwani/jevmem/blob/main/docs/benchmark.md) is useful because it exposes the harness and its limits. Jevmem scored 98.5% on save versus skip and 95.5% on save plus memory kind. Its 300-millisecond median was much faster than the six general models tested, which ranged from 2.8 to 4.3 seconds. At $0.000127 per decision, it was cheaper than five of the six comparison models. Those numbers came from one run on 66 held-out turns written by the author. The repository warns that a difference of one or two turns sits within run-to-run noise. It also says the five-turn harness does not measure drift across weeks and that recall quality is unmeasured. A fast classifier can decide what to store without proving that the stored line helps an agent make a better change next Tuesday. This is the same boundary I saw in [Jev's typed decision model](https://markhuang.ai/news/jev-schema-guarantee-wrong-decision). Probabilities and code-level thresholds make the gate testable. They do not make its judgment correct. In a memory tool, a false positive can preserve a bad rule while a false negative silently loses the decision the tool was meant to protect. ## A missed turn needs an owner Jevmem gives each Jev call a two-second budget. If the service is slow or unavailable, the documented behavior is to skip the turn, write the event to a local log, and move on without retrying later. That is a sensible choice for keeping the coding session responsive, but it creates a quiet failure mode. The developer may assume memory is automatic while the most important decision of the day never reaches `JEVMEM.md`. I would make that gap visible before relying on the system. A pilot should track dropped turns, incorrect saves, missed decisions, superseded lines, and whether retrieved memories changed an answer or patch for the better. The committed file should receive ordinary review, especially when a line changes architecture, security policy, or supported versions. My first test would use a repository where sending conversational context to the configured provider is acceptable. After a few weeks, I would compare the memory file with the team's decisions and inspect the local audit logs. If people keep correcting the file or the agent rarely uses the right line, automation has created another artifact to maintain. ## The install decision Jevmem has a better answer to project memory than another opaque personal database. The memory is plain text, reversals remain visible, thresholds live in configuration, and the security document says what crosses the network. The author even states the two missing proofs: better recall and stability over time. That honesty makes me more willing to test it. Even so, my first deployment would stay narrow. The 0.30-second gate is impressive, but speed answers only whether memory can run on every turn. The harder decision is whether every turn should pass through that gate at all.