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

Yeah, I've started dialing back my use of AI for READMEs because of this.

My previous rule was that I never use AI for writing that expresses my own opinions or tries to be convincing (anything on my blog for example) but I'll let it do technical documentation.

The top of a README is about convincing and explaining why I built something though, which means it should fit my no-AI policy after all.

I once told the agent explicitly not to write like it's trying to impersonate Hemingway and it started writing like a normal human being. It's surprising how a writing style that was once revolutionary is now a hallmark of sloppyness.

Maybe give it a try next time you write a readme with agents. That and giving it an example of good README in real world repos can increase dramatically the likelihood of synthesizing a serviceable README.

This is quite easily promptable. Tricks like these do well: https://news.ycombinator.com/item?id=49065956

AI readme should be a starting point. I typically remove at least 50% of the details (without any particular skill use, it goes into extremes like "x clears the edit" and writes a related wall of text in the middle of the important explanation).

My pet theory is that while the pretraining -> RL pipeline achieves very impressive results, it does not reward clarity of thought or elegance. It's not obvious whether it even should for most tasks, but it does grind on me as a human who needs elegance in order to keep everything under control. You give astra/codex many tasks, it retires them all more efficiently than I could by hand. But you look under the hood and every bugfix is another codepath, it just hammers away at things with admirable persistence and vigor until the tests pass. Similarly in discussions and docs, I've noticed many LLMs like to "beat around the bush."

The AI language really stands out, too. "What is automatic and what depends on the agent". A human might write, "jevmen watches your coding session with Claude Code or Codex and picks just the right moment to remember important things that you decided along the way. There are some differences in how jevmem works, depending on which coding harness you are using. The table below summarizes these differences:"

I don't know why the models were generally trained to be so brief, but it's definitely not the way anyone I know actually writes. A second pass is always a good idea to clean this stuff up. And, thankfully, the models are all pretty good at that.

It’s funny to me because pre-AI it’s something I something I saw all the time managing interns and junior software engineers when I’d start trying to tech them about writing design docs. You can explain the process to them and give them a million examples of what good looks like, but for a lot of them the first few docs they write will just be this weird combo of way too much information and very little of it being useful.

My belief has always been that they see the document as more like a test that’s a single task and not just one piece in a larger process and so they treat it like a test where there’s a right answer. They know they don’t really understand the question being asked though so they default to a mindset of, “Well if I just put everything in there some of it has to contain the correct answer” so you end up with this document that’s full of “what”s and “how”s, but completely void of “why”s.

You’ll also often see them fill up space answering easy questions that match the structure of things that are in other documents instead of focusing on the actual hard problems in the design because the hard problems are often unique and their answers may not fit the existing patterns in the examples. There isn’t the instinct to go, “Yeah, none of these example documents talk about the servers were going to deploy it on, but this has to be deployed in an EU cluster because of GDPR laws so I need to add that” because they’re mostly just pattern matching at first.

Usually once they’ve experienced the whole process first hand it starts to click because they start to understand where a design document fits into the larger process so they get a feel for what information matters and what doesn’t.

I think when people just tell an agent to create a README you have the same problem because both the human and the agent see it as just a checkbox type task. The agent sees it as an isolated task snd has no fucking idea how the README is going to be used and the human isn’t giving them that context so they just spit out a bunch of stuff that’s factual and fits the patterns it knows, but is fairly useless.

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.

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.

Is it outdated? Its an avenue already visited, tried and abandoned, so valuable info regarding architectural decisions.

From reading the readme, it looks like superseded decisions are not added to context.

> Next session, the relevant lines are added to Claude's context.

At least that's how I interpret it? If it is adding superseded decisions, that does seem bad.

It's such a Claudism.

Everything is inundated with info about other things tried.

Comments and docs flooded with things found out in the process when you want something about the info you need to know now.

I've recently started trying out a little approach that half makes me cringe as I think of gastown, but sharing FWIW

- All decisions get logged to DECISIONS.md, sequentially

- Before writing a decision, read through past decisions to see if any conflicts

- If no conflicts, encode the decision into the CODE.md

- If any conflicts, ask a Tribunal of 3 agents to find a resolution—each of them should be prompted in slightly different ways

I've only done this for one pretty big project but so far it seems to be working well

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.

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?].

Keeping history and using history are two different things though

You may want the old decision in the audit trail so you know why something changed without putting that old decision back into the model context every time

I think memory systems need a pretty strict separation between active memory and historical memory

TypeSafe AI are the providers for Jev. This complaint is like saying it’s a red flag that Claude Code sends lots of information to somewhere called Anthropic.

Confirmed: Jev is TypeSafe’s product, and that’s the decide/recall step. Each turn we send the scrubbed user message (and sometimes the assistant reply), the previous two turns, and live memory lines to score — no telemetry. Credential-shaped secrets, emails, and card-shaped numbers are redacted first; names/phones/addresses are not. Full table: https://github.com/Avinash-jetwani/jevmem/blob/main/SECURITY...

The people that run local jev like models do sth similar. Train a seperate nn adapter on top of qwen 4b so it has balanced probabilities whatever that means and apparently it works quite well.

Side note: conspiracy theorists say that jev is a qwen model fine tuned but who know if true

I feel that - the contents are the useful part (decisions, open questions, what’s next) and I got tired of them living in a harness-specific memory store I can’t read or edit without jumping through hoops.

One of the first patterns to emerge here is still the best for me personally: one Markdown notes app both the human and whichever agent I’m in write to. Curious what ‘where else’ looks like for you — repo file, Obsidian, or something hosted?

Different shapes, complementary more than competing. jevmem is a thin automatic layer: watch the coding session, keep a flat scored JEVMEM.md (decisions/constraints/bugs/todos) in the repo, inject the relevant live lines next turn. Built around Claude Code hooks; Cursor/Codex share the same file.

From what I can see on deciduous.dev, you’re building a shared decision graph (goals → options → decisions → observations, multi-agent credit, archaeology from commits, Postgres + MCP). That’s richer reasoning-trail / multi-agent collaboration than jevmem aims for.

I’d love a side-by-side if you try it — npm i -g jevmem and https://github.com/Avinash-jetwani/jevmem. Curious where deciduous feels clearly better.

deciduous seems like a great way to ensure there is no space left in context for useful work.

Problem with all these automatic memory managment tools is that they can't reliably classify if something is useful or not. Once it start using some tool it will heavily become biased towards using that tool during that session. First you will have decision to use postgres as a database, by the end of session it will start saving "decided to use SELECT query for this method because that is how you pull data out of database".

Nice. I have not done a fair side-by-side with Deciduous yet, so I will not invent one. jevmem’s bet is automatic capture into a repo file via Jev’s typed questions (save/skip, kind, contradictions), with Claude Code hooks doing it every turn. Would love Deciduous users’ notes after you try it. Install if useful: npm i -g jevmem · https://github.com/Avinash-jetwani/jevmem

Every user turn, the previous two turns, and your whole memory file go to TypeSafe AI, a young vendor.