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.
Show HN: Stop Claude Code from forgetting everything
181–190 of 241 posts
Re: Show HN: Stop Claude Code from forgetting everything
#182I'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…
This is fair, many memory projects out there boil down to better summaries or prompt glue without any clear way to measure impact.
One thing I’d clarify about what we’re building is that it’s not meant to be “the best memory for a single agent.”
The core idea is portability and sharing, not just persistence.
Concretely:
- you can give Codex access to memory created while working in Claude
- Claude Code can retrieve context from work done in other tools
- multiple agents can read/write the same memory instead of each carrying their own partial copy
- specific parts of context can be shared with teammates or collaborators
That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory, and it’s also why we don’t frame this as “breaking the context limit.”
Measuring impact here is tricky, but the problem we’re solving shows up as fragmentation rather than forgetting: duplicated explanations, divergent state between agents, and lost context when switching tools or models.
If someone only uses a single agent in a single tool and already are using their customized CLAUDE.md, they probably don’t need this. The value shows up once you treat agents as interchangeable workers rather than a single long-running conversation.
Re: Show HN: Stop Claude Code from forgetting everything
#183Looks 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…
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?
Re: Show HN: Stop Claude Code from forgetting everything
#184I 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.
Re: Show HN: Stop Claude Code from forgetting everything
#185A 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?
Re: Show HN: Stop Claude Code from forgetting everything
#186I 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.
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.
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.
Re: Show HN: Stop Claude Code from forgetting everything
#187I'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…
I feel like so many of these memory solutions are incredibly over-engineered too. You can work around a lot of the memory issues for large and complex tasks just by making the agent keep work logs. Critical context to keep throughout large pieces of work include decisions, conversations, investigations, plans and implementations - a normal developer should be tracking these and it's sensible to have the agent track t…
Yes. I have (as part of Claude output) a
- `FEATURE_IMPL_PLAN.md` (master plan; or `NEXT_FEATURES_LIST.md` or somesuch)
- `FEATURE_IMPL_PROMPT_TEMPLATE.md` (where I replace placeholders with next feature to be implemented; prompt includes various points about being thorough, making sure to validate and loop until full test pipeline works, to git version tag upon user confirmation, etc.)
- `feature-impl-plans/` directory where Claude is to keep per-feature detailed docs (with current status) up to date - this is esp. useful for complex features which may require multiple sessions for example
- also instruct it to keep main impl plan doc up to date, but that one is limited in size/depth/scope on purpose, not to overwhelm it
- CLAUDE.md has summary of important code references (paths / modules / classes etc.) for lookup, but is also restricted in size. But it includes full (up-to-date) inventory of all doc files, for itself
- If I end up expanding CLAUDE.md for some reason or temporarily (before I offload some content to separate docs), I will say as part of prompt template to "make sure to read in the whole @CLAUDE.md without skipping any content"
Re: Show HN: Stop Claude Code from forgetting everything
#188Earlier quoted context omitted.
i don't understand this mcp/skill distinction? one of the mcps i use indexes the runtime dependency of code modules so that claude can refactor without just blindly grepping. how would that be a "skill"? just wrap the mcp in a cli? fwiw this may be a skill issue, pun intended, but i can't seem to get claude to trigger skills, whereas it reaches for mcps more... i wonder if im missing something. I'm plenty productive…
So MCPs are a bunch of, essenntially skill type objects. But it has to tell you about all of them, and information about all of them up front. So a Skill is just a smaller granulatrity level of that concept. It's just one of the individual things an MCP can do. This is about context management at some level. When you need to do a single thing within that full list of potential things, you don't need the instructions…
no that makes no sense. the skill doesn't do anything by itself, the mcp (can be) attached to a deterministic oracle that can return correct information.
Re: Show HN: Stop Claude Code from forgetting everything
#189“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?
Re: Show HN: Stop Claude Code from forgetting everything
#190Earlier quoted context omitted.
Great advise. For large plans I tell the agent to write to an “implementation_log.md” and make note of it during compaction. Additionally the agent can also just reference the original session logs.
The problem with this approach, is that the model may forget to update the log... It usually happens when the context window >50% filled
.. and not only those, but the baseline as well aka CLAUDE.md.. I've countless of times told it basics, in the same session without compacting etc etc