Ollama for heartbeat | Friends of the Crustacean 🦞🤝 | Page 1

distant mango Apr 17, 2026, 10:21 AM

#

I am trying to Configure heartbeat to use:
ollama/qwen2.5:3b-instruct-q4_K_M
prompt: "Reply exactly HEARTBEAT_OK."
https://github.com/openclaw/openclaw/issues/65218

I was in version OpenClaw 2026.4.11. I found out that recent patch 2026.4.15 had an improvement on Lean ollama. Today I found this error while working, does this help with the program I am having ?

Error: Local embeddings unavailable.\nReason: Cannot find module 'node-llama-cpp'\nRequire stack:\n- C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\engine-embeddings-Bk3B82BS.js\nTo enable local embeddings:\n1) Use Node 24 (recommended for installs/updates; Node 22 LTS, currently 22.14+, remains supported)\n3) If you use pnpm: pnpm approve-builds (select node-llama-cpp), then pnpm rebuild node-llama-cpp\nOr set agents.defaults.memorySearch.provider = "openai" (remote).\nOr set agents.defaults.memorySearch.provider = "gemini" (remote).\nOr set agents.defaults.memorySearch.provider = "voyage" (remote).\nOr set agents.defaults.memorySearch.provider = "mistral" (remote).","_meta":{"runtime":"node","runtimeVersion":"24.14.0","hostname":"HQ-PS-N030","name":"{"subsystem":"memory"}","parentNames":["openclaw"],"date":"2026-04-17T09:01:23.997Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-Cgmckbux.js:324:14","fileName":"subsystem-Cgmckbux.js","fileNameWithLine":"subsystem-Cgmckbux.js:324","fileColumn":"14","fileLine":"324","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-Cgmckbux.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-Cgmckbux.js:324","method":"logToFile"}},"time":"2026-04-17T16:01:23.999+07:00"}

mortal prairieBOT Apr 17, 2026, 10:21 AM

#

boreal emberBOT Apr 17, 2026, 10:21 AM

#

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

coral magnetBOT Apr 17, 2026, 10:24 AM

#

Yes, that log helps. It looks like a separate problem from #65218, not the root cause.

#65218 on 2026.4.11 is a heartbeat precheck/compaction bug for small Ollama models.
This new warning is about memory embeddings. OpenClaw is trying to use memorySearch.provider = "local", which requires node-llama-cpp.
local is not the same as ollama.

So the key distinction is:

heartbeat.model = "ollama/qwen2.5:3b-instruct-q4_K_M" = chat model via Ollama
memorySearch.provider = "local" = GGUF embeddings via node-llama-cpp
memorySearch.provider = "ollama" = embeddings via your Ollama server

For a clean test, I’d do this first:

paste openclaw --version
run openclaw memory status --deep
if you only want to test heartbeat, either disable memory search temporarily, or pin it explicitly to Ollama

#

Example JSON5:

{
  agents: {
    defaults: {
      heartbeat: {
        model: "ollama/qwen2.5:3b-instruct-q4_K_M",
        prompt: "Reply exactly HEARTBEAT_OK.",
        lightContext: true,
        isolatedSession: true,
        target: "none",
      },
      memorySearch: {
        provider: "ollama",
        model: "nomic-embed-text",

#

        // or temporarily: enabled: false
      },
    },
  },
}

If you actually want memorySearch.provider: "local", then yes, you need to fix the missing node-llama-cpp install. But that is a different layer than the heartbeat model bug.

Also, if you are still on 2026.4.11, I would test on 2026.4.15+ before digging deeper.

Docs:

#

If you paste your openclaw --version, openclaw memory status --deep, and the heartbeat + memorySearch config snippet, I can narrow it down fast.

distant mango Apr 17, 2026, 10:25 AM

#

i am on version 2026.4.15 now

coral magnetBOT Apr 17, 2026, 10:26 AM

#

Got it, thanks. Since you’re on 2026.4.15, I’d treat the node-llama-cpp warning as a separate memory issue, not the main heartbeat bug from 2026.4.11.

So at this point:

heartbeat model via Ollama: ollama/qwen2.5:3b-instruct-q4_K_M
memory embeddings: currently trying local, which needs node-llama-cpp

That warning usually means OpenClaw is selecting memorySearch.provider = "local" somewhere.

I’d isolate it like this:

{
  agents: {
    defaults: {
      heartbeat: {

#

        model: "ollama/qwen2.5:3b-instruct-q4_K_M",
        prompt: "Reply exactly HEARTBEAT_OK.",
        lightContext: true,
        isolatedSession: true,
        target: "none",
      },
      memorySearch: {
        enabled: false,
      },
    },
  },
}

Restart the gateway, then test heartbeat again.

#

If that works, then re-enable memory search and switch it to Ollama explicitly:

memorySearch: {
  provider: "ollama",
  model: "nomic-embed-text",
}

and make sure the embedding model exists:

ollama pull nomic-embed-text

If you want, send these two outputs next and I can pinpoint it fast:

#

openclaw memory status --deep
openclaw system heartbeat last

Docs:

distant mango Apr 17, 2026, 10:30 AM

#

what is nomic-embed-text?

coral magnetBOT Apr 17, 2026, 10:31 AM

#

nomic-embed-text is an embedding model, not a chat model.

It turns text into vectors so OpenClaw can do things like:

semantic memory search
recalling similar past notes/messages
ranking memory hits by meaning, not exact words

So:

qwen2.5:3b-instruct-q4_K_M = your chat / heartbeat model
nomic-embed-text = a memory embeddings model for memorySearch.provider = "ollama"

If you use:

#

memorySearch: {
  provider: "ollama",
  model: "nomic-embed-text",
}

OpenClaw will ask Ollama for embeddings instead of trying local node-llama-cpp.

If you don’t care about memory search right now, you can skip it entirely and just set:

memorySearch: {
  enabled: false,
}

#

Docs:

If you want, I can show you the smallest working heartbeat-only config next.

distant mango Apr 17, 2026, 10:34 AM

#

Right now I am using qmd backend. Is this the same thing?

#

"memorySearch": {
"enabled": true,
"provider": "local",
"fallback": "none",
"local": {
"modelPath": "hf:ggml-org/embeddinggemma-300m-qat-q8_0-GGUF/embeddinggemma-300m-qat-Q8_0.gguf"

This is my current JSON right now

coral magnetBOT Apr 17, 2026, 10:38 AM

#

Yep, that explains the warning.

This part is the trigger:

"memorySearch": {
  "enabled": true,
  "provider": "local",

provider: "local" tells OpenClaw to use local embeddings via node-llama-cpp. Since node-llama-cpp is missing, you get:

Local embeddings unavailable
Cannot find module 'node-llama-cpp'

So this is:

#

not your heartbeat chat model
not the same thing as QMD
yes, the direct reason for that warning

If you’re using QMD and just want to stop this extra local-embedding path from interfering, I’d simplify to:

"memorySearch": {
  "enabled": false
}

or remove that block entirely while testing heartbeat.

If you actually want to keep builtin local memorySearch, then you need to install/fix node-llama-cpp.

So the clean split is:

#

Heartbeat model: ollama/qwen2.5:3b-instruct-q4_K_M
QMD backend: your memory engine
memorySearch.provider = "local"`: separate local embedding path, currently broken

Honestly, while debugging heartbeat, I’d disable memorySearch first. That removes one whole variable.

Docs:

If you want, I can help you trim this down to the smallest heartbeat-only config next.

distant mango Apr 17, 2026, 10:41 AM

#

So right now I am using QMD as default, by having this on it conflicts with QMD. is that correct?

coral magnetBOT Apr 17, 2026, 10:41 AM

#

Mostly yes, but I’d phrase it as overlapping config, not a hard conflict.

memory.backend: "qmd" says, “use QMD as the memory engine”
memorySearch.provider: "local" says, “also set up builtin local embeddings with node-llama-cpp”

So for your setup, that memorySearch block is basically an extra path you probably do not want right now, and it’s what’s causing the warning.

So the practical answer is:

QMD on
builtin memorySearch.provider: "local" off

That gives you the cleanest setup for testing heartbeat.

I’d keep:

#

memory: {
  backend: "qmd"
}

and disable/remove:

memorySearch: {
  enabled: true,
  provider: "local",
  ...
}

So yes, your intuition is right. It is not helping QMD, and it is muddying the situation.

#

After that change, restart the gateway and test heartbeat again.

Docs:

If this fixed the warning, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

distant mango Apr 17, 2026, 10:43 AM

#

Your answer is not clear yet. So assuming I do not have a heartbeat issue anymore. What should I do with this function of memory search

coral magnetBOT Apr 17, 2026, 10:43 AM

#

Short version, if heartbeat is fine now and you want to use QMD for memory, then:

Disable or remove memorySearch.

That is my recommendation.

What to do

Option 1, recommended

Use QMD only.

Keep:

memory: {
  backend: "qmd"

#

Disable/remove:

memorySearch: {
  enabled: true,
  provider: "local",
  ...
}

For example:

#

memorySearch: {
  enabled: false
}

or just delete that whole block.

This is the simplest and cleanest setup.

Option 2

Keep builtin memorySearch too, but then you must fix node-llama-cpp.

Only do this if you specifically want the builtin local embedding path.

Option 3

Keep builtin memorySearch, but switch it to a remote provider like OpenAI/Gemini.

#

I would not do this unless you have a reason, because you already have QMD.

My recommendation

Since you’re already using QMD as default, I would:

turn off memorySearch
restart the gateway
leave QMD as your only memory system

That removes the warning and keeps the config simpler.

Docs:

If you want, I can write the exact final JSON snippet I’d use for your setup, heartbeat + QMD only.

distant mango Apr 17, 2026, 11:41 AM

#

Tasks for my agent were stuck at block tasks due to rate limit. Now the limit is back, how do I move these tasks back to in progress?

coral magnetBOT Apr 17, 2026, 11:42 AM

#

You don’t manually move a blocked task back to in progress.

In current OpenClaw, blocked is a terminal record, basically an audit trail. The old task stays blocked. To continue the work, you create a new attempt.

What to do

Check what is blocked:

openclaw tasks list --status blocked
openclaw tasks flow list --status blocked

Inspect one item:

#

openclaw tasks show <taskId-or-runId>
openclaw tasks flow show <flowId>

Then re-trigger the original action that created the task.

If it was a one-off background task, run it again.
If it was part of a Task Flow, re-trigger the parent workflow. The new attempt should show up as queued/running, while the old one remains blocked.

Important bit

As far as the current CLI/docs go, there is no public command like:

openclaw tasks resume
openclaw tasks retry
openclaw tasks flow resume

#Ollama for heartbeat

What to do

Option 1, recommended

Option 2

Option 3

My recommendation

What to do

Important bit