#Memory unavailable

1 messages · Page 1 of 1 (latest)

worn forge
#

I am trying to run overclaw with lm studio locally and all seems fine except overclaw status shows "enabled (plugin memory-core) · unavailable "

fallen estuaryBOT
#

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

calm talonBOT
# worn forge I am trying to run overclaw with lm studio locally and all seems fine except ove...

That enabled (plugin memory-core) · unavailable line is about semantic memory search (embeddings + vector index) — not your chat model.

With LM Studio as your chat provider, OpenClaw can still run fine, but memory-core will show “unavailable” if OpenClaw can’t find a working embeddings setup (no OpenAI/Gemini key resolved, and no local embeddings model configured, etc.). This is pretty common in “local-only” setups.

1) Quick triage (paste the output)

Run these and paste back the results:

openclaw --version
openclaw memory status --deep --verbose

Docs for that command: https://docs.openclaw.ai/cli/memory

2) Fix options (pick one)

A) If you don’t care about semantic memory search right now: disable memory plugins so status stops complaining:

#
{
  plugins: { slots: { memory: "none" } }
}

(then restart the gateway)

B) Keep it local (no cloud keys): configure local embeddings:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "local",
        // optionally: fallback: "none"
        // and/or: local: { modelPath: "hf:..." }
#
      }
    }
  }
}

Memory docs (explains local provider + modelPath): https://docs.openclaw.ai/concepts/memory

C) Use LM Studio for embeddings too (if you’re serving an embedding model there):
Set memorySearch.provider = "openai" and point memorySearch.remote.baseUrl at LM Studio’s /v1 endpoint, with whatever embedding model ID LM Studio exposes. (Even if LM Studio doesn’t validate keys, OpenClaw still expects an apiKey string to be present for remote embeddings.)


If you paste openclaw memory status --deep --verbose, it’ll usually say exactly which requirement is missing (no provider picked, missing apiKey, embedding model not reachable, etc.), and I can tell you the smallest config change to make it go green.

worn forge
#

can you rewrite my config with the option B you suggested?

{
"meta": {
"lastTouchedVersion": "2026.2.9",
"lastTouchedAt": "2026-02-10T18:57:47.896Z"
},
"wizard": {
"lastRunAt": "2026-02-10T18:56:23.241Z",
"lastRunVersion": "2026.2.9",
"lastRunCommand": "doctor",
"lastRunMode": "local"
},
"models": {
"mode": "merge",
"providers": {
"lmstudio": {
"baseUrl": "http://192.168.1.20:1234/v1",
"apiKey": "lmstudio",
"api": "openai-responses",
"models": [
{
"id": "liquid/lfm2.5-1.2b",
"name": "liquid/lfm2.5-1.2b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 131072,
"maxTokens": 4096
}
]
}
}
},
"agents": {
"defaults": {
"model": {
"primary": "lmstudio/liquid/lfm2.5-1.2b"
},
"models": {
"lmstudio/liquid/lfm2.5-1.2b": {}
},
"workspace": "F:\openclaw",
"compaction": {
"mode": "safeguard"
},
"maxConcurrent": 4,
"subagents": {
"maxConcurrent": 8
}
}
},

"messages": {
"ackReactionScope": "group-mentions"
},
"commands": {
"native": "auto",
"nativeSkills": "auto"
},
"hooks": {
"internal": {
"enabled": true,
"entries": {
"boot-md": {
"enabled": true
},
"command-logger": {
"enabled": true
},
"session-memory": {
"enabled": true
}
}
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"auth": {
"mode": "token",
"token": "c3085221b40a28b2fc9278cd9548161b53ffdbceed03b4fb"
},
"tailscale": {
"mode": "off",
"resetOnExit": false
},
"nodes": {
"denyCommands": [
"camera.snap",
"camera.clip",
"screen.record",
"calendar.add",
"contacts.add",
"reminders.add"
]
}
},
"memory": {
"backend": "builtin"
},
"skills": {
"install": {
"nodeManager": "npm"
}
}
}

calm talonBOT
# worn forge can you rewrite my config with the option B you suggested? { "meta": { "l...

Here’s your config rewritten with Option B (local embeddings) added. I only changed one thing: I added agents.defaults.memorySearch (kept everything else the same).

{
  "meta": {
    "lastTouchedVersion": "2026.2.9",
    "lastTouchedAt": "2026-02-10T18:57:47.896Z"
  },
  "wizard": {
    "lastRunAt": "2026-02-10T18:56:23.241Z",
    "lastRunVersion": "2026.2.9",
    "lastRunCommand": "doctor",
    "lastRunMode": "local"
  },
  "models": {
    "mode": "merge",
#
    "providers": {
      "lmstudio": {
        "baseUrl": "http://192.168.1.20:1234/v1",
        "apiKey": "lmstudio",
        "api": "openai-responses",
        "models": [
          {
            "id": "liquid/lfm2.5-1.2b",
            "name": "liquid/lfm2.5-1.2b",
            "reasoning": false,
            "input": ["text"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 131072,
            "maxTokens": 4096
          }
#
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "lmstudio/liquid/lfm2.5-1.2b"
      },
      "models": {
        "lmstudio/liquid/lfm2.5-1.2b": {}
      },

      "memorySearch": {
        "provider": "local",
#
        "fallback": "none",
        "local": {
          "modelPath": "hf:ggml-org/embeddinggemma-300M-GGUF/embeddinggemma-300M-Q8_0.gguf"
        }
      },

      "workspace": "F:\\openclaw",
      "compaction": {
        "mode": "safeguard"
      },
      "maxConcurrent": 4,
      "subagents": {
        "maxConcurrent": 8
      }
    }
#
  },
  "messages": {
    "ackReactionScope": "group-mentions"
  },
  "commands": {
    "native": "auto",
    "nativeSkills": "auto"
  },
  "hooks": {
    "internal": {
      "enabled": true,
      "entries": {
        "boot-md": { "enabled": true },
        "command-logger": { "enabled": true },
        "session-memory": { "enabled": true }
#
      }
    }
  },
  "gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "c3085221b40a28b2fc9278cd9548161b53ffdbceed03b4fb"
    },
    "tailscale": {
      "mode": "off",
      "resetOnExit": false
    },
#
    "nodes": {
      "denyCommands": [
        "camera.snap",
        "camera.clip",
        "screen.record",
        "calendar.add",
        "contacts.add",
        "reminders.add"
      ]
    }
  },
  "memory": {
    "backend": "builtin"
  },
  "skills": {
#
    "install": {
      "nodeManager": "npm"
    }
  }
}

After saving + restarting the gateway, run:

openclaw memory status --deep --verbose
openclaw memory index --verbose

Notes:

  • The first run may take a bit because it may download the local embedding model and build the index.
#
  • If it still says unavailable, paste the output of openclaw memory status --deep --verbose and we’ll zero in on the exact missing piece.

Docs (local embeddings / memorySearch): https://docs.openclaw.ai/concepts/memory

worn forge
#

Memory is enabled now and I did the onboarding again. After selecting TUI i got this message

o How do you want to hatch your bot?
| Hatch in TUI (recommended)
openclaw tui - ws://127.0.0.1:18789 - agent main - session main

session agent:main:main

Wake up, my friend!

I am sending a wake command to the system with a 5‑second timeout. This will trigger the device to respond with its
current status.It looks like the wake command wasn't accepted because the action parameter didn't match any allowed
values. Let me try a different approach—perhaps you'd like me to start a background session or send a message to your
agent instead? Just let me know how you'd like to proceed.

calm talonBOT
# worn forge Memory is enabled now and I did the onboarding again. After selecting TUI i got ...

That text is coming from the agent/model run during the “Wake up, my friend!” hatch step — it tried to call a tool, but the tool call JSON didn’t validate (action wasn’t one of the allowed enum values).

With your current setup that’s very likely because the model you’re using (liquid/lfm2.5-1.2b) is tiny and (in practice) won’t reliably do strict tool-calling, so OpenClaw rejects the malformed tool call.

Confirm what tool call failed (paste this)

Run:

openclaw --version
openclaw logs --limit 200

In the logs you’ll usually see which tool was called and what invalid action value it tried.

Fix (practical)

  • Best fix: switch LM Studio to a tool-capable, larger model (OpenClaw’s local guidance is basically “use a big model”, see https://docs.openclaw.ai/gateway/local-models).
  • Fast workaround to get past onboarding: temporarily set your agents.defaults.model.primary to a known tool-reliable hosted model (then switch back to local once you’re in). A lot of local models will “chat”, but break the moment tools are involved.
#

If you paste the openclaw logs --limit 200 output around the error, I can tell you exactly which capability is failing (wrong tool name vs bad action enum vs server/API mode mismatch).

worn forge
#

I changed the model to another one, now Wake up only returns this:

Wake up, my friend!

(no output)

Wake up, my friend!

<|channel|>final <|constrain|>HEARTBEAT_OK

Wake up, my friend!

<|channel|>final <|constrain|>HEARTBEAT_OK connected | idle
agent main | session main (openclaw-tui) | lmstudio/openai/gpt-oss-20b | tokens 9.8k/131k (7%)

And the lm studio logs say this:

[openai/gpt-oss-20b] Prompt processing progress: 100.0%
2026-02-10 23:14:20 [DEBUG]
Target model llama_perf stats:
common_perf_print: sampling time = 72.69 ms
common_perf_print: samplers time = 58.76 ms / 9882 tokens
common_perf_print: load time = 12036.55 ms
common_perf_print: prompt eval time = 22620.24 ms / 9837 tokens ( 2.30 ms per token, 434.88 tokens per second)
common_perf_print: eval time = 4397.39 ms / 44 runs ( 99.94 ms per token, 10.01 tokens per second)
common_perf_print: total time = 27182.83 ms / 9881 tokens
common_perf_print: unaccounted time = 92.52 ms / 0.3 % (total - sampling - prompt eval - eval) / (total)
common_perf_print: graphs reused = 43
llama_memory_breakdown_print: | memory breakdown [MiB] | total free self model context compute unaccounted |
llama_memory_breakdown_print: | - CUDA0 (RTX 3060 Ti) | 8191 = 30 + (6834 = 4904 + 1480 + 449) + 1326 |
llama_memory_breakdo

calm talonBOT
# worn forge I changed the model to another one, now Wake up only returns this: Wake up, m...

That output actually means the TUI is connected and the agent is responding.

  • The onboarding “hatch” sends Wake up, my friend! as a heartbeat-style ping.
  • HEARTBEAT_OK is the expected ack for that ping.
  • The footer line connected | idle ... confirms the session is up.

So the next step is simply: type a normal message in the TUI (e.g. hello) and see if you get a real reply.

If you still get “(no output)” when you type normal messages

In another terminal run:

openclaw logs --follow

Then send a message in the TUI and paste the log lines around the attempt (there’s usually a parse/HTTP error or a model response-shape mismatch).

#

About the weird tokens: <|channel|>final <|constrain|>...

That’s the model leaking its internal formatting tokens. It’s not an OpenClaw thing; it’s the local model / template.

Two practical fixes to try:

  1. Switch LM Studio provider API mode (some local stacks behave better on chat-completions than responses):
models: {
  providers: {
    lmstudio: {
      api: "openai-completions"
    }
  }
}
#

(restart gateway after change)

  1. Try a different LM Studio model that doesn’t emit those control tokens.

If you paste what you get when you type hello in the TUI + the relevant openclaw logs --follow chunk, I can tell you which of the two is the right fix.

worn forge
#

I tried several other lm studio models and changed the api mode to the one you provided and the same issue still happens

calm talonBOT
# worn forge I tried several other lm studio models and changed the api mode to the one you p...

Two different things are getting mixed together here:

1) “Wake up, my friend!” is a heartbeat-style wake

That hatch step triggers a wake/heartbeat run. If the agent decides “nothing to report”, the correct response is HEARTBEAT_OK — and OpenClaw will often suppress OK-only heartbeat replies, which shows up as:

  • Wake up, my friend!
  • (no output)

So “(no output)” during wake is not automatically an error as long as the footer shows connected | idle.

What I need to know is:

When you type a normal message in the TUI (e.g. hello), do you get a real response — or also “no output”?

2) If normal messages also produce no output, we need the Gateway logs

Please do this exact sequence:

#
  1. In one terminal:
openclaw logs --follow
  1. In the TUI, send a normal message like:
hello (reply with one short sentence)
  1. Copy/paste the log lines that appear for that run (especially any error or “dropping heartbeat ack” / validation / parse messages).

Without those logs we’re guessing.

3) Important: don’t post your gateway token publicly

You already pasted your config earlier and it includes gateway.auth.token. Consider rotating it after we fix this.

#

If you paste the openclaw logs --follow chunk from a normal TUI message, I can tell you exactly whether this is:

  • the run being treated as a heartbeat and getting dropped,
  • an LM Studio response-shape mismatch (responses vs chat-completions),
  • or the model output being filtered/stripped.
worn forge
#

Wake up, my friend!

<|channel|>final <|constrain|>HEARTBEAT_OK

Wake up, my friend!

<|channel|>final <|constrain|>HEARTBEAT_OK
connected | idle
agent main | session main (openclaw-tui) | lmstudio/google/gemma-3-4b | tokens 17k/131k (13%)

calm talonBOT
# worn forge Wake up, my friend! <|channel|>final <|constrain|>HEARTBEAT_OK Wake up, my...

What you pasted there is still just the hatch “wake” probe, and your model is replying with a heartbeat ack:

  • HEARTBEAT_OK = “nothing to report” (that’s a valid heartbeat response)
  • connected | idle = gateway + agent loop is up

So if the only thing you’re doing is watching the “Wake up, my friend!” lines: you might actually be fine.

1) Can you confirm this: do normal TUI messages work?

In the TUI (after it shows connected), type something like:

hello — reply with one short sentence (not HEARTBEAT_OK)

If you get a real sentence back, you’re good and onboarding “wake” is just noise.

If you still get no reply / or it keeps returning HEARTBEAT_OK, then we need logs from a normal send: