config

[desert peak]

agent facing this issie , how can i set it so agent can restart gateway himself {Gateway restart is disabled in config. I'll continue filling the form using JavaScript to avoid ref instability. Let me fill all fields at once and submit.
I'll restart the browser service and use a direct script to fill and submit the form.}

[dusk mantle]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[blissful trail]

That message is coming from OpenClaw intentionally blocking Gateway restarts by default.

To let the agent restart the Gateway (and to enable the /restart chat command), set this in your openclaw.json:

{
  commands: {
    restart: true
  }
}

Then do one manual restart so the new config is loaded:

openclaw gateway restart

Notes / gotchas:

• This is a security control: once enabled, any authorized sender could potentially trigger restarts. Make sure your channel access control is tight (allowFrom / pairing, and keep commands.useAccessGroups: true).
• Docs reference: https://docs.openclaw.ai/gateway/configuration (see commands.restart) and https://docs.openclaw.ai/gateway (SIGUSR1/in-process restart behavior).

If you paste your openclaw --version + the relevant commands { ... } block (redact tokens), I can sanity-check it.

[desert peak]

give me the command line to update it to true so i dont haver to do itmanually

[blissful trail]

Run:

openclaw config set commands.restart true --json
openclaw gateway restart

(One-liner:)

openclaw config set commands.restart true --json && openclaw gateway restart

Docs: https://docs.openclaw.ai/cli/config and https://docs.openclaw.ai/gateway/configuration (commands.restart).

[desert peak]

command to confirm its set ?

[blissful trail]

openclaw config get commands.restart

If you want to see the whole block:

openclaw config get commands

[desert peak]

command to confirm what memeory my agent is using , i rmember switch to qmd , butnow i still get completions o0n open ai enbedding usage , it shouldnt be writing there anymore but instad using qmd by/tobi , need to verify all this

[blissful trail]

Use the memory CLI — it shows which backend is actually serving recall (builtin vs qmd), plus which embedding provider/model it’s using:

openclaw memory status --json
# or, with probes:
openclaw memory status --deep --json

If you have multiple agents, check the one you care about:

openclaw memory status --deep --agent main --json

What to look for in the JSON:

• status.backend should be "qmd" if QMD is active (otherwise you’ll see "builtin").
• status.provider / status.model will tell you if it’s still using openai embeddings.

If you think you switched to QMD but it’s still not using it, also confirm the config:

openclaw config get memory.backend
openclaw config get memory.qmd

And if needed, this usually explains why it fell back (missing qmd binary / PATH issues):

openclaw memory status --deep --verbose

Docs: https://docs.openclaw.ai/cli/memory and https://docs.openclaw.ai/concepts/memory (QMD backend section).

[desert peak]

agent@agent:~$ openclaw memory status --deep --json
22:03:20 [memory] qmd embed failed (boot): Error: qmd embed timed out after 120000ms
│
◇
[
{
"agentId": "main",
"status": {
"backend": "qmd",
"provider": "qmd",
"model": "qmd",
"requestedProvider": "qmd",
"files": 129,
"chunks": 129,
"dirty": false,
"workspaceDir": "/home/agent/.openclaw/workspace",
"dbPath": "/home/agent/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite",
"sources": [
"memory",
"sessions"
],
"sourceCounts": [
{
"source": "memory",
"files": 7,
"chunks": 7
},
{
"source": "sessions",
"files": 122,
"chunks": 122
}
],
"vector": {
"enabled": true,
"available": true
},
"batch": {
"enabled": false,
"failures": 0,
"limit": 0,
"wait": false,
"concurrency": 0,
"pollIntervalMs": 0,
"timeoutMs": 0
},
"custom": {
"qmd": {
"collections": 4,
"lastUpdateAt": 1770588200041
}
}
},
"embeddingProbe": {
"ok": true
},
"scan": {
"sources": [
{
"source": "memory",
"totalFiles": 4,
"issues": []
},
{
"source": "sessions",
"totalFiles": 122,
"issues": []
}
],
"totalFiles": 126,
"issues": []
}
}
]
agent@agent:~$

[blissful trail]

Your output already confirms you are on QMD:

• status.backend: "qmd"
• status.provider/model: "qmd"
• sources include memory + sessions

So memory_search should not be using OpenAI embeddings anymore on this agent.

That log line is a separate issue:

qmd embed failed (boot): qmd embed timed out after 120000ms

That means the local QMD embed step didn’t finish within 2 minutes on boot (often first-run model downloads, slow disk/CPU, or a lot of session files).

Verify what’s happening (commands)

1. Confirm config is set to QMD:

openclaw config get memory.backend
openclaw config get memory.qmd

2. Force a reindex and watch it:

openclaw memory index --agent main --verbose

3. Warm up QMD manually (this often fixes the boot-time timeout by downloading models once):

STATE_DIR="${OPENCLAW_STATE_DIR:-$HOME/.openclaw}"
export XDG_CONFIG_HOME="$STATE_DIR/agents/main/qmd/xdg-config"
export XDG_CACHE_HOME="$STATE_DIR/agents/main/qmd/xdg-cache"

qmd update
qmd embed
qmd query "test" -c memory-root --json >/dev/null

If you still see OpenAI embedding spend

It’s almost always one of:

• a different agent (or a different Gateway) still using builtin memory with provider: openai
• old usage from before switching
• fallback to builtin memory during a QMD failure window

To confirm no other agent is using OpenAI embeddings:

openclaw memory status --deep --json

(If there were other agents, they’d show up in that array with their own status.provider.)

If you want, paste the last ~30 lines around that “qmd embed timed out” from openclaw logs --follow and I’ll help pinpoint whether it’s just slow first-run downloads vs something stuck.

[desert peak]

agent@agent:~$ openclaw config get memory.backend
openclaw config get memory.qmd

🦞 OpenClaw 2026.2.6-3 (85ed6c7)
I'm not magic—I'm just extremely persistent with retries and coping strategies.

qmd

🦞 OpenClaw 2026.2.6-3 (85ed6c7)
Your task has been queued; your dignity has been deprecated.

{
"command": "qmd",
"includeDefaultMemory": true,
"sessions": {
"enabled": true,
"exportDir": "/home/agent/.openclaw/agents/main/qmd/sessions",
"retentionDays": 30
},
"update": {
"interval": "5m",
"debounceMs": 15000,
"onBoot": true,
"embedInterval": "10m"
},
"limits": {
"maxResults": 6,
"maxSnippetChars": 700,
"maxInjectedChars": 4000,
"timeoutMs": 4000
},
"scope": {
"default": "deny",
"rules": [
{
"action": "allow",
"match": {
"chatType": "direct"
}
}
]
}
}
agent@agent:~$

[blissful trail]

You’re configured correctly — that output proves you’re on QMD now:

• backend: "qmd"
• provider/model: "qmd"
• indexing memory + sessions

So OpenClaw memory search should not be calling OpenAI embeddings going forward.

About qmd embed timed out after 120000ms

That’s a local QMD embed step getting killed after 2 minutes (hardcoded timeout). Common causes: first-run model downloads, slow CPU/disk, or lots of session files.

Best fix: run the embed once manually (no 2‑minute timeout), then future boots are usually fast:

STATE_DIR="${OPENCLAW_STATE_DIR:-$HOME/.openclaw}"
export XDG_CONFIG_HOME="$STATE_DIR/agents/main/qmd/xdg-config"

export XDG_CACHE_HOME="$STATE_DIR/agents/main/qmd/xdg-cache"

cd /home/agent/.openclaw/workspace
qmd update
qmd embed

Reduce the load (optional but recommended)

You’re embedding sessions every 10 minutes + updating every 5 minutes — that’s pretty aggressive.

Examples:

openclaw config set memory.qmd.update.embedInterval "60m"
openclaw config set memory.qmd.sessions.retentionDays 7 --json

openclaw gateway restart

If you want to prove no OpenAI embeddings are being called

Tail logs and look for text-embedding / /embeddings:

openclaw logs --follow | grep -i -E "text-embedding|/embeddings|embedding"

If you still see OpenAI embedding usage after this, it’s almost certainly another Gateway/agent elsewhere still using builtin memory (or old usage showing up delayed in billing).

[desert peak]

whats the pros and cons of this You’re embedding sessions every 10 minutes + updating every 5 minutes — that’s pretty aggressive.
and what chnages if i chnage it to this openclaw config set memory.qmd.update.embedInterval "60m"
openclaw config set memory.qmd.sessions.retentionDays 7 --json

[blissful trail]

What those knobs control:

• memory.qmd.update.interval "5m" = how often OpenClaw runs qmd update (scan files / refresh index metadata, plus session export if enabled).
• memory.qmd.update.embedInterval "10m" (your current) = how often it runs qmd embed (the expensive part: generating/refreshing vectors).
• memory.qmd.sessions.retentionDays 30 (your current) = how many days of session transcripts get exported into QMD and kept searchable.

Pros / cons of your current settings (5m update, 10m embed, 30d sessions)

Pros

• Very “fresh” recall: new chats show up in memory quickly.
• Great if you actively rely on “what did we discuss earlier today?” and want it searchable almost immediately.
• If the machine is fast, it feels snappy/always up to date.

Cons

• More CPU/disk churn (and more chances to hit that qmd embed timed out on boot).
• If you have lots of sessions, qmd embed can be heavy and may overlap with other work.
• More background activity (can matter on small VPS / Raspberry Pi / busy box).

What changes if you switch to:

openclaw config set memory.qmd.update.embedInterval "60m"
openclaw config set memory.qmd.sessions.retentionDays 7 --json

1) embedInterval "60m" (less frequent embeddings)

What you gain

• Much lower load: fewer long embed runs, fewer timeouts.
• More stable gateway startup (less likely to try a big embed right after boot).

What you give up

• New/updated session exports might not be vector-embedded for up to ~1 hour.
  • Practically: memory recall may feel a bit less “instant” for very recent conversations until the next embed run.
  • (QMD can still do BM25/keyword-style retrieval, but the “semantic” quality improves once embeddings are up to date.)

2) sessions.retentionDays 7 (shorter session memory window)

What you gain

• Smaller index, faster updates/embeds, less disk usage.
• Reduced privacy exposure / less old chat content sitting in the QMD store.

What you give up

• You won’t get semantic recall from conversations older than 7 days (unless the info was also written into MEMORY.md / memory/*.md).

My suggested “sane default”

For most people: keep update.interval at 5m (fine), set embedInterval to 60m, and set retentionDays to 7–14. Then put truly durable stuff into MEMORY.md.

If you tell me what hardware this is running on (tiny VPS vs beefy box) and whether you want long-term chat recall, I can suggest a tighter set of values.

[desert peak]

tiny vps CPU usage 100.33% of 2 CPU(s)
Memory usage 84.54% (5.12 GiB of 6.05 GiB)
Host memory usage 5.63 GiB
Bootdisk size 70.00 GiB
and if retention is made 14 days , it means after 14 days it doesnt remember what we spoke about 15 days ago ? ecept its written down in memory md ?

[blissful trail]

On that VPS (2 vCPU, ~6GB RAM, already ~100% CPU / 85% RAM), the “aggressive” part is simply: you’re constantly exporting sessions + reindexing + re-embedding, which competes with the Gateway + model calls.

What’s the tradeoff?

More frequent update/embed (5m / 10m)

• Pros: new chats become searchable in memory fast.
• Cons: lots of background CPU + disk IO; higher chance qmd embed takes >2 min and hits the 120s timeout; can make the whole box feel pegged.

Less frequent embed + shorter retention (60m embed, 7–14d retention)

• Pros: big reduction in background work; fewer timeouts; steadier latency for “real” agent work.
• Cons: “what we talked about 5 minutes ago” might not be semantically searchable until the next embed run (keyword/BM25 may still hit, but vectors/reranking improve once embedded).

Does retentionDays: 14 mean it forgets day 15?

For QMD session memory, yes in practice:

• After ~14 days, the exported session transcripts that QMD indexes get pruned, so memory_search won’t be able to retrieve content from 15+ days ago from sessions.
• Anything you wrote into MEMORY.md / memory/*.md is still indexed (that’s the “durable memory” path), so it remains recallable.

So the workflow becomes:

• “Temporary recall” = last ~14 days of sessions
• “Permanent recall” = write it down in MEMORY.md (or a note file under memory/)

What I’d do for your tiny VPS

Keep sessions indexing (if you like it), but slow it down:

openclaw config set memory.qmd.update.embedInterval "60m"
openclaw config set memory.qmd.sessions.retentionDays 14 --json
openclaw gateway restart

If it’s still heavy, also relax the update cadence (this reduces session export churn too):

openclaw config set memory.qmd.update.interval "30m"
openclaw gateway restart

Then verify impact:

openclaw memory status --deep --json

If you want maximum performance/stability: consider disabling session indexing entirely and rely on MEMORY.md for the important stuff.

[desert peak]

also this might be why my cpu is up , and note its juust here nothing is happening , am i suppose to control c out of here or its suppose to finish itself agent@agent:~$ STATE_DIR="${OPENCLAW_STATE_DIR:-$HOME/.openclaw}"
export XDG_CONFIG_HOME="$STATE_DIR/agents/main/qmd/xdg-config"
export XDG_CACHE_HOME="$STATE_DIR/agents/main/qmd/xdg-cache"

cd /home/agent/.openclaw/workspace
qmd update
qmd embed
Updating 5 collection(s)...

[1/5] memory-root (memory//*.md)
Collection: /home/agent/.openclaw/workspace (memory//*.md)
Indexing: 3/3 ETA: 0s
Indexed: 0 new, 0 updated, 3 unchanged, 0 removed

[2/5] memory-main (MEMORY.md)
Collection: /home/agent/.openclaw/workspace (MEMORY.md)
Indexing: 1/1
Indexed: 0 new, 0 updated, 1 unchanged, 0 removed

[3/5] memory-alt (memory.md)
Collection: /home/agent/.openclaw/workspace (memory.md)
No files found matching pattern.

[4/5] memory-dir (/*.md)
Collection: /home/agent/.openclaw/workspace/memory (/*.md)
Indexing: 3/3 ETA: 0s
Indexed: 0 new, 0 updated, 3 unchanged, 0 removed

[5/5] sessions (/*.md)
Collection: /home/agent/.openclaw/agents/main/qmd/sessions (/*.md)
Indexing: 122/122 ETA: 0s
Indexed: 0 new, 0 updated, 122 unchanged, 0 removed

✓ All collections updated.

Run 'qmd embed' to update embeddings (50 unique hashes need vectors)
Chunking 50 documents by token count...
[node-llama-cpp] The prebuilt binary for platform "linux" "x64" with Vulkan support is not compatible with the current system, falling back to using no GPU
Embedding 50 documents (113 chunks, 195.1 KB)
12 documents split into multiple chunks
Model: embeddinggemma

[blissful trail]

That’s normal — you’re in the middle of qmd embed, and yes: this can absolutely be why your CPU is pegged while “nothing is happening.” It’s generating vectors locally (CPU-only, since it says no compatible Vulkan GPU binary).

Should you Ctrl‑C?

• If you can wait: don’t Ctrl‑C. It should finish on its own and then you’ll get your shell prompt back.
• If you need the CPU back right now: Ctrl‑C is fine. Worst case you just have a partially-updated embedding run; the next qmd embed (manual or scheduled) will continue/redo what’s missing.

How long should it take?

In your output it’s embedding:

• 50 documents → 113 chunks → ~195 KB text
  That’s not huge, but on a tiny VPS with CPU already hot, it can still take a while (plus first-time model warmup). The key is: it’s doing real work; it’s not “stuck” just because there’s no progress bar.

If you want to confirm it’s still running (in another SSH tab)

Safe checks:

ps aux | grep -E "qmd|llama" | grep -v grep
top

How to avoid this hammering your VPS in the future

Once this finishes (or after you abort), reduce how often it runs:

openclaw config set memory.qmd.update.embedInterval "60m"
openclaw config set memory.qmd.update.interval "30m"
openclaw config set memory.qmd.sessions.retentionDays 14 --json
openclaw gateway restart

That keeps QMD on, but stops it from constantly chewing CPU when you’re idle.

[desert peak]

okay so whats the pros and cons of this
If you want maximum performance/stability: consider disabling session indexing entirely and rely on MEMORY.md for the important stuff.

[blissful trail]

Disabling session indexing (memory.qmd.sessions.enabled = false) means QMD will only index your “durable” memory files (MEMORY.md + memory/**/*.md), not the rolling exported chat transcripts.

Pros (on a tiny VPS, these are big)

• Much lower CPU/RAM/disk churn
  No constant session export, no embedding a growing pile of chats.
• Fewer timeouts / fewer background surprises
  That qmd embed timed out after 120000ms is often driven by session volume.
• More predictable performance
  Your agent latency stays steadier because it’s not competing with background embed jobs.
• Cleaner privacy boundary
  Your “memory” becomes explicitly curated notes, not “everything I said in DMs for the last N days.”

Cons (what you give up)

• Less “automatic recall” of past conversations
  If you discussed something in chat and didn’t write it into MEMORY.md (or a memory/*.md note), it likely won’t be retrievable later via memory_search.
• More manual habit required
  You (or the agent) need to actively capture key facts as notes (“remember this: …”) instead of relying on implicit transcript recall.

• Harder to answer “what did we decide last week?” unless it was written down.

What it changes in practice

With session indexing ON: “the bot remembers what we talked about” (within retention window).
With session indexing OFF: “the bot remembers what we wrote down.”

On your VPS specs, I’d lean OFF unless you really value transcript recall.

Commands to disable (and restart)

openclaw config set memory.qmd.sessions.enabled false --json
openclaw gateway restart

Verify:

openclaw config get memory.qmd.sessions
openclaw memory status --deep --json

If you tell me whether you mostly use OpenClaw for quick chats vs long-running projects, I can suggest the best setting (sessions ON with low retention vs OFF).

[desert peak]

i use OpenClaw for quick chats and long-running projects. so need to work out a plan that is effective

[blissful trail]

On a tiny VPS, the “effective” setup is usually a 2‑layer memory strategy:

1. Short-term recall from sessions (good for quick chats, “what did we just say yesterday?”)
2. Durable project notes in MEMORY.md / memory/*.md (good for long-running projects + decisions)

That way you get convenience without letting background embedding jobs melt the box.

Recommended “balanced” plan (for your VPS)

A) Keep session indexing ON, but make it lighter

• Retention: 14 days (enough for quick chats + recent project context)
• Update cadence: 30 minutes (not every 5m)
• Embed cadence: 6 hours (or 12h) instead of every 10m
• Boot behavior: don’t try to embed immediately on boot (avoids the 120s timeout spike)

Commands:

openclaw config set memory.qmd.sessions.enabled true --json
openclaw config set memory.qmd.sessions.retentionDays 14 --json
openclaw config set memory.qmd.update.interval "30m"
openclaw config set memory.qmd.update.embedInterval "6h"
openclaw config set memory.qmd.update.onBoot false --json
openclaw gateway restart

What changes:

• You still “remember” recent chats (last ~14d), but the VPS won’t constantly re-embed.
• Embeddings for very recent chats might lag (up to a few hours), but for most people that’s fine.

B) Make long-running projects “durable” on purpose

For anything you’ll care about in >14 days, write it into a project note file, e.g.

• memory/projects/<project>.md (goals, decisions, links, credentials references, next steps)
• Keep MEMORY.md for global preferences / personal facts / “always true” stuff.

Rule of thumb:

• Sessions = convenience
• memory/*.md = source of truth

If you want it even cheaper (max stability)

Drop retention to 7 days and embed to 12–24h:

openclaw config set memory.qmd.sessions.retentionDays 7 --json
openclaw config set memory.qmd.update.embedInterval "24h"
openclaw gateway restart

How to verify it’s behaving

After a day, check:

openclaw memory status --deep --json

…and if CPU is still pegged “idle”, tail logs to see if QMD is running constantly:

openclaw logs --follow | grep -i qmd

If you tell me roughly how many messages/day and how many active projects you run in parallel, I can suggest whether 6h embedInterval is enough or if you should go 12h/24h.

[desert peak]

at a gola i have at least 4 active projects , and iutside that i use it in chat sessions with free models just to play around and get familair with openclaw functionality , whihc am guessng causes a lot of chun , so we might also have to come up woith hard rulls under sole md for the model to alwayas write to memory md like you said here Make long-running projects “durable” on purpose
For anything you’ll care about in >14 days, write it into a project note file, e.g.
memory/projects/<project>.md (goals, decisions, links, credentials references, next steps)
Keep MEMORY.md for global preferences / personal facts / “always true” stuff.
Rule of thumb:
Sessions = convenience
memory/*.md = source of truth

also not embedding is finshed agent@agent:~$ STATE_DIR="${OPENCLAW_STATE_DIR:-$HOME/.openclaw}"
export XDG_CONFIG_HOME="$STATE_DIR/agents/main/qmd/xdg-config"
export XDG_CACHE_HOME="$STATE_DIR/agents/main/qmd/xdg-cache"

cd /home/agent/.openclaw/workspace
qmd update
qmd embed
Updating 5 collection(s)...

[1/5] memory-root (memory//*.md)
Collection: /home/agent/.openclaw/workspace (memory//*.md)
Indexing: 3/3 ETA: 0s
Indexed: 0 new, 0 updated, 3 unchanged, 0 removed

[2/5] memory-main (MEMORY.md)
Collection: /home/agent/.openclaw/workspace (MEMORY.md)
Indexing: 1/1
Indexed: 0 new, 0 updated, 1 unchanged, 0 removed

[3/5] memory-alt (memory.md)
Collection: /home/agent/.openclaw/workspace (memory.md)
No files found matching pattern.

[4/5] memory-dir (/*.md)
Collection: /home/agent/.openclaw/workspace/memory (/*.md)
Indexing: 3/3 ETA: 0s
Indexed: 0 new, 0 updated, 3 unchanged, 0 removed

[5/5] sessions (/*.md)
Collection: /home/agent/.openclaw/agents/main/qmd/sessions (/*.md)
Indexing: 122/122 ETA: 0s
Indexed: 0 new, 0 updated, 122 unchanged, 0 removed

✓ All collections updated.

Run 'qmd embed' to update embeddings (50 unique hashes need vectors)
Chunking 50 documents by token count...
[node-llama-cpp] The prebuilt binary for platform "linux" "x64" with Vulkan support is not compatible with the current system, falling back to using no GPU
Embedding 50 documents (113 chunks, 195.1 KB)
12 documents split into multiple chunks
Model: embeddinggemma

████████████░░░░░░░░░░░░░░░░░░ 38% 32/113 144.01396971479747 B/s ETA 14m 13s████████████████████░░░░░░░░░░ 68% 64/113 140.44431898142477 B/s ETA 7m 39s ███████████████████████████░░░ 91% 96/113 136.60853176977386 B/s ETA 2m 5s ██████████████████████████████ 100% 0s

✓ Done! Embedded 113 chunks from 50 documents in 24m 37s (135.24409235560972 B/s)
agent@agent:~/.openclaw/workspace$

[blissful trail]

On a tiny VPS + lots of “play” chats, the key is: session indexing scales with how many session files you create, and it’ll keep growing. So you want a setup where:

• Quick chats rely mostly on the current chat session history (no extra indexing needed).
• Projects get promoted into durable notes (MEMORY.md / memory/projects/*.md) so they survive weeks/months and stay searchable cheaply.

My recommended plan (effective + VPS-friendly)

1) Turn OFF session indexing (biggest CPU win)

You’ll still have normal chat continuity in the same session, but you stop QMD from continuously exporting/indexing tons of transcripts.

openclaw config set memory.qmd.sessions.enabled false --json
openclaw gateway restart

Then keep QMD for memory files only (cheap), and rely on curated project notes for long-running stuff.

2) Slow down QMD background work (avoid idle CPU spikes)

openclaw config set memory.qmd.update.interval "30m"
openclaw config set memory.qmd.update.embedInterval "6h"
openclaw config set memory.qmd.update.onBoot false --json
openclaw gateway restart

(With sessions disabled, even 24h embedInterval is totally fine if you want it quieter.)

“Hard rules” for SOUL.md (copy/paste)

Add something like this to the agent’s SOUL.md (or AGENTS.md) so it consistently writes durable project state:

## Memory protocol (must follow)

- Memory source of truth is Markdown files in the workspace.
- For long-running work, maintain per-project files:
  - memory/projects/<project>.md
- After any work that changes project state (decision, plan update, new requirement, link, next steps):
  1) Update the relevant memory/projects/<project>.md (keep it concise).
  2) Append a short note to memory/YYYY-MM-DD.md (today’s log).

- Do NOT write memory for casual “play” chats unless the user explicitly says
  “remember this”, “save this”, or “add to project memory”.

- Never store secrets/tokens in memory. Store references instead
  (e.g. “API key in 1Password item: X”).

Suggested per-project note template

Create memory/projects/<project>.md with:

# Project: <name>

## Goal
## Current status
## Decisions (date-stamped)
## Next steps (actionable)
## Links / resources
## Open questions / risks

Why this fits your usage (4 projects + lots of experimentation)

• Your “play around with free models” won’t balloon the QMD sessions collection anymore.
• Your real projects stay durable and searchable without hammering CPU.

If you want, paste your current openclaw config get memory.qmd and I’ll suggest exact intervals (6h vs 12h vs 24h) based on how often you actually want project notes to become searchable.

Yep — that output is the smoking gun: qmd embed took ~25 minutes on your tiny VPS. That’s exactly why the Gateway’s automatic boot embed keeps failing with:

• qmd embed timed out after 120000ms (2 minutes)

So: you did the right thing letting it finish. Now you really don’t want this running every 10 minutes in the background, because it’ll basically keep your CPU pinned whenever it decides it needs vectors.

What to do next (so your VPS stops melting)

Option A (recommended for your setup): keep sessions indexing, but make it “cheap”

This keeps “recent chat recall” but reduces churn a lot:

openclaw config set memory.qmd.update.onBoot false --json
openclaw config set memory.qmd.update.interval "30m"
openclaw config set memory.qmd.update.embedInterval "12h"
openclaw config set memory.qmd.sessions.retentionDays 14 --json

openclaw gateway restart

Option B (max stability): disable session indexing entirely

If your “play chats” are generating tons of sessions, this is the biggest win:

openclaw config set memory.qmd.sessions.enabled false --json
openclaw gateway restart

(Then the durable stuff lives in MEMORY.md + memory/*.md only.)

Verify it’s calm + still on QMD

After changes:

openclaw memory status --deep --json

You want to see backend: "qmd" and no new embed timed out warnings.

“Hard rule” so projects become durable (without saving play-chatter)

Add this to your agent’s SOUL.md:

• Maintain memory/projects/<project>.md for each active project (goals, decisions, next steps).
• Only write durable memory when:
  • user says “remember/save”, or
  • you make a project decision / update plan / capture a link, or
  • you finish a task that changes project state.
• Do not store random play-chat in memory.

If you tell me what surfaces you use for “play” (same Discord channel vs DMs vs Telegram), I can suggest a clean split (either by tuning memory rules, or by using a separate “play” agent so it can’t pollute your project memory at all).

[desert peak]

i have gone with this openclaw config set memory.qmd.sessions.enabled true --json
openclaw config set memory.qmd.sessions.retentionDays 14 --json
openclaw config set memory.qmd.update.interval "30m"
openclaw config set memory.qmd.update.embedInterval "6h"
openclaw config set memory.qmd.update.onBoot false --json
openclaw gateway restart but will also still need to md rules to enforce others

[blissful trail]

Those settings are a good “tiny VPS” compromise. With:

• onBoot=false → no more guaranteed 2‑minute boot timeout spam
• interval=30m → fewer session exports / scans
• embedInterval=6h → embeddings run rarely enough to not peg CPU all day
• retentionDays=14 → keeps recent chat recall without the index growing forever

Quick sanity checks after the restart:

openclaw memory status --deep --json
openclaw logs --follow | grep -i qmd

The “MD rules” part (what to put in SOUL.md / AGENTS.md)

Add a Memory Protocol section that makes two things explicit:

1. what is allowed to be written (durable project facts), and
2. what is forbidden (play chatter, secrets).

Copy/paste template:

## Memory protocol (must follow)

Memory source-of-truth is Markdown in the workspace.

### What to write
- Long-running projects: maintain `memory/projects/<project>.md`
  - Goal, current status, decisions (dated), next steps, links
- Durable personal/system prefs: `MEMORY.md`
- Daily scratchpad / running context: `memory/YYYY-MM-DD.md` (append-only)

### When to write
Write/update project memory when:
- a decision is made
- requirements change
- a plan is updated
- you finish a task that changes project state
- the user says “remember / save this / add this to project notes”

### What NOT to write
- Do not store random “play” chats or experiments.
- Do not store secrets/tokens/credentials. Store references instead
  (e.g. “key stored in <vault>, item name …”).
- If unsure whether something is durable, ask before writing.

### How to write

- Keep entries concise.
- Prefer bullets + a “Next steps” list.
- Always update the correct project file (do not mix projects).

Create the project files once (4 active projects)

mkdir -p memory/projects
# create one file per project, e.g.
nano memory/projects/project-a.md

Suggested structure for each memory/projects/<project>.md:

# Project: <name>
## Goal
## Status
## Decisions (dated)
## Next steps
## Links

If “play” is still causing churn

The cleanest separation is a separate agent/workspace just for experimentation, so it can’t pollute project memory at all (multi-agent routing). Doc: https://docs.openclaw.ai/concepts/multi-agent

If you tell me where “play” happens (same Discord channel vs DMs vs Telegram), I can suggest the simplest binding split.

[desert peak]

sanity check 026-02-08T23:01:03.467Z info gateway/reload {"subsystem":"gateway/reload"} config change detected; evaluating reload (meta.lastTouchedAt, memory.qmd.update.interval, memory.qmd.scope.rules)
2026-02-08T23:01:03.469Z warn gateway/reload {"subsystem":"gateway/reload"} config change requires gateway restart (meta.lastTouchedAt, memory.qmd.update.interval, memory.qmd.scope.rules)
2026-02-08T23:01:06.564Z info Updated memory.qmd.update.embedInterval. Restart the gateway to apply.
2026-02-08T23:01:07.076Z info gateway/reload {"subsystem":"gateway/reload"} config change detected; evaluating reload (meta.lastTouchedAt, memory.qmd.update.embedInterval, memory.qmd.scope.rules)
2026-02-08T23:01:07.077Z warn gateway/reload {"subsystem":"gateway/reload"} config change requires gateway restart (meta.lastTouchedAt, memory.qmd.update.embedInterval, memory.qmd.scope.rules)
2026-02-08T23:01:10.006Z info Updated memory.qmd.update.onBoot. Restart the gateway to apply.
2026-02-08T23:01:10.525Z info gateway/reload {"subsystem":"gateway/reload"} config change detected; evaluating reload (meta.lastTouchedAt, memory.qmd.update.onBoot, memory.qmd.scope.rules)
Log tail truncated (increase --max-bytes).

[blissful trail]

Those log lines look normal/expected.

What’s happening:

• Every openclaw config set ... write touches the config file (meta.lastTouchedAt), so the Gateway’s hot-reload watcher wakes up.
• For memory.qmd.update.* (and apparently memory.qmd.scope.rules), the reload system is saying: “I can’t hot-apply this safely; you need a full gateway restart.”
• The “Updated … Restart the gateway to apply.” lines are just confirming the config file was written successfully.

So the sanity check is simply: did the restart actually happen after the last change?

Confirm the Gateway restarted and is now running with the new config

Run:

openclaw gateway status
openclaw config get memory.qmd.update

openclaw config get memory.qmd.sessions
openclaw memory status --deep --json

If openclaw config get memory.qmd.update shows your 30m / 6h / onBoot=false, you’re good.

If you still keep seeing “config change requires gateway restart” repeatedly after restarting

That usually means something is continuing to rewrite the config (or you’re still in the middle of applying multiple config sets). In that case, paste:

• openclaw gateway status
• the next ~30 lines of openclaw logs --follow around another reload warning

…and we can pinpoint what’s touching memory.qmd.scope.rules / triggering the reload loop.

[desert peak]

agent@agent:~$ openclaw memory status --deep --json
openclaw logs --follow | grep -i qmd
│
◇
[
{
"agentId": "main",
"status": {
"backend": "qmd",
"provider": "qmd",
"model": "qmd",
"requestedProvider": "qmd",
"files": 129,
"chunks": 129,
"dirty": false,
"workspaceDir": "/home/agent/.openclaw/workspace",
"dbPath": "/home/agent/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite",
"sources": [
"memory",
"sessions"
],
"sourceCounts": [
{
"source": "memory",
"files": 7,
"chunks": 7
},
{
"source": "sessions",
"files": 122,
"chunks": 122
}
],
"vector": {
"enabled": true,
"available": true
},
"batch": {
"enabled": false,
"failures": 0,
"limit": 0,
"wait": false,
"concurrency": 0,
"pollIntervalMs": 0,
"timeoutMs": 0
},
"custom": {
"qmd": {
"collections": 4,
"lastUpdateAt": null
}
}
},
"embeddingProbe": {
"ok": true
},
"scan": {
"sources": [
{
"source": "memory",
"totalFiles": 4,
"issues": []
},
{
"source": "sessions",
"totalFiles": 122,
"issues": []
}
],
"totalFiles": 126,
"issues": []
}
}

[blissful trail]

Looks good.

From openclaw memory status --deep --json:

• backend: "qmd" ✅ (you’re on QMD)
• sources: ["memory","sessions"] ✅ (session indexing is enabled)
• dirty: false ✅ (index isn’t pending/rebuild)
• embeddingProbe.ok: true ✅

The only “odd” looking field is:

• custom.qmd.lastUpdateAt: null

That’s expected with your settings because you set:

• memory.qmd.update.onBoot = false

So the gateway won’t run a QMD update at startup, and it also hasn’t hit the first scheduled update.interval tick yet (30m). After ~30 minutes (or the next time a memory update runs), lastUpdateAt should become a timestamp.

Quick confirm your config is actually what you think

openclaw config get memory.qmd.update
openclaw config get memory.qmd.sessions

If you want to see QMD activity without “follow” blocking your shell

Run a one-shot tail + filter:

openclaw logs --plain --limit 500 --max-bytes 500000 | grep -i qmd | tail -n 50

(--follow is fine too, just remember it will sit there until you Ctrl+C.)

One thing to watch

Even with onBoot=false, the first scheduled update (at ~30m) may run qmd embed if there are new hashes needing vectors. Since you just completed a full manual embed, it should be quick unless new sessions got exported/changed in the meantime. If CPU spikes again around that 30m mark, bump embedInterval up (12h/24h) or reduce session retention.

[silent folio]

@blissful trail what's a QMD update? is that needed? is memory.qmd.sessions.enabled = true the meta? like whats the point of qmd if i dont do that?