elfenleid

I've been experimenting with that in the last couple of days. I added to CLAUDE.md a directive on how and when to use recall and he's autoamtically calling the tool for store and fetch

Absolutely! But this is not a replacement of those files, this is a different (better?) way to navigate through those learnings instead of having to read whole files.

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.

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.

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

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

No particular specific reason. I was working with another project that also had redis and decided to start with it. It can be changed to other tool, which one would you recommend?

I think that's a great point. I will experiment with different approaches. I started with redis mostly because it's something I have experience with and was a quick setup win, but having different strategies I think it could make sense.

I think that's a great point really. There is not 1 size fits all, different people will have different strategies that better suit their workflow.

Totally, point taken. I'll dig a bit deeper into that.

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.

Yeah people do that but it doesn't scale, after a while your "restart prompt" is 50KB and won't fit, plus you're stuck copying stuff manually instead of just asking "what did we say about Redis" and getting the relevant bits automatically.

Yeah it still uses context but way more efficiently, instead of injecting a 50KB context.md every time, Recall searches 10k memories and only injects the top 5 relevant ones (maybe 2KB), so you can store way more total knowledge.

Yep! Valkey should work fine.

Recall just uses basic Redis commands - HSET, SADD, ZADD, etc. Nothing fancy.

Valkey is Redis-compatible so all those commands work the same.

I haven't tested it personally but there's no reason it wouldn't work. The Redis client library (ioredis) should connect to Valkey without issues.

If you try it and hit any problems let me know! Would be good to officially support it.

That's a great point! And also works really well for shared context between claude instances, for example, we use that for our business model in the company, all business rules and model is stored as memories in a central redis that the mcp connects to. The way that memories are stored are specific to a folder or global (similar to CLAUDE.md home directiory), but with this approach you can have an external redis where multiple claudes read and write into as a shared almost hive like memory.

I've been using it for a while now, personally. I've found that I have less issues with context, I can easily recall (pun intended) after a context compact, etc.

Totally get what you're saying! Having Claude manually call memory tools mid-conversation does feel intrusive, I agree with that, especially since you need to keep saying Yes to the tool access.

Your approach is actually really interesting, like a background process watching the conversation and deciding what's worth remembering. More passive, less in-your-face.

I thought about this too. The tradeoff I made:

Your approach (judge/watcher): - Pro: Zero interruption to conversation flow - Pro: Can use cheaper model for the judge - Con: Claude doesn't know what's in memory when responding - Con: Memory happens after the fact

Tool-based (current Recall): - Pro: Claude actively uses memory while thinking - Pro: Can retrieve relevant context mid-response - Con: Yeah, it's intrusive sometimes

Honestly both have merit. You could even do both, background judge for auto-capture, tools when Claude needs to look something up.

The Grammarly analogy is spot on. Passive monitoring vs active participation.

Have you built something with the judge pattern? I'd be curious how well it works for deciding what's memorable vs noise.

Maybe Recall needs a "passive mode" option where it just watches and suggests memories instead of Claude actively storing them. That's a cool idea.

Yes I did, I worked on this a while back, before it was availabale I believe. I'll have another check. Thanks for the heads up

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?

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.