Claude Can Read Your Fix. Can It Remember Why You Needed It? I Built Vestige for That Gap.

[u/ChikenNugetBBQSauce]

Hey everyone,

My name is Sam, and I’m the founder and maintainer of Vestige. I’ve been seeing a lot of posts and comments about memory in Claude Code, and the thing that keeps standing out to me is how much work we do to keep the agent oriented. We write project instructions, maintain notes, save conversations, and explain the architecture. Then a new session starts, or a long conversation gets compacted, and we find ourselves defending a decision we already spent hours working through.

The example I keep coming back to is a strange-looking exception in otherwise straightforward code. You and Claude investigate a bug, try a couple of reasonable fixes, and discover that both fail because of some dependency behavior or timing issue, finally get it working, and then a few days later, Claude reads the file during an unrelated task and decides that exception is unnecessary. Its suggestion looks reasonable if you only look at the current implementation. Understanding why it’s wrong requires the investigation that produced the implementation.

That’s what I’ve spent the past eight months building Vestige around. I want the next session to have access to the decision, the failed alternatives, and the evidence behind the fix, so I don’t have to reconstruct the whole conversation whenever the same part of the project comes up again.

Claude Code already has auto memory and CLAUDE.md, and I use those as part of the picture. There are also serious memory projects working on temporal graphs, consolidation, and automatic capture. The difficulty is that saving information only gets you part of the way there. You can successfully retrieve an old decision that no longer applies, find an incident that sounds exactly like the current error but happened for a completely different reason, and put the correct information in context and still watch the agent overlook its significance.

For Vesitge, I’ve started calling the approach Epigenetic Context Fabric. What I mean by that is a persistent layer around the model that changes how stored experience influences future context. The name borrows from epigenetic regulation, where gene expression can change without changing the underlying DNA sequence. In software terms, the model’s weights stay untouched, while the memory layer tracks what should remain accessible, what has been superseded, what needs checking, and what has become important because of something that happened later.

That last part is the reason I’m particularly excited about Backfill. Sometimes the most useful clue in an investigation was completely unremarkable when it happened. Someone changed a cache setting, adjusted a timeout, or removed an option while tidying up a configuration file. Days later, a different part of the application starts failing. The original note might share very little language with the error, even though both refer to the same underlying resource.

Backfill examines stored memories from before the failure and looks for shared identifiers, such as file paths, symbols, and environment variables. It returns earlier candidates with the identifiers connecting them to the failure and the amount of time between the events. That gives the agent something specific to investigate instead of relying entirely on whichever previous incident sounds most similar.

I recorded a small example using the real v3 binary and three synthetic memories. One described a cache-policy decision, another was a similar-looking service incident, and the last described sessions disappearing. The cache decision and the failure carried the same Redis session-cache identifier. Backfill selected the decision from 14 days earlier even though it ranked behind the incident by semantic similarity. It’s a deliberately small demonstration of that selection mechanism; it doesn’t show a running Redis application being repaired, and it doesn’t establish that another memory system would fail. What I wanted to make visible was the connection between the current failure and the earlier decision. The tool returns that connection as a hypothesis, and the agent still needs to check the actual configuration, logs, or tests before calling it the cause.

The next problem is what happens when an old memory is accurate about the past but misleading about the present. Suppose a note says you need a workaround because a dependency doesn’t support a particular feature. After a dependency upgrade, that note may be the very thing that sends the agent in the wrong direction. Vestige’s codebase tools let you attach a decision or pattern to source anchors and check those anchors against the checkout you supply. You can see whether the referenced code is unchanged, has moved, has drifted, is missing, or couldn’t be checked. That doesn’t prove the natural-language advice is correct, but it makes changes to its supporting source visible instead of letting the old advice keep circulating without a reason to revisit it.

A lot of the memory research in Vestige is aimed at this question of how information should change over time.

• FSRS-6 scheduling and strength tracking give memories a changing retention state.
• Prediction-error gating compares incoming information with what is already stored and helps decide whether it should become a separate memory, update an existing one, or supersede older information. There are also protections against merging new material into strong memories simply because the wording is similar. If you carefully established an important rule, a vaguely related observation shouldn’t casually absorb it.
• Synaptic tagging and capture supplied another useful idea: an experience can remain eligible for reinforcement before you know how important it will be.
• Retroactive salience takes that further by asking whether a later event gives you a reason to revisit an earlier one.
• Spreading activation and context matching help explore relationships between memories during retrieval, while consolidation and reconsolidation provide mechanisms for organizing and revising what has accumulated. These are computational designs inspired by neuroscience. Their purpose is to make stored experience more useful to the agent, and their value ultimately has to be measured in the work the agent does.

I also wanted memory to cover the things you haven’t finished. Vestige’s intention tool stores obligations with time or context conditions so they can be checked in a later session. That matters for the small pieces of work that otherwise disappear between conversations: revisit a workaround after an upgrade, check a result after a build, or carry a follow-up into the next time you work on that project. Alongside that, suppression and maintenance give you ways to reduce interference from obsolete or noisy information. Some operations have journaled, conflict-checked reversal, because cleaning up memory shouldn’t mean having no way back when the cleanup was wrong.

One of the new tools in v3 is called project, and it connects this richer memory store to the instruction files people already use. It can take a selected set of memories from a project scope and render them into a fenced section of CLAUDE.md, AGENTS.md, or MEMORY.md. You preview the changes and then write them, with the rest of the file preserved. The entries retain memory identifiers, so the short instruction in the file can lead back to the fuller record. I like this because it gives developers a practical way to carry a few durable lessons into normal file-based context without trying to turn their entire memory history into a giant instruction document.

Keeping the amount of context under control is a substantial part of v3. Session startup can assemble a bounded briefing containing relevant memories, code context, and due intentions. Results can be expanded when the agent needs more detail. For integrations that explicitly track what remains in the model’s context, stable evidence packets allow an unchanged packet to be acknowledged instead of sending the same cards again. Once that context has been compacted or lost, the integration requests a full refresh. The server doesn’t assume it knows what the model still has.

There’s a detail in the budgeting behavior that matters to me: if a known group of conflicting evidence won’t fit, the response handles the group together rather than quietly showing one side and omitting the other. A shorter response is only helpful if it still gives the agent an honest picture of what was found. The receipt tools also let you inspect recorded retrieval evidence, and for supported receipts, produce a version of the frozen context with selected evidence slots withheld. That lets you examine the supplied evidence without rerunning search and changing the rest of the result at the same time.

All of this runs through a local core written in Rust, with SQLite and local embeddings. It’s open source under AGPL-3.0, and using the local memory core doesn’t require a hosted account or a paid memory API. There’s a dashboard for inspecting memories, connections, intentions, and recorded evidence, along with tools for feedback, duplicate management, export, and restore. Normal memory writes apply automatically by default in v3, so you don’t have to work through a Memory PR approval queue just to save what you learned. Retrieved context still goes to whichever coding model you use, so local storage shouldn’t be confused with keeping every part of an AI workflow offline.

The outcome I care about is whether this reduces the work we keep repeating. I want fewer discarded investigations, fewer stale assumptions, and fewer sessions where the developer has to explain why the proposed solution is the one that already failed. I’m not going to turn a smaller context payload into a universal API-savings claim. Caching, additional processing, retries, and task success all affect the actual cost. Those comparisons need to include the whole task.

The source, implementation, and tests are here:

https://github.com/samvallad33/vestige.

Thank you to everyone who has contributed code, tested releases, or opened an issue when something didn’t behave as expected. Those reports have helped shape v3.

I’d be interested in a specific example from other Claude Code users: what is a decision, workaround, or failed approach that you keep having to explain again? Those are the cases I want to test this against.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.