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.
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!"
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 :)
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.
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.
> 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.
1. Claude Desktop's built-in `/memory` command (what you tried) - just lists CLAUDE.md files
2. Recall MCP server (this project) - completely separate tool you need to install
Recall doesn't work through slash commands. It's an MCP server that needs setup:
1. Install: npm install -g @joseairosa/recall
2. Add to claude_desktop_config.json
3. Restart Claude Desktop
4. Then Claude can use memory tools automatically in conversation
Quick test after setup: "Remember: I prefer TypeScript" - Claude will store it in Redis.
The other point here, I wanted something more in line with LLMs natural language, something that can be queried more effeciently buy just using normal language, almost like the way we think normally, we first have a though and then we go through our memory archive.
I still do, but having this allows for strategies like memory decay for older information. It also allows for much more structured searching capabilities, instead of opening file which are less structured.
.md files work great for small projects. But they hit limits:
1. Size - 100KB context.md won't fit in the window
2. No search - Claude reads the whole file every time
3. Manual - You decide what to save, not Claude
4. Static - Doesn't evolve or learn
Recall fixes this:
- Semantic search finds relevant memories only
- Auto-captures context during conversations
- Handles 10k+ memories, retrieves top 5
- Works across multiple projects
Real example: I have 2000 memories. That's 200KB in .md form. Recall retrieves 5 relevant ones = 2KB.
And of course, there's always the option to use both .md for docs, Recall for dynamic learning.
I'm not sure. You don't use a single context.md file, you use multiple and add them when relevant in context. AIs adjust these as you need, so they do "evolve". So what you try to achieve is already solved.
These two videos on using Claude well explain what I mean:
Yeah that's a solid workflow and honestly simpler than what I built - I think Recall makes sense when you hit the scale where managing multiple .md files becomes tedious (like 50+ conversations across 10 projects), but you're right that for most people your approach works great and is way less complex.
Can't you get recency just from git blame? Editors already show you each source line's last-touch age, even in READMEs, and even though this can get obfuscated (by reformatters, file moves, etc.) it's still a decent indicator.
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.
Yeah previously it had # to make that easy. But I also worry about CLAUDE.md bloat and so don't tend to continually update it.
Oh yeah # is actually what I meant.
Hey! You're mixing up two different things:
1. Claude Desktop's built-in `/memory` command (what you tried) - just lists CLAUDE.md files 2. Recall MCP server (this project) - completely separate tool you need to install
Recall doesn't work through slash commands. It's an MCP server that needs setup:
1. Install: npm install -g @joseairosa/recall 2. Add to claude_desktop_config.json 3. Restart Claude Desktop 4. Then Claude can use memory tools automatically in conversation
Quick test after setup: "Remember: I prefer TypeScript" - Claude will store it in Redis.
Sorry for the confusion, I was purely commenting about Claude. I have not tried your MCP.
The other point here, I wanted something more in line with LLMs natural language, something that can be queried more effeciently buy just using normal language, almost like the way we think normally, we first have a though and then we go through our memory archive.
It's had native memory in the form of per-directory CLAUDE.md files for a while though. Not just 2.0
I still do, but having this allows for strategies like memory decay for older information. It also allows for much more structured searching capabilities, instead of opening file which are less structured.
.md files work great for small projects. But they hit limits:
1. Size - 100KB context.md won't fit in the window 2. No search - Claude reads the whole file every time 3. Manual - You decide what to save, not Claude 4. Static - Doesn't evolve or learn
Recall fixes this: - Semantic search finds relevant memories only - Auto-captures context during conversations - Handles 10k+ memories, retrieves top 5 - Works across multiple projects
Real example: I have 2000 memories. That's 200KB in .md form. Recall retrieves 5 relevant ones = 2KB.
And of course, there's always the option to use both .md for docs, Recall for dynamic learning.
Does that help?
I'm not sure. You don't use a single context.md file, you use multiple and add them when relevant in context. AIs adjust these as you need, so they do "evolve". So what you try to achieve is already solved.
These two videos on using Claude well explain what I mean:
1. Claude Code best practices: https://youtu.be/gv0WHhKelSE
2. Claude Code with Playwright MCP and subagents: https://youtu.be/xOO8Wt_i72s
Yeah that's a solid workflow and honestly simpler than what I built - I think Recall makes sense when you hit the scale where managing multiple .md files becomes tedious (like 50+ conversations across 10 projects), but you're right that for most people your approach works great and is way less complex.
Can't you get recency just from git blame? Editors already show you each source line's last-touch age, even in READMEs, and even though this can get obfuscated (by reformatters, file moves, etc.) it's still a decent indicator.