4 ms·
Show HN: Total Recall – write-gated memory for Claude Code
built this because I got tired of re-teaching Claude Code the same context every session. Preferences, decisions, “we already tried X,” “don’t touch this file,” etc. After a few days it starts to feel like onboarding the same coworker every morning.
Most “agent memory” tools auto-save everything. That feels good briefly, then memory turns into a junk drawer and retrieval gets noisy. Total Recall takes the opposite approach: a write gate. Before anything gets promoted, it asks one question: “Will this change future behavior?” If not, it doesn’t get saved.
How it works:
Daily log first (raw notes)
Promote durable stuff into registers (decisions, preferences, people, projects)
Small working memory loads every session (kept intentionally lean)
Hooks fail open. SessionStart can surface open loops + recent context. PreCompact writes to disk (not model-visible stdout)
The holy shit moment is simple: tell Claude one important preference or decision once, come back tomorrow, and it behaves correctly without you repeating yourself.
Would love feedback from heavy Claude Code users:
Does the write gate feel right or too strict?
Does this actually reduce repetition over multiple days?
Any workflow/privacy footguns I’m missing?
- deleted 7mo ago[deleted]
- nunobrito 7mo agoFrom a first read, the memory folder should also go into .gitignore by default
- davegoldblatt 7mo agoGood catch. I agree the safe default is to ignore memory/ since it can contain personal notes, people context, and daily logs. I’m updating the installer to add memory/ to .gitignore by default (along with CLAUDE.local.md and .claude/settings.local.json). For teams that do want shared context, I’ll document a “team mode” gitignore pattern that commits only selected registers (e.g. decisions/projects) while keeping daily logs + preferences/people local.
- nunobrito 7mo agoThanks, thinking again it was indeed safer to keep as hidden by default. I've been using it since yesterday, it is doing it work as intended without getting in the way. So far, works great.
- davegoldblatt 7mo agogreat to hear! lmk if you have any feedback
- davegoldblatt 7mo agodone https://github.com/davegoldblatt/total-recall/commit/152ab12 https://github.com/davegoldblatt/total-recall/commit/152ab12
- ChatEngineer 7mo ago[flagged]
- davegoldblatt 7mo agothanks! lmk if you have any feedback
- ChatEngineer 7mo agoUsing something similar in my OpenClaw setup — hierarchical memory with L1/L2/L3 layers plus a "fiscal" agent that audits before writes. The gate is definitely the right abstraction. One thing I've noticed: the "distillation" decision (what deserves L2 vs stays in L1) benefits from a second opinion. I have my fiscal check summaries against a simple rubric: "Does this change future behavior?" If yes, promote. If no, compact and discard. Curious if you've experimented with read-time context injection vs just the write gate? I've found pulling relevant L2 into prompt context at session start helps continuity, but there's a tradeoff on token burn. Great work — this feels like table stakes infrastructure for 2026 agents.
- chrisss395 7mo agoDo you do anything to manage the size of this memory or is that left to the user? I think it would be interesting to make it behave more like real memory and have a way to degrade gracefully, e.g., consolidate old memories to key words only? Random Tuesday thoughts. Neat work!
- Terretta 7mo agoLove the idea and the approach, both. Intend to try it. Dislike READMEs written by or with the LLM. They're filled with tropes and absolutes, as if written by a PdM to pitch his budget rather than for engineers needing to make it work. At some point, reading these becomes like hearing a rhythm in daily life (riding subway, grinding espresso, typing in a cafe) and a rhythm-matched earwig inserts itself in your brain. Now you aren't hearing whatever made that rhythmic sound, but the unrelated earwig. Trying to think about your README or AskHN, instead thinking about LLM slop and confabulation and trust. (Just like new account ChatEngineer's comment opening with “The [hard thing] is real.” which leaves the otherwise natural rest of comment more sus.) Unsolicited opinion: Shouldn't be called total-recall, but curated-recall or selective-recall (prefer this one) or partial-recall or anything that doesn't confuse users or LLM as to (trope incoming, because where did they learn tropes anyway?): what it is (and isn't) …
- davegoldblatt 7mo agoroger that! good point on the readme, was aiming for velocity of shipping. will re work
- rco8786 7mo agoJust +1ing on the readme. It's clearly an LLM dump that repeats a lot of the same points multiple times and is missing a very, very important section: How to use Total Recall. It explains all of the concepts, but lacks a "quick start" section for someone who is ready to get up and running.
- DonHopkins 7mo agoI want an in-depth tutorial, so I can really wrap my head around it, because it blows my mind! How to Learn Total Recall in Two Weeks: https://www.youtube.com/watch?v=-KFH--_cdiI https://www.youtube.com/watch?v=-KFH--_cdiI
- davegoldblatt 7mo ago
- dhruv3006 7mo agoI like the name total recall haha!
- deleted 7mo ago[deleted]
- deleted 7mo ago[deleted]
- sibellavia 7mo agoI built something similar for my needs[1]. I really like your idea of having write-gated memories. [1] https://github.com/sibellavia/dory https://github.com/sibellavia/dory
- davegoldblatt 7mo agoNice, just looked at dory. Cool to see different takes on the same problem. The write gate and the manual curation approach converge on the same insight: the model shouldn't necessarily decide what's permanently important.
- agluszak 7mo agoSuch a feature is very much needed, but I'll wait for the first-party, battle-tested solution
- ejae_dev 7mo agothe daily-log-first approach is a smart design choice — it decouples capture from commitment. curious about one edge case though: what happens when two parallel claude code sessions write to the same daily log simultaneously? with long-running tasks it's common to have multiple sessions open on the same project, and the daily logs are plain markdown files with no locking. also, how consistent is the model at applying the five-point write gate? "does this change future behavior" feels clear in theory, but in practice i'd expect the model to be overly conservative (dropping things that matter) or overly permissive (saving trivia that felt important mid-session) depending on context. have you noticed any patterns in what slips through vs what gets filtered incorrectly?
- davegoldblatt 7mo agoTwo good questions. Concurrent sessions: it's a real edge case but the blast radius is small. Daily logs are append-only by convention, so two sessions writing at the same time would mean interleaved or lost entries at worst. Registers and CLAUDE.local.md are theoretically higher risk since they get modified rather than appended to, but promotion is user-initiated via /recall-promote, so you'd have to be promoting in both sessions at the same time to hit it. The race window exists (edit tool does read-then-write, not atomic append) but I haven't hit it in practice. Cleanest fix if it ever matters: per-session log files (YYYY-MM-DD-session-abc.md) so there's no conflict on capture, and recall-promote just reads all of them. Not worth adding file locking or restructuring for a problem that hasn't bitten anyone yet. Write gate consistency: in my experience the model errs conservative (misses things) rather than permissive (saves junk). For me I actually prefer that direction since saving too much degrades the whole system over time, while missing something important is easy to fix. You just say "remember this" and it bypasses the gate. That explicit override (item 5 on the gate) has been more reliable than trying to tune the automatic criteria to be more permissive.
- 4b11b4 7mo agoI'm a fan human pruning (which you refer to as "write gates"). At this point, I'd argue any "automated memory" is a failure over time. I don't know if I'll be convinced otherwise. If one were to go full automation, then I'd want generations of what to prune ("I haven't used this memory in a while... "). Actually, that might be useful in your tool as well. "Remove-gates"?
- davegoldblatt 7mo agoAgree on human pruning piece for the most part. The system is built on the assumption that the model shouldn't necessarily be trusted to decide what's permanently important. Remove-gates are a good extension of the same philosophy. Right now /recall-maintain lets you manually review and clean up, but it doesn't proactively surface "hey, you haven't referenced this in two weeks, still relevant?" That would be the natural counterpart to the write gate: system surfaces candidates, human decides. Am going to think on this, but will likely add. Appreciate you!
- davegoldblatt 7mo agoOpened a design issue for this if anyone wants to follow along or weigh in: https://github.com/davegoldblatt/total-recall/issues/2 https://github.com/davegoldblatt/total-recall/issues/2
- 4b11b4 7mo agoNice work!
- andershaig 7mo agoI'm going a bit broader with my system but it's similar. Instead of trying to predict future behavior, I'm focusing on capturing new, meaningful information, preparing it for human review (no fully automatic writes) and pairing with an ongoing review process, deduplication and treating it like a resource I manually curate (with help to make that easier of course). I think context needs to be treated primarily globally with the addition of some project specific data. For example, my coding preferences don't change between projects, nor does my name. Other data like the company I work for can change, but infrequently and some values change frequently and are expected to. I also use Claude Code a lot more for thinking or writing these days so there's less separation between topics than there are in separate repos.
- davegoldblatt 7mo agoThe global vs. project-specific split is the right question and has real tradeoffs. You're right that preferences, identity, and coding style don't change between repos. Right now Total Recall is project-scoped, so if you're using it across multiple projects you'd be maintaining separate memory for each, which of course is redundant for that kind of context. The tension is that some things genuinely are project-specific (decisions, architecture, people involved) and mixing those into a global tier makes retrieval noisier and may degrade performance to the point where its useless. I think the answer is probably both: a global layer for durable personal context and project-scoped registers for everything else. Haven't built that yet but it's the obvious next step. Am going to add this to my next sprint. Also, your point about using Claude Code for thinking and writing beyond just coding resonates too. The more you use it outside of repo-scoped work, the more project-level memory feels like the wrong boundary. Will report back when ive come up with a potential solution.
- iamleppert 7mo agoI just want an infinite scroll in Claude Code, where I can easily search and view all my past conversations. Is that asking too much?
- fidorka 7mo agoNice work - the daily-log-first approach resonates. We hit the same "re-onboarding Claude every morning" problem and went a different direction with MemoryLane (https://github.com/deusXmachina-dev/memorylane https://github.com/deusXmachina-dev/memorylane): it sits in the background capturing your activity (screenshots + OCR + summaries) and makes that context available to any AI chat via MCP. Different tradeoff - Total Recall is curated (daily logs) and lean, MemoryLane for now captures broadly and relies on search to surface what's relevant. I think they are complementary: your write gate keeps project knowledge tight, broad context with search fills in the "wait, what tab/webpage was that" gaps. We applied to this batch (YC S26), still waiting on Apple notarization before a wider release. Happy to chat if anyone's curious about the screen-context approach.
- davegoldblatt 7mo agoThx! Also, interesting approach on your end. The screen-context angle solves a different problem than what I was going after, but I agree they're complementary. Curated project memory and broad ambient capture serve different retrieval patterns. Good luck with YC!