Show HN: Recall: Give Claude memory with Redis-backed persistent context
npmjs.com170 points by elfenleid 5 days ago
170 points by elfenleid 5 days ago
Hey HN! I'm José, and I built Recall to solve a problem that was driving me crazy.
The Problem: I use Claude for coding daily, but every conversation starts from scratch. I'd explain my architecture, coding standards, past decisions... then hit the context limit and lose everything. Next session? Start over.
The Solution: Recall is an MCP (Model Context Protocol) server that gives Claude persistent memory using Redis + semantic search. Think of it as long-term memory that survives context limits and session restarts.
How it works: - Claude stores important context as "memories" during conversations - Memories are embedded (OpenAI) and stored in Redis with metadata - Semantic search retrieves relevant memories automatically - Works across sessions, projects, even machines (if you use cloud Redis)
Key Features: - Global memories: Share context across all projects - Relationships: Link related memories into knowledge graphs - Versioning: Track how memories evolve over time - Templates: Reusable patterns for common workflows - Workspace isolation: Project A memories don't pollute Project B
Tech Stack: - TypeScript + MCP SDK - Redis for storage - OpenAI embeddings (text-embedding-3-small) - ~189KB bundle, runs locally
Current Stats: - 27 tools exposed to Claude - 10 context types (directives, decisions, patterns, etc.) - Sub-second semantic search on 10k+ memories - Works with Claude Desktop, Claude Code, any MCP client
Example Use Case: I'm building an e-commerce platform. I told Claude once: "We use Tailwind, prefer composition API, API rate limit is 1000/min." Now every conversation, Claude remembers and applies these preferences automatically.
What's Next (v1.6.0 in progress): - CI/CD pipeline with GitHub Actions - Docker support for easy deployment - Proper test suite with Vitest - Better error messages and logging
Try it:
npm install -g @joseairosa/recall
# Add to claude_desktop_config.json
# Start using persistent memory
Why would you bloat the (already crowded) context window with 27 tools instead of the 2 simplest ones: Save Memory & Search Memory? Or even just search, handling the save process through a listener on a directory of markdown memory files that Claude Code can natively edit? MCP's are toys for point-and-click devs that no self-respecting dev has any business using. Case in point; I'm mostly a Claude user, which has decent background process / BashOutput support to get a long-running process's stdout. I was using codex just now, and its processes support is ass. So I asked it, give me 5 options using cli tools to implement process support. After 3 min back and forth, I got this: https://github.com/offline-ant/shellagent-tools/blob/main/ba... Add single line in AGENTS.md. > the `background` tool allows running programs in the background. Calling `background` outputs the help. Now I can go "background ./server; try thing. investigate" and it has access to the stdout. Stop pre-trashing your context with MCPs people. Yep. Most MCP servers are best repackaged as a cli tool, and telling the LLM to invoke `toolname --help` to learn how to use it at runtime. The primary downside is that they LLM will have a lower proclivity to invoke those tools unless explicitly reminded to. If you do like rolling your own MCP servers, I've had great success recently refactoring a bunch of my own to consume fewer tokens by, instead of creating many different tools, consolidating the tools and passing through different arguments. People are just ricing out AI like they rice out Linux, nvim or any other thing. It's pretty simple to get results from the tech. Use the CLI and know what you're doing. Fair points, share how you are learning - seems to be more than one way to the same result. Maintain a good agents.md with notes on code grammar/structure/architecture conventions your org uses, then for each problem, prompt it step-by-step as if you were a junior engineer's monologue. e.g. as I am dropped into a new codebase: 1. Ask Claude to find the section of code that controls X 2. Take a look manually 3. Ask it to explain the chain of events 4. Ask it to implement change Y, in order to modify X to do behavior we want 5. Ask it about any implementation details you don't understand, or want clarification on -- it usually self-edits well. 6. You can ask it to add comments, tests, etc., at this point, and it should run tests to confirm everything works as expected. 7. Manually step through tests, then code, to sanity check (it can easily have errors in both). 8. Review its diff to satisfaction. 9. Ask it to review its own diff as if it was a senior engineer. This is the method I've been using, as I onboard onto week 1 in a new codebase. If the codebase is massive, and READMEs are weak, AI copilot tools can cut down overall PR time by 2-3x. I imagine overall performance dips after developer familiarity increases. From my observation, it's especially great for automating code-finding and logic tracing, which often involves a bunch of context-switching and open windows--human developers often struggle with this more than LLMs. Also great for creating scaffolding/project structure. Overall weak at debugging complex issues, less-documented public API logic, often has junior level failures. Great walkthrough, I might send your comment to my coworkers. I use AI to write pretty much 100% of my code and my process looks similar. For writing code, you really want to step through each edit one by one and course-correct it as you go. A lot of times it's obvious when it's taking a suboptimal approach and it's much easier to correct before the wrong thing is written. Plus it's easier to control this way than trying to overengineer rules files to get it to do exactly what you want. The "I'm running 10 autonomous agents at once" stuff is a complete joke unless you are a solo dev just trying to crap something working out. I use Sonnet 4.5 exclusively for this right now. Codex is great if you have some kind of high-context tricky logic to think through. If Sonnet 4.5 gets stuck I like to have it write a prompt for Codex. But Codex is not a good daily driver. As usual with people describing their AI workflows, I’m amazed how complicated and hand-holding their whole process is. Sounds like you’re spending the time you would otherwise spend on the task to struggle with ai tools. That's a great point, the reality is that context, at least from personal experience, is brittle and over time will start to lose precision. This is a always there, persistent way for claude to access "memories". I've been running with it for about a week now and did not feel that the context would get bloated. I do notice building up context makes a difference. Having the context modular helps too. Yes, exactly this. But idiot VC funding (which YC is also somewhat engaged in I imagine) cries for MCP. Hence multi billion valuations and many million dollar salaries and bonuses being thrown around. It's ridiculous and ties into the overall state of the world tbh. Pretty much given up hoping that we'll become an enlightened species. So let's enjoy our stupid MCP and stupid disposable plastic because I don't see any way that we aren't gonna cook ourselves to extinction on this planet. :) While I totally agree with you, I also can see a world where we just throw a ton of calls in the MCP and then wrap it in a subagent that has a short description listing every verb it has access to. Absolutely. Remember these are just tools, how each one of us uses them it's a diffrent story. A lot can be leveraged as well by adding a couple of lines to CLAUDE.md on how he should use this memory solution, or not, it's totally up to anyone.
You can also have a subagent that is responsible for project management that is in charge of managing memory or having a coordinator. Again a lot of testing needs to be done :) Why would you not use context files in form of .md? E.g. how the SpecKit project does it. Memory features are useful for the same reason that a human would use a database instead of a large .md file: it's more efficient to query for something and get exactly what you want than it is to read through a large, ultimately less structured document. That said, Claude now has a native memory feature as of the 2.0 release recently: https://docs.claude.com/en/docs/claude-code/memory so the parent's tool may be too late, unless it offers some kind of advantage over that. I don't know how to make that comparison, personally. Claude’s memory function adds a note to the file(s) that it reads on startup. Whereas this tool pulls from a database of memories on-demand. So hilariously, I hadn't actually read those docs yet, I just knew they added the feature. It seems like the docs may not be up to date, as when I read them in response to your reply here, I was like "wait, I thought it was more sophisticated than that!" The answer seems to be both yes and no: see their announcement on youtube yesterday: https://www.youtube.com/watch?v=Yct0MvNtdfU&t=181s It's still ultimately file-based, but it can create non-Claude.md files in a directory it treats more specially. So it's less sophisticated than I expected, but more sophisticated than the previous "add this to claude.md" feature they've had for a while. Thanks for the nudge to take the time to actually dig into the details :) It creates them on its own? Okay so, now that I've had time after work to play with it... it doesn't work like in the video! The video shows /memories, but it's /memory, and when I run the command, it seems to be listing out the various CLAUDE.md files, and just gives you a convenient way to edit them. I wonder if the feature got cut for scope, if I'm not in some sort of beta of a better feature, or what. How disappointing! Let me have a look, thanks for reporting that. This is very much in development and I keep adding features to it. Any suggestions let me know. The way I use it, I add instructions to CLAUDE.md on how I want him to use recall, and when. ## Using Recall Memory Efficiently *IMPORTANT: Be selective with memory storage to avoid context bloat.* ### When to Store Memories
- Store HIGH-LEVEL decisions, not implementation details
- Store PROJECT PREFERENCES (coding style, architecture patterns, tech stack)
- Store CRITICAL CONSTRAINTS (API limits, business rules, security requirements)
- Store LEARNED PATTERNS from bugs/solutions ### When NOT to Store
- Don't store code snippets (put those in files)
- Don't store obvious facts or general knowledge
- Don't store temporary context (only current session needs)
- Don't duplicate what's already in documentation ### Memory Best Practices
- Keep memories CONCISE (1-2 sentences ideal)
- Use TAGS for easy filtering
- Mark truly critical things with importance 8-10
- Let old, less relevant memories decay naturally ### Examples
GOOD: "API rate limit is 1000 req/min, prefer caching for frequently accessed data"
BAD: "Here's the entire implementation of our caching layer: [50 lines of code]" GOOD: "Team prefers Tailwind CSS over styled-components for consistency"
BAD: "Tailwind is a utility-first CSS framework that..." *Remember: Recall is for HIGH-SIGNAL context, not a code repository.* If you look at the changelog[0] for 2.0, it doesn't mention any memory features. I also find it strange that they released this as 2.0 without any new actual Claude Code features other than /rewind, which I'm not sure what is for, since we already have version control. [0]: https://github.com/anthropics/claude-code/blob/main/CHANGELO... So, when Anthropic had that huge release day, with Sonnet 4.5, Code 2.0, etc, this was one of the things they published: https://www.anthropic.com/news/context-management > The memory tool enables Claude to store and consult information outside the context window through a file-based system. Claude can create, read, update, and delete files in a dedicated memory directory stored in your infrastructure that persists across conversations. This allows agents to build up knowledge bases over time, maintain project state across sessions, and reference previous learnings without having to keep everything in context. This is what made me think that it came out with the 2.0.0 release. But apparently /memory landed in 1.0.94. Frustrating! FWIW, you can instruct it to edit CLAUDE.md on its own. At this point I am too lazy to type myself, so I never used /memory (which just appends to CLAUDE.md). The problem though is that it gets bloated and hard-to-read pretty quickly, and I forget what exactly I put in there.
pacoWebConsult - 5 days ago
athrowaway3z - 5 days ago
laborcontract - 4 days ago
fishmicrowaver - 5 days ago
j45 - 5 days ago
icedrop - 4 days ago
extr - 4 days ago
blks - 4 days ago
elfenleid - 5 days ago
j45 - 5 days ago
fennecbutt - 5 days ago
jrecyclebin - 5 days ago
elfenleid - 5 days ago
bryanhogan - 5 days ago
steveklabnik - 5 days ago
ebcode - 5 days ago
steveklabnik - 5 days ago
koakuma-chan - 5 days ago
steveklabnik - 5 days ago
elfenleid - 5 days ago
koakuma-chan - 4 days ago
steveklabnik - 4 days ago
koakuma-chan - 4 days ago