8 ms·

Show HN: Stop Claude Code from forgetting everything

202 points by austinbaggio 9mo ago

I got tired of Claude Code forgetting all my context every time I open a new session: set-up decisions, how I like my margins, decision history. etc. We built a shared memory layer you can drop in as a Claude Code Skill. It’s basically a tiny memory DB with recall that remembers your sessions. Not magic. Not AGI. Just state. Install in Claude Code: /plugin marketplace add https://github.com/mutable-state-inc/ensue-skill /plugin install ensue-memory # restart Claude Code What it does: (1) persists context between sessions (2) semantic & temportal search (not just string grep). Basically git for your Claude brain What it doesn’t do: - it won’t read your mind - it’s alpha; it might break if you throw a couch at it Repo: https://github.com/mutable-state-inc/ensue-skill https://github.com/mutable-state-inc/ensue-skill If you try it and it sucks, tell me why so I can fix it. Don't be kind, tia

deleted 9mo ago
[deleted]
zyan1de 9mo ago
I mostly use it during long Claude Code research sessions so I don’t lose my place between days. I run it in automatic mode with decent namespacing, so thoughts, notes, and whole conversations just accumulate in a structured way. As I work, it stores the session and builds small semantic, entity-based hypergraphs of what I was thinking about. Later I’ll come back and ask things like: what was I actually trying to fix here? what research threads exist already? where did my reasoning drift? Sometimes I’ll even ask Claude to reflect on its own reasoning in a past session and point out where it was being reactive or missed connections.
altmanaltman 9mo ago
Thank you for specifying it wasn't magic or AGI.
- austinbaggio 9mo ago
  [flagged]
- apublicfrog 9mo ago
  > Not magic. Not AGI. Just state. Very clearly AI written
  - fragmede 9mo ago
    You're absolutely right!
CPLX 9mo ago
I absolutely love this concept! It's like the thing that I've been looking for my whole life. Well, at least since I've been using Claude Code, which is this year. I'm sold. With that said, I can't think of a way that this would work. How does this work? I took a very quick glance, and it's not obvious at first glance. The whole problem is, the AI is short on context, it has limited memory. Of course, you can store lots of memory elsewhere, but how do you solve the problem of having the AI not know what's in the memory as it goes from step to step? How does it sort of find the relevant memory at the time that that relevance is most active? Could you just walk through the sort of conceptual mechanism of action of this thing?
- zyan1de 9mo ago
  yeah so you can run it in automatic mode, or read only mode. In automatic mode it hooks onto the conversation and tool calls so you get the entire conversation stored. If you dont want to get super deep, then read only is safe and only stores what you ask. You could ask it things like "why is my reasoning dumb" by recalling passed conversations, or even give it the claude tool call sequence and ask "how can claude be smarter about next time". I think of it like a file tree with proper namespacing and keep abstract concepts in separate directories. so like my food preferences will be in like /preferences/sandos. or you can even do things like /system-design preferences and then load them into a relevant conversation for next time.
- skuenzli 9mo ago
  It looks to me like the skill sets up a connection to their MCP server at api.ensue-network.ai during Claude session start via https://github.com/mutable-state-inc/ensue-skill/blob/main/scripts/session-start.sh https://github.com/mutable-state-inc/ensue-skill/blob/main/s... Then Claude uses the MCP tools according to the SKILL definition: https://github.com/mutable-state-inc/ensue-skill/blob/main/skills/ensue-memory/SKILL.md https://github.com/mutable-state-inc/ensue-skill/blob/main/s...
- austinbaggio 9mo ago
  Appreciate it - yeah, you're right, models don't work well when you just give it a giant dump of memory. We store memories in a small DB - think key/value pair with embeddings Every time you ask Claude something, the skill: 1. Embeds the current request. 2. Runs a semantic + timestamp-weighted search over your past sessions. Returns only the top N items that look relevant to this request. 3. Those get injected into the prompt as context (like extra system/user messages), so Claude sees just enough to stay oriented without blowing context limits. Think of it like: Attention over your historical work, more so than brute force recall. Context on demand basically giving you an infinite context window. Bookmark + semantic grep + temporal rank. It doesn’t “know everything all the time.” It just knows how to ask its own past: “What from memory might matter for this?” When you try it, I’d love to hear where the mechanism breaks for you.
senshan 9mo ago
What is the advantage over summarizing previous sessions for the new one? Or, over continuing the same session and compacting?
- austinbaggio 9mo ago
  You can use it with summaries for sure, but summaries often miss edge cases and long sessions drift. This makes it easier to jump between tasks, come back days later, and reorient without missing something that the summarization or compaction might have gotten rid of. I've often found post-compaction, the memory of even the current session feels so much dumber.
  - ec109685 9mo ago
    You can go to a previous session and resume from there. Plus keep updating the repo claude.md along the way:
zyan1de 9mo ago
maybe you are in a claude code session and think "didn't i already make design doc for system like this one?" Or you could even look at your thought process in a previous session and reflect. but rn i mainly use it for reviewing research and the hypergraph retrieval
coffeeboy27 9mo ago
What's the data retention/deletion policy and is there a self-hosted option planned? I'd prefer not to send proprietary code to third-party servers.
- austinbaggio 9mo ago
  Honestly, very reasonable ask, you're not the first person to ask for a self-hosted version. We have a privacy policy we've drafted that is up-to-date with the current version of the product https://www.ensue-network.ai/privacy-policy https://www.ensue-network.ai/privacy-policy. The project is still in alpha, so you could shape what we build next - what do you need to see, or what gets you comfortable sending proprietary code to other external services?
  - frumplestlatz 9mo ago
    > what do you need to see, or what gets you comfortable sending proprietary code to other external services? Honestly? It just has to be local. At work, we have contracts with OpenAI, Anthropic, and Google with isolated/private hosting requirements, coupled with internal, custom, private API endpoints that enforce our enterprise constraints. Those endpoints perform extensive logging of everything, and reject calls that contain even small portions of code if it's identified as belonging to a secret/critical project. There's just no way we're going to negotiate, pay for, and build something like that for every possible small AI tooling vendor. And at home, I feed AI a ton of personal/private information, even when just writing software for my own use. I also give the AI relatively wide latitude to vibe-code and execute things. The level of trust I need in external services that insert themselves in that loop is very high. I'm just not going to insert a hard dependency on an external service like this -- and that's putting aside the whole "could disappear / raise prices / enshittify at any time" aspect of relying on a cloud provider.
    - austinbaggio 9mo ago
      Yeah I get the dependency concern, and also I think about the trust and pricing challenge a lot. I might be getting ahead of my skis here, but living in a future world, assuming there is a local service, what would you want to see with a context management service for your team to actually use it? Or even better - pay for it?
sabareesh 9mo ago
Non starter for us, we cant ship propriety data to a third party servers.
- austinbaggio 9mo ago
  I assume this is with work? And also assume you do send data, you just need some service agreement or something like with AWS or Microsoft for GH?
  - bg_tagas 9mo ago
    [dead]
qudat 9mo ago
Have you tried https://github.com/steveyegge/beads https://github.com/steveyegge/beads
- PrayagS 9mo ago
  +1 to beads. Works great
- zyan1de 9mo ago
  oh yeah beads is awesome! I'd say this is a bit more general purpose rn especially what is in the skill!
- jswny 9mo ago
  Can you give an example of how beads would be used by Claude to do something it otherwise couldn’t? I can’t quite tell what it is useful for
  - frankc 9mo ago
    Personally, I have been using beads for a few days on a couple of projects. I also like https://github.com/Dicklesworthstone/beads_viewer https://github.com/Dicklesworthstone/beads_viewer which is a nice tui for beads (with some additional workflow i haven't tried). I have found its been useful for longer, multi-session implementations. Its easier to get back into the work. I wouldn't go so far as to it couldn't do the work without it, but so far it seems smoother. These things are hard to measure. I think the it's really not that different than how an engineering team would use jira but more hierarchical, which helps preserve context, and with prebuilt instructions for how the agent should use it.
- rahimnathwani 9mo ago
  Beads is awesome. I've been using it with a greenfield React Native hobby project. I did some work up front on the spec (with help from AI), and started the repo from a boilerplate, but after that every single bead (epic, ticket) and every single line of code has been written by AI (using a mix of claude, codex, cursor-agent/composer-1). The app works. When I feel like working on it, I just open a CLI coding agent and say 'start working'. Then every so often I say 'commit and push' or 'find opportunities to improve the code base by refactoring, and create an issue for each opportunity'. (I followed the instructions to add the boilerplate instructions for both bd and bv, to AGENTS.md)
deleted 9mo ago
[deleted]
JoshGlazebrook 9mo ago
Is anyone else just completely overwhelmed with the number of things you _need_ for claude code? Agents, sub agents, skills, claud.md, agents.md, rules, hooks, etc. We use Cursor where I work and I find it a good medium for still being in control and knowing what is happening with all of the changes being reviewed in an IDE. Claude feels more like a black box, and one with so many options that it's just overwhelming, yet I continue to try and figure out the best way to use it for my personal projects. Claude code suffers from initial decision fatigue in my opinion.
- minimaxir 9mo ago
  With Opus 4.5 in Claude Code, I'm doing fine with just a (very detailed) CLAUDE.md.
  - austinbaggio 9mo ago
    Do you find you want to share the .md with the teams you work with? Or is it more for your solo coding?
    - Myrmornis 9mo ago
      Not saying you were suggesting it but people committing AGENTS.md in shared repos is pretty annoying IMO. Those things are personal.
- asdev 9mo ago
  you really don't need any of this crap. you just need Claude Code and CLAUDE.MD in directories where you need to direct it. complicated AI set ups are mid curve
  - wouldbecouldbe 9mo ago
    It seems to mostly ignore Claude.md
    - 9mo ago
dr_dshiv 9mo ago
I just ask Claude to look at past conversations where I was working on x… it sometimes thinks it can’t see them, but it can. I’ll give this a go though and let you know!
- ramoz 9mo ago
  Here is a simple skill (markdown instruction only) that instructs a nice ripgrep approach - with utility of discovering current session. https://github.com/backnotprop/rg_history https://github.com/backnotprop/rg_history
AndyNemmity 9mo ago
I don't understand the use case. I think if you don't use agents, and skills currently effectively, then perhaps this is useful. If you're using them though, we no longer have the problem of Claude forgetting things.
- lkbm 9mo ago
  I'm curious how those replace this? I've barely used either, and would love to hear more.
  - AndyNemmity 9mo ago
    Okay, Claude.md is an md file with instructions. Agents are an md file with instructions. Skills are an md file with instructions. Commands are.. you get the point. We're just dealing with instructions. Claude.md is handled by Claude Code. It is forgotten almost entirely often when the context fills. Okay, what is an agent? An agent is basically a Claude.md file, but you make it extremely granular. So it only has instructions of let's say, Typescript. We're all just doing context management here. We're trying to make sure our instructions that matter stay. To do that, we have to remove all other instructions from the picture. When you're doing typescript, you only know type script things. Okay, what's a skill? A skill is doing a single thing with type script. Why? So that the context is even smaller. Instead of the agent having every single instruction you need about typescript, you put them in skills so they only get put into context when that thing is needed. But skills are also where you connect deterministic programs. For example, I have a skill for creating images in nano banana. So when the Typescript Agent needs to create an image, it calls the skill, that calls the python script, to create images in nano banana. We're managing all the context to only be available when it's needed, keeping all other instructions out. Does that help?
    - lkbm 9mo ago
      A little. Thanks for the detailed reply. But I wouldn't expect a smaller, more targeted Claude.md would make a big difference. My impression is that we're filling up the context less with Claude.md than with the session work: back and forth about the specific task, Claude's chain-of-thought as it does that, the relevant sections of code, etc. That's what this is trying to compact and reference, iiuc. What I'd think would help, would be doing things in smaller chunks: an agent to do this small subtask, another to do that small subtask, and the parent task context only grows with the sub-agents reporting back, not with their chain-of-thought. Could be I should have a much bigger, more detailed Claude.md. Mine tend to be small project overviews and a list of TODOs, not that different from README.md: https://github.com/lkbm/sideways_math/blob/main/CLAUDE.md https://github.com/lkbm/sideways_math/blob/main/CLAUDE.md
bilbo-b-baggins 9mo ago
Your site advertises careers in San Francisco/Remote. California law requires compensation disclosures.
- austinbaggio 9mo ago
  Good flag, we're still pretty early, I think the strict requirement for compensation disclosures is post 15 employees in CA? Did I get this wrong?
ramoz 9mo ago
I struggle with these abstractions over context windows, esp when anthropic is actively focused on improving things like compaction, and knowing the eventual* goal is for the models to yave real memory layers baked in. Until then we have to optimize with how agents work best and ephemeral context is a part of that (they weren’t RL’d/trained with memory abstractions so we shouldn’t use them at inference either). Constant rediscovery that is task specific has worked well for me, doesn’t suffer from context decay, though it does eat more tokens. Otherwise the ability to search back through history is a valuable simple git log/diff or (rip)grep/jq combo over the session directory. Simple example of mine: https://github.com/backnotprop/rg_history https://github.com/backnotprop/rg_history
- AndyNemmity 9mo ago
  There is certainly a level where at any time you could be building some abstraction that is no longer required in a month, or 3. I feel that way too. I have a lot of these things. But the reality is, it doesn't really happen that often in my actual experience. Everyone is very slow as a whole to understand what these things mean, so far you get quite a bit of time just with an improved, customized system of your own.
  - ramoz 9mo ago
    My somewhat naive heuristic would be that memory abstractions are a complete mistep in terms of optimization. There is no "super claude mem" or "continual claude" until there actually is. https://backnotprop.com/blog/50-first-dates-with-mr-meeseeks/ https://backnotprop.com/blog/50-first-dates-with-mr-meeseeks...
    - AndyNemmity 9mo ago
      I tend to agree with you, however compacting has gotten much worse. So... it's tough. I think memory abstractions are generally a mistake, and generally not needed, however I also think that compacting has gotten so wrong recently that they are also required until Claude Code releases a version with improved compacting. But I don't do memory abstraction like this at all. I use skills to manage plans, and the plans are the memory abstraction. But that is more than memory. That is also about having a detailed set of things that must occur.
robertwt7 9mo ago
Congrats for this! how does this differs from claude-mem? I've been using claude-mem for a while now https://github.com/thedotmack/claude-mem https://github.com/thedotmack/claude-mem
- bgilly 9mo ago
  Thanks for mentioning this. I installed claude-mem today and it’s already come in handy. Pretty neat how it can go get individual prompts and replies from previous sessions without consuming a lot of tokens. And I finally have some visibility into what my subagents are doing thanks for the real time feed web dashboard.
amannm 9mo ago
There's a lot of people interested in forming some sort of memory layer around vendored LLM services. I don't think they realize how much impact a single error that disappears from your immediate attention can have on downstream performance. Now think of the accrual of those errors over time and your lack of ability to discern if it was service degradation or a bad prompt or a bad AGENTS.md OR now this "long term memory" or whatever. If this sort of feature will ever be viable, the service providers will offer the best solution only behind their API, optimized for their models and their infrastructure.
ossa-ma 9mo ago
There are a quadrillion startups (mem0, langmem, zep, supermemory), open source repos (claude-mem, beads), and tools that do this. My approach is literally just a top-level, local, git version controlled memory system with 3 commands: - /handoff - End of session, capture into an inbox.md - /sync - Route inbox.md to custom organised markdown files - /engineering (or /projects, /tasks, /research) - Load context into next session I didn't want a database or an MCP server or embeddings or auto-indexing when I can build something frictionless that works with git and markdown. Repo: https://github.com/ossa-ma/double https://github.com/ossa-ma/double (just published it publicly but its about the idea imo) Writeup: https://ossa-ma.github.io/blog/double https://ossa-ma.github.io/blog/double
- AndyNemmity 9mo ago
  Your approach essentially matches mine, but I call them plans. I agree with you that the other tools don't seem to add any value compared to this structure. I think at this point in time, we both have it right.
- bl4ckneon 9mo ago
  The extention Cline has a "memory bank" feature. It's just a markdown you add as an instruction. Works well for me. Worked with agents.md as well so not just with the Cline extention. Pretty much the same idea.
- fastball 9mo ago
  What is the purpose of a separate /handoff and /sync command? It seems like handoff could just write learnings straight to their final destinations without needing an .inbox.md buffer in-between.
  - ossa-ma 9mo ago
    I like to read and review what was captured in .inbox.md before it is committed and synced across my knowledge base. Allows me to catch mistakes, tweak preferences, add context and decide whether something is actually worth pushing. I will typically make multiple '/handoff's per day as I use Claude code whereas I typically use '/sync' at the end of the day to organise them all at once.
EMM_386 9mo ago
Just put a claude.md file in your directory. If you want more details about a subdirectory put one in there too. Claude itself can just update the claude.md file with whatever you might have forgot to put in there. You can stick it in git and it lives with the project.
graphememes 9mo ago
stop wasting context space with this stuff ミ · · 彡
lloydatkinson 9mo ago
> Not magic. Not AGI. Just state. Why did you need to use AI to write this post?
- llmslave2 9mo ago
  Their brains are mush, lost the ability to focus on a task or do any deep thinking. Just proooooooooompt.
  - lloydatkinson 9mo ago
    insert prooomptorrrrr soyjack meme
ec109685 9mo ago
This is impressive. Though I have found repo level claude.md that is updated everytime claude makes a mistake plus using —restore to select a previous relevant session works well. There is no way for Anthropic to optimize Claude code or the underlying models for these custom setups. So it’s probably better to stick with the patterns Anthropic engineers use internally.
- austinbaggio 9mo ago
  Do you ever switch tools? I don't love the idea of my context being hostage of whatever LLM I choose first.
- austinbaggio 9mo ago
  If you give it a try, I think that use case should work, but if not, I would be grateful if you told us what broke. And also - I genuinely worry about vendor lock-in, do you?
  - deleted 9mo ago
    [deleted]
fullstick 9mo ago
I like it when the conversation is new sometimes.
alex_young 9mo ago
Doesn't Claude already use RAG on the backend?
gbnwl 9mo ago
I'm not sure how many HN users frequent other places related to agentic coding like the subreddits of particular providers, but this has got to be the 1000th "ultimate memory system"/break-free-of-the-context-limit-tyranny! project I've seen, and like all other similar projects there's never any evidence or even attempt at measuring any metric of performance improved by it. Of course it's hard to measure such a thing, but that's part of exactly why it's hard to build something like this. Here's user #1001 that's been told by Claude "What a fascinating idea! You've identified a real gap in the market for a simple database based memory system to extend agent memory."
- austinbaggio 9mo ago
  Which of the 1000 is your favorite? There does seem to be a shallow race to optimizing xyz benchmark for some narrow sliver of the context problem, but you're right, context problem space is big, so I don't think we'll hurry to join that narrow race.
  - gbnwl 9mo ago
    | Which of the 1000 is your favorite? None, that's what I'm trying to say. My favorite is just storing project context locally in docs that agents can discover on their own or I can point to if needed. This doesn't require me to upload sensitive code or information to anonymous people's side projects and has and equivalent amount of hard evidence for efficacy (zero), but at least has my own anecdotal evidence of helping and doesn't invite additonal security risk. People go way overboard with MCPs and armies of subagents built on wishes and unproven memory systems because no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. Doesn't mean it's time to send our data to strangers.
    - gck1 9mo ago
      > no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. FWIW, I find this eventual degradation point comes much later and with fewer consequences when there are strict guardrails inside and outside of the LLM itself. From what I've seen, most people try to fix only the "inside" part - by tweaking the prompts, installing 500 MCPs (that ironically pollute the context and make problem worse), yell in uppercase in hopes that it will remember etc, and ignore that automated compliance checks existed way before LLMs. Throw the strictest and most masochistic linting rules at it in a language that is masochistic itself (e.g. rust), add tons of integration tests that encode intent, add a stop hook in CC that runs all these checks and you've got a system that is simply not allowed to silently drift and can put itself back on track with feedback it gets from it. Basically, rather than trying to hypnotize an agent to remember everything by writing a 5000 line agents.md, just let the code itself scream at it and feed the context.
linsomniac 9mo ago
The past few weeks I've been experimenting with using less context and less memory and it's been going really well. Where before I'd try to do a bunch of fairly related things in a single session, experimenting with compacting more or less frequently, now I'm clearing my context or exiting and restarting claude and codex. It seems to help it focus on the task at hand, hasn't tended to go off into the weeds as much, and my token costs have dropped way down. Combined with a good AGENTS.md, it seems to be working really well.
- einsteinx2 9mo ago
  That’s been my experience as well. I find I usually get better output if I create a new conversation for each thing I need. I’ve found that the only times it’s better to continue an existing conversation is if I want to have it make small improvements or changes to something it just wrote, as it tends to do better with the previous context still there. But even that only goes so far, then the scale tips and it works much better with a clean slate. I especially don’t want totally unrelated conversations polluting the context which is why I have all memory features turned off in all the web chat UI’s for the models I use.
deleted 9mo ago
[deleted]
incoming1211 9mo ago
[dead]
jMyles 9mo ago
We built one too, with a web frontend and a 'spy' viewer in case your team wants to watch your interactions. Also has secret redaction: https://github.com/jMyles/memory-lane https://github.com/jMyles/memory-lane
scubbo 9mo ago
I've been tinkering with building something similar for myself - though for a generic chatbot, rather than for Claude (not every task is coding, and I'd like to keep !). From other comments (e.g. https://news.ycombinator.com/item?id=46428368 https://news.ycombinator.com/item?id=46428368, https://news.ycombinator.com/item?id=46427950 https://news.ycombinator.com/item?id=46427950) suggest that many others are already ahead of me. Any recs for tools, libraries, or approaches that I should learn from or adopt? In particular, I've found that - no matter how direct and clear the system prompt is - models have a tendency to respond verbally as if they've made a tool-call recording some gained-knowledge ("thanks! I'll remember that"), but to not actually return the JSON required to trigger the call by the tool.
- austinbaggio 9mo ago
  Since you've already thought about this problem, I'd love to hear your feedback after giving this skill a try. It should speed up at least your basic need of having to trigger the LLM to store the memory. One of our colleagues has found success asking at the end of a research session what he missed, how he could improve, etc.
devhouse 9mo ago
Feels like this is solving a problem that /compact should solve but doesn't. The fact that post-compaction Claude 'feels dumber' suggests the summarization is too aggressive? Would be interesting if Anthropic exposed more control over what gets preserved vs. compressed ... or let users provide their own summary template.
heliumtera 9mo ago
Stop Claude from forgetting by telling it to not forget
- AndyNemmity 9mo ago
  and put it in all caps, so it knows you mean business.
  - wellthisisgreat 9mo ago
    alarm emoji alarm emoji alarm emoji
austinbaggio 9mo ago
Thanks everyone for the comments, really, I wasn't expecting this. Quite a few of you have mentioned that you store a lot of your working context across sessions in some md file - what are you actually storing? What data do you actually go back to and refer to as you're building?
- EMM_386 9mo ago
  > in some md file 1a directly from Anthropic on agentic coding and Claude Code best practices. "Create CLAUDE.md files" https://www.anthropic.com/engineering/claude-code-best-practices https://www.anthropic.com/engineering/claude-code-best-pract... It works great. You can put anything you want in there. Coding style, architecture guidelines, project explanation. Anything the agent needs to know to work properly with your code base. Similar to an onboarding document. Tools (Claude Code CLI, extensions) will pick them up hierarchically too if you want to get more specific about one subdirectory in your project. AGENTS.md is similar for other AI agents (OpenAI Codex is one). It doesn't even have to be those - you can just @ the filename at the start of the chat and that information goes in the context. The naming scheme just allows for it to be automatic.
gaigalas 9mo ago
I like the fact that it forgets. Each time an LLM looks at my project, it's like a newcomer has arrived. If it keeps repeating mistakes, it's because my project sucks. It's an unique opportunity. You can have lots of repeated feedback from "infinite newcomers" to a project, each of their failures an opportunity to make things clearer. Better docs (for humans, no machine-specific hacks), better conventions, better examples, more intuitive code. That, in my opinion, is how markdown (for machines only and not humans) will fall. There will be a breed of projects that thrives with minimal machine-specific context. For example, if my project uses MIDI, I'm much better doing some specialized tools and examples that introduce MIDI to newcomers (machines and humans alike) than writing extensive "skill documents" that explain what MIDI is and how it works. Think like a human do. Do you prefer being introduced to a codebase by reading lots of verbose docs or having some ready-to-run examples that can get you going right away? We humans also forget, or ignore, or keep redundant context sources away (for a good reason).
ChicagoDave 9mo ago
I use 92% of context, have Claude write a “work summary” to a context folder, commit, push, quit, restart, repeat. I’m never stopped and Claude always remembers what we’re doing. This pattern has been highly productive for 8 months.
- csar 9mo ago
  You should never let context get that high unless you’re doing really basic things. Somewhere 40-60% is generally the time to start thinking about exits for tougher tasks. Get out in the 60s.
  - ChicagoDave 9mo ago
    I keep work chunks small, which is why I can hit 90%. If I do I have a large task like a big planning effort, yes I’d start fresh.
jijji 9mo ago
every time Claude code loads or it compacts the conversation it loses its context so I always type in: read CLAUDE.md .... which usually solves the problem... I run Claude code on a few screen sessions in different directories for months
BonoboIO 9mo ago
Different approach: I continuously refine my global CLAUDE.md (~/.claude/CLAUDE.md) instead of external memory systems. I work primarily in Python and maintain extensive coding conventions there - patterns allowed/forbidden, preferred libs, error handling, etc. Custom slash commands like `/use-recommended-python` (loads my curated libs: pendulum over datetime, httpx over requests) and `/find-reinvented-the-wheel` to catch when Claude ignored existing utilities. My use case: multiple smaller Python projects (similar to steipete's workflow https://github.com/steipete https://github.com/steipete), so cross-project consistency matters more than single-codebase context. Yes, ~15k tokens for CLAUDE.md + rules. I sacrifice context for consistency. Worth it. Also baked in my dev philosophy: Carmack-style - make it work first, then fast. Otherwise Claude over-optimizes prematurely. These memory abstractions are too complicated for me and too inconsistent in practice. I'd rather maintain a living document I control and constantly refine.
itissid 9mo ago
The general process feels very much like having kids over for a birthday party. Except you have to get them all to play nice and you have no idea what this other kid was conditioned on by their parents. Generally it would all work fine, all the kids know how the party progresses and what their roles are — if any. But imagine how hard it would be if these kids had short term memory only and they would not know what to focus on except what you tell them to. You literally have to tell them "Here is A-Z pay attention to 'X' only and go do your thing". Add in other managers for this party like a caterer, clowns, your spouse and they also have to tell them that and remember, communicate what other managers have done. No one has solved for this, really. This is what it felt like in 2025 to code with LLMs on non trivial projects, with some what of an improvement as the year went by. But I am not sure much progress was made in fixing the process part of the problem.
idiotsecant 9mo ago
Not X, not Y, just slop
- gnabgib 9mo ago
  They already admitted: https://news.ycombinator.com/item?id=46427193 https://news.ycombinator.com/item?id=46427193 https://news.ycombinator.com/item?id=46427016 https://news.ycombinator.com/item?id=46427016
itissid 9mo ago
has anyone had good experience with humanlayer's system/process of management? Just their thought management git system works pretty well for me TBH. https://www.humanlayer.dev/ https://www.humanlayer.dev/
AmiteK 9mo ago
One thing that seems under-discussed is what kind of state is worth persisting. Raw chat logs are cheap; distilled decisions, constraints, and preferences are harder but much more valuable. Even if most approaches fail, exploring that boundary feels useful - especially if the system is transparent about what it stores and why.
rmonvfer 9mo ago
Looks cool but as others have said, it’s really hard to just try all similar projects because all of them promise the same thing but I haven’t seen any of them provide any benchmarks. Claude Code keeps all the conversation logs stored on-disk right? Why not parse them asynchronously and then use hooks to enrich the context as the conversation goes? (I mean in the most broad and generic way, I guess we’d have to embed them, do some RAG… the whole thing)
- christinetyip 9mo ago
  Yep, parsing logs + async RAG works fine if you’re staying inside a single tool. The issue we ran into when building agent systems was portability. Once you want multiple agents or models to share the same evolving context, each tool reconstructing its own memory from transcripts stops scaling. We’re less focused on “making agents smarter” and more on avoiding fragmentation when context needs to move across agents, tools, or people — for example, using context created in Claude from Codex, or sharing specific parts of that context with a friend or a team. That’s also why benchmarks are tricky here. The gains tend to show up as less duplication and less state drift rather than a single accuracy metric. What would constitute convincing proof in this space for you?
bgun 9mo ago
I like this. Although - can we stop naming every project with a single short, common, vaguely related English word? Does anyone name software after what it actually does anymore? It’s almost as if software authors are afraid that if their project names are too descriptive, they won’t be able to pivot to some other purpose, which ends up making every project name sound at once banal and vague.
deleted 9mo ago
[deleted]
dmos62 9mo ago
I consider the "perfect fortgetfulness" of LLMs a great feature, because I can then precisely select what the context is for a given task. Context is additive, so once something's in it, it's doing something: most I could do is try to counteract it, which is like playing jailbreak. Then again, this might be just me. When there's a task to be done, even without an LLM my thought process is about selecting the relevant parts of my context for solving it. What is relevant? What starting point has the best odds of being good? That translates naturally to tasking an LLM. Let's say I have a spec I'm working on. It's based off of a requirements document. If I want to think about the spec in isolation (let's say I want to ask the LLM what requirements are actually being fulfilled by the spec), I can just pass the spec, without passing the requirements. Then I'll compare the response against the actual requirements. At the end of the day, I guess I hate the automagicness of a silent context injection. Like I said, it also negates the perfect forgetfulness of LLMs.
photios 9mo ago
Can it run with a local DB? I have zero interest in another monthly subscription pretending to be "an open source tool".
huali 9mo ago
I've built a lightweight Memory MCP service to efficiently store conversation memories. It only implements essential *CRUD* (Create, Read, Update, Delete) methods, minimizing token usage. Deploy the service on your cloud server or your local computer, then add the streamable MCP and skill to Claude Code. To activate in a new conversation, simply reference the skill first: `@~/.claude/skills/mem/SKILL.md`. If you like this project, please give it a star on GitHub!
- huali 9mo ago
  [dead]
minikomi 9mo ago
I use gptel[0] with my denote[1] notes, and a tool that can search/retrieve tags/grep/create notes (in a specific sub folder). It's been good enough as a memory for me. 0: https://github.com/karthink/gptel https://github.com/karthink/gptel 1: https://protesilaos.com/emacs/denote https://protesilaos.com/emacs/denote
kingkongjaffa 9mo ago
I actively don't want to use LLMs this way. I use things like claude projects on the web app and skills and stuff, and claude code heavily. I want to manually curate the context, adding memory is a anti pattern for this, I don't want the LLM grabbing tokens from memory that may or may not be relevant, and most likely will be stale.
christinetyip 9mo ago
A lot of the discussion here is about memory inside a single tool, which makes sense. I’m curious how people think about portability: e.g. letting Claude Code retrieve context that was created while using Codex, Manus, or Cursor, or sharing specific parts of that context with other people or agents. At that point, log parsing and summaries become per-tool views of state rather than shared state. Do people think a shared external memory layer is overkill here, or a necessary step once you have multiple agents/tools in play?
- d4rkp4ttern 9mo ago
  The aichat tool I mentioned in another comment [1] enables exactly this type of cross-agent work-continuation, specifically between Claude-Code and Codex-CLI. [1] https://news.ycombinator.com/item?id=46433213 https://news.ycombinator.com/item?id=46433213
vintagedave 9mo ago
“Not magic. Not AGI. Just state.” AI writing slop is infecting everything. Nothing turns me off this product more than the feeling you can’t even write about it as a human. If you can’t do that, why would I use or value it?
Terretta 9mo ago
Low effort in the Show HN copy suggests low effort in the tool. Not this. Not that. Just something. What it does. What it doesn't do. > ... fix it.
saberience 9mo ago
Do we really need another vibe-coded LLM context/memory startup? Do the authors have any benchmarks or test to show that this genuinely improved outputs? I have tried probably 10-20 other open source projects and closed source projects purporting to improve Claude Code with memory/context, and still to this date, nothing works better than simply keeping my own library of markdown files for each project specification, markdown files for decisions made etc, and then explicitly telling Claude Code to review x,y,z markdown files. I would also suggest to the founders, don't found a startup based on improving context for Claude Code, why? Because this is the number 1 thing the Claude Code developers are working on too, and it's clearly getting better and better with every release. So not only are you competing with like 20+ other startups and 20+ other open-source projects, you are competing with Anthropic too.
- sdoering 9mo ago
  This. Exactly this. Even relatively well working tools (from my experience and for my project types) like Agent OS are no guarantee, that Claude will not go on a tangent, use the "memory files" the framework tells it to use. And I agree with your sentiment, that this is a "business field" that will get eaten by the next generations of base models getting better.
- christinetyip 9mo ago
  I mostly agree with this, if the goal were “better persistent memory inside Claude Code,” that wouldn’t be very interesting. For a single agent and a single tool, keeping project specs and decisions in markdown and explicitly pointing the model at them works well. We do that too. What we’re focused on is a different boundary: memory that isn’t owned by a specific agent or tool. Once you start switching between tools (Claude, Codex, Cursor, etc.), or running multiple agents in parallel, markdown stops being “the memory” and becomes a coordination mechanism you have to keep in sync manually. Context created in one place doesn’t naturally flow to another, and you end up re-establishing state rather than accumulating it. That’s why we're not thinking about this as "improving Claude Code”. We’re interested in the layer above that: a shared, external memory that can be plugged into any other model and tools, that any agent can read from or write to, and that can be selectively shared with collaborators. Context created in Claude can be reused in Codex, Manus, Cursor, or other agents from collaborators - and vice versa. If one already built and is using one agent in one tool and is happy with markdown, they probably don’t need this. The value shows up once agents are treated as interchangeable workers and context needs to move across tools and people without being re-explained each time.
antonvs 9mo ago
> Not magic. Not AGI. Just state. Did Claude write this?
d4rkp4ttern 9mo ago
I like that it does not require following any particular "system" or discipline. But having to use a non-local/proprietary memory layer is not ideal. My own fully-local, minimalistic take on this problem of "session continuation without compaction" is to rely on the session JSONL files directly rather than create separate "memory" artifacts, and seamlessly index them to enable fast full-text search. This is the idea behind the "aichat" command-group + plugin I just added to my claude-code-tools [1] repo. You can quit your Claude-Code/Codex-CLI session S and type aichat resume <id-of-session-S-you-just-quit> It launches a TUI, offering a few ways to continue your work: - blind trim - clones the session, truncates large tool calls/results and older assistant messages, which can clear up as much as 50% of context depending of course on what's going on; this is a quick hack to continue your work a bit longer - smart trim - similar but uses headless agent to decide what to truncate - rollover: the one I use most frequently; it creates a new session S1 (which can optionally be a different CLI agent, allowing cross-agent work continuation), and injects back-pointers to the parent session JSONL file of S, the parent's parent , and so on (what I call session lineage) , into the first user message, and the user can then prompt the agent to use a sub-agent to extract arbitrary context from the ancestor sessions to continue the work. [1] https://github.com/pchalasani/claude-code-tools?tab=readme-ov-file#aichat-session-management https://github.com/pchalasani/claude-code-tools?tab=readme-o...
deadeye 9mo ago
Is this for people who haven't read the docs on how to instruct the agent on common setups and preferences?
jdthedisciple 9mo ago
introduces another layer of caching issues, the worst of all kinds ... not sure it's worth the risk
realitydrift 9mo ago
[flagged]
johann8384 9mo ago
I have markdown files in ~/.claude/guides that I refer to, my subagents have instructions about, and my claude.md in several projects reference them when relevant. This seems like it wouldn't accomplish much more than those methods. It knows my stack preferences, what I want commit messages to look like, etc.
Agent_Builder 9mo ago
[dead]
edmundsparrow 9mo ago
I've been manually copying responses between chats when I hit token limits, and I'm wondering - have you considered a multi-AI consensus approach instead of persistent memory? The idea: multiple AIs (Claude, GPT, Gemini, Grok) brainstorm simultaneously and produce one agreed response. This might solve the context problem more elegantly because: - No token limit anxiety - you get comprehensive answers upfront - Better quality through AI cross-validation - The consensus answer naturally becomes your context - Simpler to implement - just parallel API calls vs memory tree management Just curious if you've explored this direction or if there's a reason the memory persistence approach works better for your use case?
DNSZLSK 9mo ago
[dead]

202 points by austinbaggio 9mo ago

deleted 9mo ago

[deleted]

zyan1de 9mo ago

I mostly use it during long Claude Code research sessions so I don’t lose my place between days. I run it in automatic mode with decent namespacing, so thoughts, notes, and whole conversations just accumulate in a structured way. As I work, it stores the session and builds small semantic, entity-based hypergraphs of what I was thinking about. Later I’ll come back and ask things like: what was I actually trying to fix here? what research threads exist already? where did my reasoning drift? Sometimes I’ll even ask Claude to reflect on its own reasoning in a past session and point out where it was being reactive or missed connections.

altmanaltman 9mo ago

Thank you for specifying it wasn't magic or AGI.

austinbaggio 9mo ago
[flagged]
apublicfrog 9mo ago
> Not magic. Not AGI. Just state. Very clearly AI written
- fragmede 9mo ago
  You're absolutely right!

CPLX 9mo ago

I absolutely love this concept! It's like the thing that I've been looking for my whole life. Well, at least since I've been using Claude Code, which is this year. I'm sold. With that said, I can't think of a way that this would work. How does this work? I took a very quick glance, and it's not obvious at first glance. The whole problem is, the AI is short on context, it has limited memory. Of course, you can store lots of memory elsewhere, but how do you solve the problem of having the AI not know what's in the memory as it goes from step to step? How does it sort of find the relevant memory at the time that that relevance is most active? Could you just walk through the sort of conceptual mechanism of action of this thing?

zyan1de 9mo ago
yeah so you can run it in automatic mode, or read only mode. In automatic mode it hooks onto the conversation and tool calls so you get the entire conversation stored. If you dont want to get super deep, then read only is safe and only stores what you ask. You could ask it things like "why is my reasoning dumb" by recalling passed conversations, or even give it the claude tool call sequence and ask "how can claude be smarter about next time". I think of it like a file tree with proper namespacing and keep abstract concepts in separate directories. so like my food preferences will be in like /preferences/sandos. or you can even do things like /system-design preferences and then load them into a relevant conversation for next time.
skuenzli 9mo ago
It looks to me like the skill sets up a connection to their MCP server at api.ensue-network.ai during Claude session start via https://github.com/mutable-state-inc/ensue-skill/blob/main/scripts/session-start.sh https://github.com/mutable-state-inc/ensue-skill/blob/main/s... Then Claude uses the MCP tools according to the SKILL definition: https://github.com/mutable-state-inc/ensue-skill/blob/main/skills/ensue-memory/SKILL.md https://github.com/mutable-state-inc/ensue-skill/blob/main/s...
austinbaggio 9mo ago
Appreciate it - yeah, you're right, models don't work well when you just give it a giant dump of memory. We store memories in a small DB - think key/value pair with embeddings Every time you ask Claude something, the skill: 1. Embeds the current request. 2. Runs a semantic + timestamp-weighted search over your past sessions. Returns only the top N items that look relevant to this request. 3. Those get injected into the prompt as context (like extra system/user messages), so Claude sees just enough to stay oriented without blowing context limits. Think of it like: Attention over your historical work, more so than brute force recall. Context on demand basically giving you an infinite context window. Bookmark + semantic grep + temporal rank. It doesn’t “know everything all the time.” It just knows how to ask its own past: “What from memory might matter for this?” When you try it, I’d love to hear where the mechanism breaks for you.

senshan 9mo ago

What is the advantage over summarizing previous sessions for the new one? Or, over continuing the same session and compacting?

austinbaggio 9mo ago
You can use it with summaries for sure, but summaries often miss edge cases and long sessions drift. This makes it easier to jump between tasks, come back days later, and reorient without missing something that the summarization or compaction might have gotten rid of. I've often found post-compaction, the memory of even the current session feels so much dumber.
- ec109685 9mo ago
  You can go to a previous session and resume from there. Plus keep updating the repo claude.md along the way:

zyan1de 9mo ago

maybe you are in a claude code session and think "didn't i already make design doc for system like this one?" Or you could even look at your thought process in a previous session and reflect. but rn i mainly use it for reviewing research and the hypergraph retrieval

coffeeboy27 9mo ago

What's the data retention/deletion policy and is there a self-hosted option planned? I'd prefer not to send proprietary code to third-party servers.

austinbaggio 9mo ago
Honestly, very reasonable ask, you're not the first person to ask for a self-hosted version. We have a privacy policy we've drafted that is up-to-date with the current version of the product https://www.ensue-network.ai/privacy-policy https://www.ensue-network.ai/privacy-policy. The project is still in alpha, so you could shape what we build next - what do you need to see, or what gets you comfortable sending proprietary code to other external services?
- frumplestlatz 9mo ago
  > what do you need to see, or what gets you comfortable sending proprietary code to other external services? Honestly? It just has to be local. At work, we have contracts with OpenAI, Anthropic, and Google with isolated/private hosting requirements, coupled with internal, custom, private API endpoints that enforce our enterprise constraints. Those endpoints perform extensive logging of everything, and reject calls that contain even small portions of code if it's identified as belonging to a secret/critical project. There's just no way we're going to negotiate, pay for, and build something like that for every possible small AI tooling vendor. And at home, I feed AI a ton of personal/private information, even when just writing software for my own use. I also give the AI relatively wide latitude to vibe-code and execute things. The level of trust I need in external services that insert themselves in that loop is very high. I'm just not going to insert a hard dependency on an external service like this -- and that's putting aside the whole "could disappear / raise prices / enshittify at any time" aspect of relying on a cloud provider.
  - austinbaggio 9mo ago
    Yeah I get the dependency concern, and also I think about the trust and pricing challenge a lot. I might be getting ahead of my skis here, but living in a future world, assuming there is a local service, what would you want to see with a context management service for your team to actually use it? Or even better - pay for it?

sabareesh 9mo ago

Non starter for us, we cant ship propriety data to a third party servers.

austinbaggio 9mo ago
I assume this is with work? And also assume you do send data, you just need some service agreement or something like with AWS or Microsoft for GH?
- bg_tagas 9mo ago
  [dead]

qudat 9mo ago

Have you tried https://github.com/steveyegge/beads https://github.com/steveyegge/beads

PrayagS 9mo ago
+1 to beads. Works great
zyan1de 9mo ago
oh yeah beads is awesome! I'd say this is a bit more general purpose rn especially what is in the skill!
jswny 9mo ago
Can you give an example of how beads would be used by Claude to do something it otherwise couldn’t? I can’t quite tell what it is useful for
- frankc 9mo ago
  Personally, I have been using beads for a few days on a couple of projects. I also like https://github.com/Dicklesworthstone/beads_viewer https://github.com/Dicklesworthstone/beads_viewer which is a nice tui for beads (with some additional workflow i haven't tried). I have found its been useful for longer, multi-session implementations. Its easier to get back into the work. I wouldn't go so far as to it couldn't do the work without it, but so far it seems smoother. These things are hard to measure. I think the it's really not that different than how an engineering team would use jira but more hierarchical, which helps preserve context, and with prebuilt instructions for how the agent should use it.
rahimnathwani 9mo ago
Beads is awesome. I've been using it with a greenfield React Native hobby project. I did some work up front on the spec (with help from AI), and started the repo from a boilerplate, but after that every single bead (epic, ticket) and every single line of code has been written by AI (using a mix of claude, codex, cursor-agent/composer-1). The app works. When I feel like working on it, I just open a CLI coding agent and say 'start working'. Then every so often I say 'commit and push' or 'find opportunities to improve the code base by refactoring, and create an issue for each opportunity'. (I followed the instructions to add the boilerplate instructions for both bd and bv, to AGENTS.md)

deleted 9mo ago

[deleted]

JoshGlazebrook 9mo ago

Is anyone else just completely overwhelmed with the number of things you _need_ for claude code? Agents, sub agents, skills, claud.md, agents.md, rules, hooks, etc. We use Cursor where I work and I find it a good medium for still being in control and knowing what is happening with all of the changes being reviewed in an IDE. Claude feels more like a black box, and one with so many options that it's just overwhelming, yet I continue to try and figure out the best way to use it for my personal projects. Claude code suffers from initial decision fatigue in my opinion.

minimaxir 9mo ago
With Opus 4.5 in Claude Code, I'm doing fine with just a (very detailed) CLAUDE.md.
- austinbaggio 9mo ago
  Do you find you want to share the .md with the teams you work with? Or is it more for your solo coding?
  - Myrmornis 9mo ago
    Not saying you were suggesting it but people committing AGENTS.md in shared repos is pretty annoying IMO. Those things are personal.
asdev 9mo ago
you really don't need any of this crap. you just need Claude Code and CLAUDE.MD in directories where you need to direct it. complicated AI set ups are mid curve
- wouldbecouldbe 9mo ago
  It seems to mostly ignore Claude.md
  - 9mo ago

dr_dshiv 9mo ago

I just ask Claude to look at past conversations where I was working on x… it sometimes thinks it can’t see them, but it can. I’ll give this a go though and let you know!

ramoz 9mo ago
Here is a simple skill (markdown instruction only) that instructs a nice ripgrep approach - with utility of discovering current session. https://github.com/backnotprop/rg_history https://github.com/backnotprop/rg_history

AndyNemmity 9mo ago

I don't understand the use case. I think if you don't use agents, and skills currently effectively, then perhaps this is useful. If you're using them though, we no longer have the problem of Claude forgetting things.

lkbm 9mo ago
I'm curious how those replace this? I've barely used either, and would love to hear more.
- AndyNemmity 9mo ago
  Okay, Claude.md is an md file with instructions. Agents are an md file with instructions. Skills are an md file with instructions. Commands are.. you get the point. We're just dealing with instructions. Claude.md is handled by Claude Code. It is forgotten almost entirely often when the context fills. Okay, what is an agent? An agent is basically a Claude.md file, but you make it extremely granular. So it only has instructions of let's say, Typescript. We're all just doing context management here. We're trying to make sure our instructions that matter stay. To do that, we have to remove all other instructions from the picture. When you're doing typescript, you only know type script things. Okay, what's a skill? A skill is doing a single thing with type script. Why? So that the context is even smaller. Instead of the agent having every single instruction you need about typescript, you put them in skills so they only get put into context when that thing is needed. But skills are also where you connect deterministic programs. For example, I have a skill for creating images in nano banana. So when the Typescript Agent needs to create an image, it calls the skill, that calls the python script, to create images in nano banana. We're managing all the context to only be available when it's needed, keeping all other instructions out. Does that help?
  - lkbm 9mo ago
    A little. Thanks for the detailed reply. But I wouldn't expect a smaller, more targeted Claude.md would make a big difference. My impression is that we're filling up the context less with Claude.md than with the session work: back and forth about the specific task, Claude's chain-of-thought as it does that, the relevant sections of code, etc. That's what this is trying to compact and reference, iiuc. What I'd think would help, would be doing things in smaller chunks: an agent to do this small subtask, another to do that small subtask, and the parent task context only grows with the sub-agents reporting back, not with their chain-of-thought. Could be I should have a much bigger, more detailed Claude.md. Mine tend to be small project overviews and a list of TODOs, not that different from README.md: https://github.com/lkbm/sideways_math/blob/main/CLAUDE.md https://github.com/lkbm/sideways_math/blob/main/CLAUDE.md

bilbo-b-baggins 9mo ago

Your site advertises careers in San Francisco/Remote. California law requires compensation disclosures.

austinbaggio 9mo ago
Good flag, we're still pretty early, I think the strict requirement for compensation disclosures is post 15 employees in CA? Did I get this wrong?

ramoz 9mo ago

I struggle with these abstractions over context windows, esp when anthropic is actively focused on improving things like compaction, and knowing the eventual* goal is for the models to yave real memory layers baked in. Until then we have to optimize with how agents work best and ephemeral context is a part of that (they weren’t RL’d/trained with memory abstractions so we shouldn’t use them at inference either). Constant rediscovery that is task specific has worked well for me, doesn’t suffer from context decay, though it does eat more tokens. Otherwise the ability to search back through history is a valuable simple git log/diff or (rip)grep/jq combo over the session directory. Simple example of mine: https://github.com/backnotprop/rg_history https://github.com/backnotprop/rg_history

AndyNemmity 9mo ago
There is certainly a level where at any time you could be building some abstraction that is no longer required in a month, or 3. I feel that way too. I have a lot of these things. But the reality is, it doesn't really happen that often in my actual experience. Everyone is very slow as a whole to understand what these things mean, so far you get quite a bit of time just with an improved, customized system of your own.
- ramoz 9mo ago
  My somewhat naive heuristic would be that memory abstractions are a complete mistep in terms of optimization. There is no "super claude mem" or "continual claude" until there actually is. https://backnotprop.com/blog/50-first-dates-with-mr-meeseeks/ https://backnotprop.com/blog/50-first-dates-with-mr-meeseeks...
  - AndyNemmity 9mo ago
    I tend to agree with you, however compacting has gotten much worse. So... it's tough. I think memory abstractions are generally a mistake, and generally not needed, however I also think that compacting has gotten so wrong recently that they are also required until Claude Code releases a version with improved compacting. But I don't do memory abstraction like this at all. I use skills to manage plans, and the plans are the memory abstraction. But that is more than memory. That is also about having a detailed set of things that must occur.

robertwt7 9mo ago

Congrats for this! how does this differs from claude-mem? I've been using claude-mem for a while now https://github.com/thedotmack/claude-mem https://github.com/thedotmack/claude-mem

bgilly 9mo ago
Thanks for mentioning this. I installed claude-mem today and it’s already come in handy. Pretty neat how it can go get individual prompts and replies from previous sessions without consuming a lot of tokens. And I finally have some visibility into what my subagents are doing thanks for the real time feed web dashboard.

amannm 9mo ago

There's a lot of people interested in forming some sort of memory layer around vendored LLM services. I don't think they realize how much impact a single error that disappears from your immediate attention can have on downstream performance. Now think of the accrual of those errors over time and your lack of ability to discern if it was service degradation or a bad prompt or a bad AGENTS.md OR now this "long term memory" or whatever. If this sort of feature will ever be viable, the service providers will offer the best solution only behind their API, optimized for their models and their infrastructure.

ossa-ma 9mo ago

There are a quadrillion startups (mem0, langmem, zep, supermemory), open source repos (claude-mem, beads), and tools that do this. My approach is literally just a top-level, local, git version controlled memory system with 3 commands: - /handoff - End of session, capture into an inbox.md - /sync - Route inbox.md to custom organised markdown files - /engineering (or /projects, /tasks, /research) - Load context into next session I didn't want a database or an MCP server or embeddings or auto-indexing when I can build something frictionless that works with git and markdown. Repo: https://github.com/ossa-ma/double https://github.com/ossa-ma/double (just published it publicly but its about the idea imo) Writeup: https://ossa-ma.github.io/blog/double https://ossa-ma.github.io/blog/double

AndyNemmity 9mo ago
Your approach essentially matches mine, but I call them plans. I agree with you that the other tools don't seem to add any value compared to this structure. I think at this point in time, we both have it right.
bl4ckneon 9mo ago
The extention Cline has a "memory bank" feature. It's just a markdown you add as an instruction. Works well for me. Worked with agents.md as well so not just with the Cline extention. Pretty much the same idea.
fastball 9mo ago
What is the purpose of a separate /handoff and /sync command? It seems like handoff could just write learnings straight to their final destinations without needing an .inbox.md buffer in-between.
- ossa-ma 9mo ago
  I like to read and review what was captured in .inbox.md before it is committed and synced across my knowledge base. Allows me to catch mistakes, tweak preferences, add context and decide whether something is actually worth pushing. I will typically make multiple '/handoff's per day as I use Claude code whereas I typically use '/sync' at the end of the day to organise them all at once.

EMM_386 9mo ago

Just put a claude.md file in your directory. If you want more details about a subdirectory put one in there too. Claude itself can just update the claude.md file with whatever you might have forgot to put in there. You can stick it in git and it lives with the project.

graphememes 9mo ago

stop wasting context space with this stuff ミ · · 彡

lloydatkinson 9mo ago

> Not magic. Not AGI. Just state. Why did you need to use AI to write this post?

llmslave2 9mo ago
Their brains are mush, lost the ability to focus on a task or do any deep thinking. Just proooooooooompt.
- lloydatkinson 9mo ago
  insert prooomptorrrrr soyjack meme

ec109685 9mo ago

This is impressive. Though I have found repo level claude.md that is updated everytime claude makes a mistake plus using —restore to select a previous relevant session works well. There is no way for Anthropic to optimize Claude code or the underlying models for these custom setups. So it’s probably better to stick with the patterns Anthropic engineers use internally.

austinbaggio 9mo ago
Do you ever switch tools? I don't love the idea of my context being hostage of whatever LLM I choose first.
austinbaggio 9mo ago
If you give it a try, I think that use case should work, but if not, I would be grateful if you told us what broke. And also - I genuinely worry about vendor lock-in, do you?
- deleted 9mo ago
  [deleted]

fullstick 9mo ago

I like it when the conversation is new sometimes.

alex_young 9mo ago

Doesn't Claude already use RAG on the backend?

gbnwl 9mo ago

I'm not sure how many HN users frequent other places related to agentic coding like the subreddits of particular providers, but this has got to be the 1000th "ultimate memory system"/break-free-of-the-context-limit-tyranny! project I've seen, and like all other similar projects there's never any evidence or even attempt at measuring any metric of performance improved by it. Of course it's hard to measure such a thing, but that's part of exactly why it's hard to build something like this. Here's user #1001 that's been told by Claude "What a fascinating idea! You've identified a real gap in the market for a simple database based memory system to extend agent memory."

austinbaggio 9mo ago
Which of the 1000 is your favorite? There does seem to be a shallow race to optimizing xyz benchmark for some narrow sliver of the context problem, but you're right, context problem space is big, so I don't think we'll hurry to join that narrow race.
- gbnwl 9mo ago
  | Which of the 1000 is your favorite? None, that's what I'm trying to say. My favorite is just storing project context locally in docs that agents can discover on their own or I can point to if needed. This doesn't require me to upload sensitive code or information to anonymous people's side projects and has and equivalent amount of hard evidence for efficacy (zero), but at least has my own anecdotal evidence of helping and doesn't invite additonal security risk. People go way overboard with MCPs and armies of subagents built on wishes and unproven memory systems because no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. Doesn't mean it's time to send our data to strangers.
  - gck1 9mo ago
    > no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. FWIW, I find this eventual degradation point comes much later and with fewer consequences when there are strict guardrails inside and outside of the LLM itself. From what I've seen, most people try to fix only the "inside" part - by tweaking the prompts, installing 500 MCPs (that ironically pollute the context and make problem worse), yell in uppercase in hopes that it will remember etc, and ignore that automated compliance checks existed way before LLMs. Throw the strictest and most masochistic linting rules at it in a language that is masochistic itself (e.g. rust), add tons of integration tests that encode intent, add a stop hook in CC that runs all these checks and you've got a system that is simply not allowed to silently drift and can put itself back on track with feedback it gets from it. Basically, rather than trying to hypnotize an agent to remember everything by writing a 5000 line agents.md, just let the code itself scream at it and feed the context.

linsomniac 9mo ago

The past few weeks I've been experimenting with using less context and less memory and it's been going really well. Where before I'd try to do a bunch of fairly related things in a single session, experimenting with compacting more or less frequently, now I'm clearing my context or exiting and restarting claude and codex. It seems to help it focus on the task at hand, hasn't tended to go off into the weeds as much, and my token costs have dropped way down. Combined with a good AGENTS.md, it seems to be working really well.

einsteinx2 9mo ago
That’s been my experience as well. I find I usually get better output if I create a new conversation for each thing I need. I’ve found that the only times it’s better to continue an existing conversation is if I want to have it make small improvements or changes to something it just wrote, as it tends to do better with the previous context still there. But even that only goes so far, then the scale tips and it works much better with a clean slate. I especially don’t want totally unrelated conversations polluting the context which is why I have all memory features turned off in all the web chat UI’s for the models I use.

deleted 9mo ago

[deleted]

incoming1211 9mo ago

[dead]

jMyles 9mo ago

We built one too, with a web frontend and a 'spy' viewer in case your team wants to watch your interactions. Also has secret redaction: https://github.com/jMyles/memory-lane https://github.com/jMyles/memory-lane

scubbo 9mo ago

I've been tinkering with building something similar for myself - though for a generic chatbot, rather than for Claude (not every task is coding, and I'd like to keep !). From other comments (e.g. https://news.ycombinator.com/item?id=46428368 https://news.ycombinator.com/item?id=46428368, https://news.ycombinator.com/item?id=46427950 https://news.ycombinator.com/item?id=46427950) suggest that many others are already ahead of me. Any recs for tools, libraries, or approaches that I should learn from or adopt? In particular, I've found that - no matter how direct and clear the system prompt is - models have a tendency to respond verbally as if they've made a tool-call recording some gained-knowledge ("thanks! I'll remember that"), but to not actually return the JSON required to trigger the call by the tool.

austinbaggio 9mo ago
Since you've already thought about this problem, I'd love to hear your feedback after giving this skill a try. It should speed up at least your basic need of having to trigger the LLM to store the memory. One of our colleagues has found success asking at the end of a research session what he missed, how he could improve, etc.

devhouse 9mo ago

Feels like this is solving a problem that /compact should solve but doesn't. The fact that post-compaction Claude 'feels dumber' suggests the summarization is too aggressive? Would be interesting if Anthropic exposed more control over what gets preserved vs. compressed ... or let users provide their own summary template.

heliumtera 9mo ago

Stop Claude from forgetting by telling it to not forget

AndyNemmity 9mo ago
and put it in all caps, so it knows you mean business.
- wellthisisgreat 9mo ago
  alarm emoji alarm emoji alarm emoji

austinbaggio 9mo ago

Thanks everyone for the comments, really, I wasn't expecting this. Quite a few of you have mentioned that you store a lot of your working context across sessions in some md file - what are you actually storing? What data do you actually go back to and refer to as you're building?

EMM_386 9mo ago
> in some md file 1a directly from Anthropic on agentic coding and Claude Code best practices. "Create CLAUDE.md files" https://www.anthropic.com/engineering/claude-code-best-practices https://www.anthropic.com/engineering/claude-code-best-pract... It works great. You can put anything you want in there. Coding style, architecture guidelines, project explanation. Anything the agent needs to know to work properly with your code base. Similar to an onboarding document. Tools (Claude Code CLI, extensions) will pick them up hierarchically too if you want to get more specific about one subdirectory in your project. AGENTS.md is similar for other AI agents (OpenAI Codex is one). It doesn't even have to be those - you can just @ the filename at the start of the chat and that information goes in the context. The naming scheme just allows for it to be automatic.

gaigalas 9mo ago

I like the fact that it forgets. Each time an LLM looks at my project, it's like a newcomer has arrived. If it keeps repeating mistakes, it's because my project sucks. It's an unique opportunity. You can have lots of repeated feedback from "infinite newcomers" to a project, each of their failures an opportunity to make things clearer. Better docs (for humans, no machine-specific hacks), better conventions, better examples, more intuitive code. That, in my opinion, is how markdown (for machines only and not humans) will fall. There will be a breed of projects that thrives with minimal machine-specific context. For example, if my project uses MIDI, I'm much better doing some specialized tools and examples that introduce MIDI to newcomers (machines and humans alike) than writing extensive "skill documents" that explain what MIDI is and how it works. Think like a human do. Do you prefer being introduced to a codebase by reading lots of verbose docs or having some ready-to-run examples that can get you going right away? We humans also forget, or ignore, or keep redundant context sources away (for a good reason).

ChicagoDave 9mo ago

I use 92% of context, have Claude write a “work summary” to a context folder, commit, push, quit, restart, repeat. I’m never stopped and Claude always remembers what we’re doing. This pattern has been highly productive for 8 months.

csar 9mo ago
You should never let context get that high unless you’re doing really basic things. Somewhere 40-60% is generally the time to start thinking about exits for tougher tasks. Get out in the 60s.
- ChicagoDave 9mo ago
  I keep work chunks small, which is why I can hit 90%. If I do I have a large task like a big planning effort, yes I’d start fresh.

jijji 9mo ago

every time Claude code loads or it compacts the conversation it loses its context so I always type in: read CLAUDE.md .... which usually solves the problem... I run Claude code on a few screen sessions in different directories for months

BonoboIO 9mo ago

Different approach: I continuously refine my global CLAUDE.md (~/.claude/CLAUDE.md) instead of external memory systems. I work primarily in Python and maintain extensive coding conventions there - patterns allowed/forbidden, preferred libs, error handling, etc. Custom slash commands like `/use-recommended-python` (loads my curated libs: pendulum over datetime, httpx over requests) and `/find-reinvented-the-wheel` to catch when Claude ignored existing utilities. My use case: multiple smaller Python projects (similar to steipete's workflow https://github.com/steipete https://github.com/steipete), so cross-project consistency matters more than single-codebase context. Yes, ~15k tokens for CLAUDE.md + rules. I sacrifice context for consistency. Worth it. Also baked in my dev philosophy: Carmack-style - make it work first, then fast. Otherwise Claude over-optimizes prematurely. These memory abstractions are too complicated for me and too inconsistent in practice. I'd rather maintain a living document I control and constantly refine.

itissid 9mo ago

The general process feels very much like having kids over for a birthday party. Except you have to get them all to play nice and you have no idea what this other kid was conditioned on by their parents. Generally it would all work fine, all the kids know how the party progresses and what their roles are — if any. But imagine how hard it would be if these kids had short term memory only and they would not know what to focus on except what you tell them to. You literally have to tell them "Here is A-Z pay attention to 'X' only and go do your thing". Add in other managers for this party like a caterer, clowns, your spouse and they also have to tell them that and remember, communicate what other managers have done. No one has solved for this, really. This is what it felt like in 2025 to code with LLMs on non trivial projects, with some what of an improvement as the year went by. But I am not sure much progress was made in fixing the process part of the problem.

idiotsecant 9mo ago

Not X, not Y, just slop

gnabgib 9mo ago
They already admitted: https://news.ycombinator.com/item?id=46427193 https://news.ycombinator.com/item?id=46427193 https://news.ycombinator.com/item?id=46427016 https://news.ycombinator.com/item?id=46427016

itissid 9mo ago

has anyone had good experience with humanlayer's system/process of management? Just their thought management git system works pretty well for me TBH. https://www.humanlayer.dev/ https://www.humanlayer.dev/

AmiteK 9mo ago

One thing that seems under-discussed is what kind of state is worth persisting. Raw chat logs are cheap; distilled decisions, constraints, and preferences are harder but much more valuable. Even if most approaches fail, exploring that boundary feels useful - especially if the system is transparent about what it stores and why.

rmonvfer 9mo ago

Looks cool but as others have said, it’s really hard to just try all similar projects because all of them promise the same thing but I haven’t seen any of them provide any benchmarks. Claude Code keeps all the conversation logs stored on-disk right? Why not parse them asynchronously and then use hooks to enrich the context as the conversation goes? (I mean in the most broad and generic way, I guess we’d have to embed them, do some RAG… the whole thing)

christinetyip 9mo ago
Yep, parsing logs + async RAG works fine if you’re staying inside a single tool. The issue we ran into when building agent systems was portability. Once you want multiple agents or models to share the same evolving context, each tool reconstructing its own memory from transcripts stops scaling. We’re less focused on “making agents smarter” and more on avoiding fragmentation when context needs to move across agents, tools, or people — for example, using context created in Claude from Codex, or sharing specific parts of that context with a friend or a team. That’s also why benchmarks are tricky here. The gains tend to show up as less duplication and less state drift rather than a single accuracy metric. What would constitute convincing proof in this space for you?

bgun 9mo ago

I like this. Although - can we stop naming every project with a single short, common, vaguely related English word? Does anyone name software after what it actually does anymore? It’s almost as if software authors are afraid that if their project names are too descriptive, they won’t be able to pivot to some other purpose, which ends up making every project name sound at once banal and vague.

deleted 9mo ago

[deleted]

dmos62 9mo ago

I consider the "perfect fortgetfulness" of LLMs a great feature, because I can then precisely select what the context is for a given task. Context is additive, so once something's in it, it's doing something: most I could do is try to counteract it, which is like playing jailbreak. Then again, this might be just me. When there's a task to be done, even without an LLM my thought process is about selecting the relevant parts of my context for solving it. What is relevant? What starting point has the best odds of being good? That translates naturally to tasking an LLM. Let's say I have a spec I'm working on. It's based off of a requirements document. If I want to think about the spec in isolation (let's say I want to ask the LLM what requirements are actually being fulfilled by the spec), I can just pass the spec, without passing the requirements. Then I'll compare the response against the actual requirements. At the end of the day, I guess I hate the automagicness of a silent context injection. Like I said, it also negates the perfect forgetfulness of LLMs.

photios 9mo ago

Can it run with a local DB? I have zero interest in another monthly subscription pretending to be "an open source tool".

huali 9mo ago

I've built a lightweight Memory MCP service to efficiently store conversation memories. It only implements essential *CRUD* (Create, Read, Update, Delete) methods, minimizing token usage. Deploy the service on your cloud server or your local computer, then add the streamable MCP and skill to Claude Code. To activate in a new conversation, simply reference the skill first: `@~/.claude/skills/mem/SKILL.md`. If you like this project, please give it a star on GitHub!

huali 9mo ago
[dead]

minikomi 9mo ago

I use gptel[0] with my denote[1] notes, and a tool that can search/retrieve tags/grep/create notes (in a specific sub folder). It's been good enough as a memory for me. 0: https://github.com/karthink/gptel https://github.com/karthink/gptel 1: https://protesilaos.com/emacs/denote https://protesilaos.com/emacs/denote

kingkongjaffa 9mo ago

I actively don't want to use LLMs this way. I use things like claude projects on the web app and skills and stuff, and claude code heavily. I want to manually curate the context, adding memory is a anti pattern for this, I don't want the LLM grabbing tokens from memory that may or may not be relevant, and most likely will be stale.

christinetyip 9mo ago

A lot of the discussion here is about memory inside a single tool, which makes sense. I’m curious how people think about portability: e.g. letting Claude Code retrieve context that was created while using Codex, Manus, or Cursor, or sharing specific parts of that context with other people or agents. At that point, log parsing and summaries become per-tool views of state rather than shared state. Do people think a shared external memory layer is overkill here, or a necessary step once you have multiple agents/tools in play?

d4rkp4ttern 9mo ago
The aichat tool I mentioned in another comment [1] enables exactly this type of cross-agent work-continuation, specifically between Claude-Code and Codex-CLI. [1] https://news.ycombinator.com/item?id=46433213 https://news.ycombinator.com/item?id=46433213

vintagedave 9mo ago

“Not magic. Not AGI. Just state.” AI writing slop is infecting everything. Nothing turns me off this product more than the feeling you can’t even write about it as a human. If you can’t do that, why would I use or value it?

Terretta 9mo ago

Low effort in the Show HN copy suggests low effort in the tool. Not this. Not that. Just something. What it does. What it doesn't do. > ... fix it.

saberience 9mo ago

Do we really need another vibe-coded LLM context/memory startup? Do the authors have any benchmarks or test to show that this genuinely improved outputs? I have tried probably 10-20 other open source projects and closed source projects purporting to improve Claude Code with memory/context, and still to this date, nothing works better than simply keeping my own library of markdown files for each project specification, markdown files for decisions made etc, and then explicitly telling Claude Code to review x,y,z markdown files. I would also suggest to the founders, don't found a startup based on improving context for Claude Code, why? Because this is the number 1 thing the Claude Code developers are working on too, and it's clearly getting better and better with every release. So not only are you competing with like 20+ other startups and 20+ other open-source projects, you are competing with Anthropic too.

sdoering 9mo ago
This. Exactly this. Even relatively well working tools (from my experience and for my project types) like Agent OS are no guarantee, that Claude will not go on a tangent, use the "memory files" the framework tells it to use. And I agree with your sentiment, that this is a "business field" that will get eaten by the next generations of base models getting better.
christinetyip 9mo ago
I mostly agree with this, if the goal were “better persistent memory inside Claude Code,” that wouldn’t be very interesting. For a single agent and a single tool, keeping project specs and decisions in markdown and explicitly pointing the model at them works well. We do that too. What we’re focused on is a different boundary: memory that isn’t owned by a specific agent or tool. Once you start switching between tools (Claude, Codex, Cursor, etc.), or running multiple agents in parallel, markdown stops being “the memory” and becomes a coordination mechanism you have to keep in sync manually. Context created in one place doesn’t naturally flow to another, and you end up re-establishing state rather than accumulating it. That’s why we're not thinking about this as "improving Claude Code”. We’re interested in the layer above that: a shared, external memory that can be plugged into any other model and tools, that any agent can read from or write to, and that can be selectively shared with collaborators. Context created in Claude can be reused in Codex, Manus, Cursor, or other agents from collaborators - and vice versa. If one already built and is using one agent in one tool and is happy with markdown, they probably don’t need this. The value shows up once agents are treated as interchangeable workers and context needs to move across tools and people without being re-explained each time.

antonvs 9mo ago

> Not magic. Not AGI. Just state. Did Claude write this?

d4rkp4ttern 9mo ago

I like that it does not require following any particular "system" or discipline. But having to use a non-local/proprietary memory layer is not ideal. My own fully-local, minimalistic take on this problem of "session continuation without compaction" is to rely on the session JSONL files directly rather than create separate "memory" artifacts, and seamlessly index them to enable fast full-text search. This is the idea behind the "aichat" command-group + plugin I just added to my claude-code-tools [1] repo. You can quit your Claude-Code/Codex-CLI session S and type aichat resume <id-of-session-S-you-just-quit> It launches a TUI, offering a few ways to continue your work: - blind trim - clones the session, truncates large tool calls/results and older assistant messages, which can clear up as much as 50% of context depending of course on what's going on; this is a quick hack to continue your work a bit longer - smart trim - similar but uses headless agent to decide what to truncate - rollover: the one I use most frequently; it creates a new session S1 (which can optionally be a different CLI agent, allowing cross-agent work continuation), and injects back-pointers to the parent session JSONL file of S, the parent's parent , and so on (what I call session lineage) , into the first user message, and the user can then prompt the agent to use a sub-agent to extract arbitrary context from the ancestor sessions to continue the work. [1] https://github.com/pchalasani/claude-code-tools?tab=readme-ov-file#aichat-session-management https://github.com/pchalasani/claude-code-tools?tab=readme-o...

deadeye 9mo ago

Is this for people who haven't read the docs on how to instruct the agent on common setups and preferences?

jdthedisciple 9mo ago

introduces another layer of caching issues, the worst of all kinds ... not sure it's worth the risk

realitydrift 9mo ago

[flagged]

johann8384 9mo ago

I have markdown files in ~/.claude/guides that I refer to, my subagents have instructions about, and my claude.md in several projects reference them when relevant. This seems like it wouldn't accomplish much more than those methods. It knows my stack preferences, what I want commit messages to look like, etc.

Agent_Builder 9mo ago

[dead]

edmundsparrow 9mo ago

I've been manually copying responses between chats when I hit token limits, and I'm wondering - have you considered a multi-AI consensus approach instead of persistent memory? The idea: multiple AIs (Claude, GPT, Gemini, Grok) brainstorm simultaneously and produce one agreed response. This might solve the context problem more elegantly because: - No token limit anxiety - you get comprehensive answers upfront - Better quality through AI cross-validation - The consensus answer naturally becomes your context - Simpler to implement - just parallel API calls vs memory tree management Just curious if you've explored this direction or if there's a reason the memory persistence approach works better for your use case?

DNSZLSK 9mo ago

[dead]