mem0 memory storage working too indiscriminately in OpenClaw

[TRON4R]

I installed mem0 locally on my VPS. I installed qdrant: v1.14.0 in a docker (anything further away than v1.13.0 +1 was rejected by mem0) and employed "openai/gpt-4.1-nano" and "openai/text-embedding-3-large" as the storage and embedding intelligence.

So far, so good. But after feeding the current MEMORY.md into its new database (producing 26 memories) and happily exchanging a few prompts with my OpenClaw agent, I checked the mem0 memory and found that it essentially had stored everything from the conversation. So it had grown to 95 memories. Even totally meaningless temporary stuff like current times and dates had been added.
(And on a side note: although I have defined disableHistory: true a memory.db is constantly growing in my workspace folder.)

When I then asked my agent to prune the memory and deleting things that are clearly redundant or of temporary nature, the number of histories went back down to 19.

When I dicussed the whole problem with Opus 4.6, it suggested turning off AutoCapture, because that's basically adding everything to the memory.

I also switched the decision making model from chatgpt-4.1-nano to chatgpt-4.1-mini. But that actually doubled to response times making the wait simply too long (roughly 2 minutes even for simple questions such as "What is 30+15?" and didn't really make a noticeable difference deciding which information is worth to be stored and which to be ignored.

Now I wonder: how practical and useful is the mem0 storage AutoCapture really? Is there a trick to make it a little more selective?
Or is the trick pruning and curating the memory twice a day using a heartbeat for this job?

Because when I asked Opus 4.6 where the advantages of mem0 WITHOUT AutoCapture lie compared to OpenClaw's default memory-core, it actually agreed that there are none. On the contrary, it said that memory-core - when using a modern embedding model such as gemini-embedding-001 - actually applies a hybrid embedding strategy employing both a Vector AND BM25 based search strategy, whereas mem0 only supports vector search (although Qdrant now also supports BM25 full-text-search, but mem0 isn't taking advantage of it [yet?]).

Which leaves me with the odd situation to

• either accept an indiscriminate AutoCapture feature basically throwing litterally everything into the memory and needing to be pruned regularly
• or turn off AutoCapture and then bascially switch a markdown file based hybrid search strategy for a vector only qdrant based search
• or go back to memory-core and its markdown files (which at least have the advantage to be easily read and fine-tuned by a human and will also lead to faster response times)

Or have I fundamentally misunderstood something? How do you deal with the dilemma? Or is there a switch that I have overlooked that increases the hurdle for information to be deemed storage-worthy?

[Nyrok]

The indiscriminate storage problem often comes from the prompt side. When everything arrives as one undifferentiated text blob, mem0 has no clear signal for what's background context vs what's session-specific input.

One pattern that helps: tag different parts of the prompt with explicit semantic roles. A context block marks durable background info, an input block marks transient user-supplied data. Memory extraction logic can then prioritize the context block and deprioritize the input block.

Been building flompt (github.com/Nyrok/flompt) around this structure, 12 semantic block types that make those distinctions explicit before the prompt reaches the model.

[TRON4R]

So my expectation of having some smart system make that distinction automatically and with good reasoning was naive then?