#Better memory

35 messages · Page 1 of 1 (latest)

crisp elm
#

I was checking videos about openclaw memory and i saw different types of things people used. For example QMD, mem0, memory wiki, obsidiant vault, losless claw and such. What are the uses for them? How does ot work and what do you recommend? I currently have qmd but i want to further expand my knowledge and actually learn what each one does.

unique nexusBOT
#

Short version: these are different layers, not all the same thing.

What each one is

  • Builtin memory

    • OpenClaw default.
    • Stores memory in Markdown (MEMORY.md, memory/YYYY-MM-DD.md) and indexes it in SQLite.
    • Best if you want simple, official, low-maintenance.

  • QMD

    • Memory backend/search engine.
    • Better recall than builtin for many setups: BM25 + vectors + reranking + query expansion.
    • Can also index extra folders and session transcripts.
    • Best if you want local-first, better search, and broader indexing.

  • mem0

    • Separate long-term memory plugin/service.
#

  • Watches chats, extracts facts automatically, recalls them later.

    • More “AI memory product” style than “Markdown workspace” style.
    • Best if you want automatic cross-session fact memory and don’t mind extra moving parts.

  • memory-wiki

    • Knowledge layer on top of memory, not a replacement for memory itself.
    • Turns durable memory into structured wiki pages with claims, evidence, contradictions, dashboards.
    • Best if you want memory to feel like a maintained knowledge base, not just notes.

  • Obsidian vault

    • Not really a memory engine by itself.
    • It’s the human-facing note workspace.
    • Usually paired with memory-wiki, or indexed by QMD, so you can browse/edit memory nicely.

  • Lossless Claw

    • Not memory, this is a context engine.
    • It improves how conversation context is compacted/summarized so less gets lost in long chats.
#
  • Best if your problem is context-window loss, not long-term memory storage.

The mental model

Think of it like this:

  • Memory backend: builtin, QMD, mem0
  • Knowledge organization layer: memory-wiki
  • Human UI/editor: Obsidian
  • Live context management: Lossless Claw

What I’d recommend

Since you already have QMD, I’d usually suggest:

  1. Keep QMD
  2. Add memory-wiki if you want cleaner long-term organization
#
  1. Add Obsidian only if you want to actually browse/edit the vault yourself
  2. Use Lossless Claw only if long conversations are getting compacted badly
  3. Try mem0 only if you specifically want automatic fact extraction/recall across sessions and are okay with a more plugin/service-style setup

My practical recommendation

For most people, the sweet spot is:

  • QMD + memory-wiki
  • optional Obsidian
  • Lossless Claw only if needed

That gives you:

  • strong recall
  • local-first behavior
  • structured long-term knowledge
  • a nice human-readable vault if you want it
crisp elm
#

What do you mean by local-only

unique nexusBOT
#

I mean the memory part stays on your machine.

So, for memory:

  • Local-only = notes, indexes, embeddings/search data stay on your PC/server
  • Not local-only = memory gets sent to some outside service/API

Example

If you use:

  • QMD → mostly local-only memory
  • memory-wiki → local files
  • Obsidian vault → local files
  • Lossless Claw → local context handling

But if you use:

#
  • mem0 cloud/platform mode
  • Honcho hosted

then your memory is being managed by an external service.

Important distinction

You can have:

  • local-only memory
  • but still use Claude / GPT / Gemini as your main chat model

That means:

  • memory stays local
  • replies still come from a cloud model

If you want fully local, then both of these are local:

#
  1. memory system
  2. main model

In practice

  • QMD + memory-wiki + Obsidian = very local-first
  • mem0 = more service-style memory, often less local depending on setup

So when I said “local-only”, I meant “your memory system doesn’t depend on a hosted memory provider.”

If you want, I can break it down as:

  • fully local
  • hybrid
  • cloud memory
    with examples for each.
crisp elm
#

I want local only since it sounds more secure, i did hear that mem0 has a none cloid version, also what about dreaming?

unique nexusBOT
#

Yeah, if local-only is your goal, I’d lean toward:

  • QMD for recall/search
  • memory-wiki if you want more structured knowledge
  • Obsidian only if you want a nice human-facing vault
  • Dreaming if you want auto-consolidation of important stuff into long-term memory

About mem0 non-cloud

From the mem0 repo, yes, it does have an open-source mode.
But here’s the important catch:

“mem0 open-source” does not automatically mean fully local.

It depends on what you plug into it:

  • local vector store? good
  • local embedder? good
  • local LLM? good
#
  • OpenAI/GPT for extraction or embeddings? then it’s not fully local anymore

So mem0 can be local-ish or fully local, but only if the whole stack is configured that way.

About dreaming

Dreaming is OpenClaw’s background memory consolidation system.

What it does:

  • looks at short-term memory signals
  • finds recurring/useful patterns
  • promotes the good stuff into MEMORY.md
  • writes human-readable summaries into DREAMS.md

Important bits:

  • it is opt-in
  • it is experimental
  • only the deep phase writes durable memory to MEMORY.md
#

So dreaming is less “store everything forever” and more:

“figure out what is actually worth remembering long-term”

Does dreaming make sense with QMD?

Yes, that’s actually a pretty sensible combo.

  • QMD = strong local search/recall
  • Dreaming = long-term consolidation
  • memory-wiki = organized knowledge layer

That’s a nice local-first setup.

What I’d recommend for you

If you want secure + local + practical:

  1. Keep QMD
  2. Try Dreaming
#
  1. Add memory-wiki later if you want a cleaner knowledge system
  2. Add Obsidian only if you want to browse/edit memory visually
  3. Only move to mem0 if you specifically want its style of automatic memory extraction and are willing to tune the whole stack

So honestly, for your goal, I would not rush away from QMD. You’re already on one of the better local-first options.

Docs:

If you want, I can next give you a “best local-only stack” in plain English, like:

  • simplest
  • best quality
  • best with Obsidian
crisp elm
#

I think i told my opemclaw to use qmd as the embedding

unique nexusBOT
#

Close, but QMD is not the embedding provider.

It’s more like the memory/search backend.

The difference

  • Embedding provider = the thing that turns text into vectors
  • QMD = the engine that manages search, reranking, query expansion, indexing, etc.

So in OpenClaw terms:

  • memory.backend = "qmd" → use QMD
  • agents.defaults.memorySearch.provider = "openai" | "gemini" | "local" | ... → builtin memory embedding provider

If you switched to QMD backend, then QMD handles its own embedding/rerank/generation side internally.

With QMD, model overrides usually happen via env vars

#

Like:

  • QMD_EMBED_MODEL
  • QMD_RERANK_MODEL
  • QMD_GENERATE_MODEL

So if you said “use QMD as embedding”, the more correct wording is probably:

“I set OpenClaw to use QMD as the memory backend.”

Easy mental model

  • Builtin memory: OpenClaw does embeddings/search itself
  • QMD: OpenClaw hands memory search off to QMD

Docs:

crisp elm
#

How would i go about correctly updating openclaw without breaking it since i tried it before and it broke my memory. Apparently i found a video saying run openclaw doctor update first so that it installs dependencoes then you can update

unique nexusBOT
#

First, what does openclaw --version show?

Version mismatch causes a lot of weirdness, and the exact update path can depend on how you installed it.

That said, the normal safe flow is not openclaw doctor update.
It sounds like that video mixed two things together.

Recommended safe update flow

  1. Back up your memory files first

    • your workspace
    • MEMORY.md
    • memory/
    • DREAMS.md if you use dreaming
    • your config

  2. Check current health

# 
   openclaw status

  1. Preview the update

    openclaw update --dry-run

  2. Do the actual update

    openclaw update

  3. Verify after

# 
   openclaw doctor
   openclaw gateway restart
   openclaw health

Important bit

Per the docs, openclaw update already:

  • detects install type
  • fetches the latest version
  • runs openclaw doctor
  • restarts the gateway

So doctor is part of the update story already.

#

If memory looks “broken” after updating

A lot of the time the memory files are still there, but the index/search side got out of sync.

Then check:

openclaw memory status
openclaw memory index --force

That can fix recall/search without meaning your actual memory files were lost.

My advice

  • use plain openclaw update
  • avoid weird/manual update sequences from random videos
#
  • always keep a backup of the workspace before updating
  • if you use QMD, verify memory/search after the update, not just chat replies

Docs:

If you paste:

  • openclaw --version
  • how you installed it (npm, installer, git/source, docker, etc.)

I can tell you the safest exact update workflow for your setup.

crisp elm
#

I saw that actice memory is also a thing

unique nexusBOT
#

Yep, Active Memory is another piece, but it’s a different kind of piece than QMD or mem0.

What Active Memory is

Active Memory is basically a pre-reply memory recall step.

Before OpenClaw answers, it does a quick memory pass and asks:

“Is there anything relevant I should remember right now before replying?”

If it finds something useful, it injects a short memory summary into the prompt for that reply.

So it is not

  • not a memory database
  • not a backend like QMD
  • not a knowledge vault like memory-wiki
  • not a context engine like Lossless Claw
#

It’s more like a memory assistant sitting in front of the main reply.

How it fits with the others

  • QMD = where/search-how memory is retrieved
  • memory-wiki = organized knowledge layer
  • Active Memory = automatically checks memory before replying
  • Lossless Claw = manages long chat context
  • Dreaming = promotes good short-term memories into long-term memory

Practical example

Without Active Memory:

  • the agent only remembers if it naturally decides to search memory, or if you ask it to

With Active Memory:

  • it proactively does a quick recall pass first, so replies can feel more natural
#

Should you use it?

If you already have QMD, Active Memory can be a nice add-on.
The combo is basically:

  • QMD finds stuff well
  • Active Memory makes that recall happen automatically before replies

My recommendation

For your setup, I’d think of it like this:

  1. QMD first
  2. Dreaming second
  3. Active Memory third
  4. memory-wiki / Obsidian if you want better organization and browsing
#

Reason: Active Memory is nice, but it works best after your base memory setup already works well.

One important caveat for “local-only”

Active Memory itself uses a model to do that recall/summarize step.

So if:

  • your session model is cloud, or
  • Active Memory fallback model is cloud

then that part is not fully local

So for a truly local-only setup, you’d want:

  • local memory backend
  • local main model
  • local Active Memory model too
crisp elm
#

How should i tell my ai to setul these memory improvements

unique nexusBOT
#

Best way is to be very specific.

Don’t say:

“improve my memory setup”

Say something like:

I’m using OpenClaw with QMD and I want a local-only memory setup.
Keep QMD as the memory backend.
Add memory improvements one at a time and do not use cloud memory services.
First inspect my current config and tell me what I already have.
Then propose the smallest safe changes for:

  1. dreaming
  2. active memory
  3. memory-wiki
  4. optional Obsidian support
#

Before editing anything:

  • show me my current openclaw --version
  • show me how OpenClaw was installed
  • back up my config and memory files
  • explain each change in plain English
    After each change, verify with:
  • openclaw doctor
  • openclaw status
  • openclaw memory status
  • a test memory search
    Don’t do all changes at once. Stop after each step and confirm it works.

Even better prompt for your exact goal

Help me build a local-first OpenClaw memory stack.
I want to keep QMD.
I want to understand and optionally enable:

#
  • Dreaming for memory consolidation
  • Active Memory for proactive recall before replies
  • memory-wiki for structured knowledge
  • Obsidian only as a human-facing vault, if useful

Constraints:

  • local-only if possible
  • no mem0 cloud / no hosted memory service
  • do not replace QMD unless you explain why
  • make reversible changes
  • show diffs before editing config

Start by checking:

  • openclaw --version
  • install method
  • current memory config
  • whether QMD is actually active