[steveklabnik]

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.

[ebcode]

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.

[steveklabnik]

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 :)

[koakuma-chan]

It creates them on its own?

[steveklabnik]

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!

[elfenleid]

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.*

[koakuma-chan]

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...

[steveklabnik]

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!

[elfenleid]

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.

[steveklabnik]

Sorry for the confusion, I was purely commenting about Claude. I have not tried your MCP.

[elfenleid]

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.

[atonse]

It's had native memory in the form of per-directory CLAUDE.md files for a while though. Not just 2.0