Not getting responses | Friends of the Crustacean 🦞🤝 | Page 1

stray pebbleBOT Apr 14, 2026, 2:05 PM

#

low elmBOT Apr 14, 2026, 2:05 PM

#

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

stray pebbleBOT Apr 14, 2026, 2:05 PM

#

blazing kite Apr 14, 2026, 2:06 PM

#

Arch Linux, ollama installed via official repo, openclaw and qwen3.5 through npm

finite lintelBOT Apr 14, 2026, 2:07 PM

#

This smells more like the local model/backend stalling than message routing, since WhatsApp is reaching the model and then timing out.

First, can you paste:

openclaw --version
openclaw status --all
openclaw models status

Then do this while sending one test message:

openclaw logs --follow

A few quick things to check right now:

#

If you configured Ollama manually, do not use /v1
OpenClaw wants the native Ollama API, for example:
- baseUrl: "http://127.0.0.1:11434"
- api: "ollama"
If you use http://...:11434/v1, tool calling can hang or break.

Raise the LLM idle timeout temporarily

openclaw config set agents.defaults.llm.idleTimeoutSeconds 900
openclaw gateway restart

Or set it to 0 just for testing.

Run one isolated model test

#

   openclaw infer model run --model ollama/<your-model> --prompt "reply with hi" --json

If that hangs too, the issue is almost certainly the Ollama model/backend, not WhatsApp/Discord routing.

If you can, also paste your models.providers.ollama config block (redact anything sensitive). My first suspicion is either:

Ollama is pointed at /v1 instead of native API, or
the local Qwen build is choking on full agent prompts/tool schemas

Docs:

Paste those outputs and I’ll help narrow it down.

#

Got it. OpenClaw via npm on Arch is fine, but I still need the actual version string first:

openclaw --version

Also paste these:

ollama list
openclaw models status

My best guess right now is one of these:

the Ollama endpoint is configured as .../v1 instead of native Ollama
the exact Qwen3.5 variant is too slow for full agent prompts

#

the model is stalling on tool-enabled prompts

Two fast tests:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 900
openclaw gateway restart

and

openclaw infer model run --model ollama/<exact-model-from-ollama-list> --prompt "reply with hi" --json

If that second command hangs too, it’s almost certainly the Ollama/model side.

#

Also, if you manually configured Ollama, please confirm your provider uses the native API, not /v1:

baseUrl: "http://127.0.0.1:11434"
api: "ollama"

Docs:

Paste openclaw --version, ollama list, and openclaw models status, and I can be a lot more precise.

blazing kite Apr 14, 2026, 2:13 PM

#

│ Version │ 2026.4.12
│ OS │ linux 6.19.11-arch1-1 (x64)
│ Node │ 25.9.0
│ Config │ ~/.openclaw/openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale │ off
│ Channel │ stable (default)
│ Update │ pnpm · npm update 2026.4.14
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 80ms · auth token · arch (192.168.1.50) app 2026.4.12 linux 6.19.11-arch1-1
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ unknown
│ Gateway service │ systemd installed · enabled · running (pid 9673, state active)
│ Node service │ systemd not installed
│ Agents │ 1 total · 1 bootstrapping · 1 active · 2 sessions
│ Secrets │ none

Channels

│ Channel │ Enabled │ State │ Detail │

│ WhatsApp │ ON │ OK │ linked · <redacted> · auth 1m ago · accounts 1

WhatsApp accounts

│ default │ OK │ dm:allowlist · allow:<redacted>

│ Agent │ Bootstrap file │ Sessions │ Active │ Store
│ main │ PRESENT │ 2 │ 1m ago │ ~/.openclaw/agents/main/sessions/sessions.json

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/<redacted>/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/<redacted>/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 9673 <redacted>: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 7 eligible · 0 missing · /home/<redacted>/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

#

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/qwen3.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

finite lintelBOT Apr 14, 2026, 2:14 PM

#

Thanks, this helps a lot. The big clue is here:

Agents: 1 total · 1 bootstrapping
Bootstrap file: PRESENT

That usually means the agent is stuck in first-run bootstrap mode. In OpenClaw, BOOTSTRAP.md is supposed to be removed after first-run completes. If it sticks around, the agent can stay “conjuring” forever.

The Port 18789 is already in use bit is not the problem here, that just means your gateway is already running.

I’d try this first:

openclaw config get agents.defaults.workspace

Then in that workspace, move BOOTSTRAP.md out of the way, for example:

#

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

(Adjust the path if your workspace is not the default one.)

Then send a fresh test message.

If it still hangs after that, do these next:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 900
openclaw gateway restart
openclaw logs --follow

#

If you want, paste:

ollama list

because with local Qwen, the exact model size matters a lot. A slower/smaller local build can choke on the full bootstrap/agent prompt even when basic chat seems fine.

Docs:

I’m pretty confident the stuck BOOTSTRAP.md is the first thing to clear here.

#

Nice, that models status looks basically fine. So this does not look like an Ollama auth/config problem.

At this point I’d treat 1 bootstrapping + Bootstrap file PRESENT as the main suspect.

OpenClaw marks an agent as bootstrapping just from BOOTSTRAP.md still existing, and docs say that file should be removed after first run. If it stays around, the agent can keep acting like it’s still hatching.

I’d do this next:

openclaw config get agents.defaults.workspace
ls -l ~/.openclaw/workspace/BOOTSTRAP.md
mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then try a fresh message.

#

If it still stalls after that:

openclaw doctor
openclaw config set agents.defaults.llm.idleTimeoutSeconds 900
openclaw gateway restart
openclaw logs --follow

If you want one more useful data point, paste:

ollama list

because then we can see the exact Qwen variant/tag you’re running.

#

So, short version: your model wiring looks okay, the stuck bootstrap looks more suspicious now.

blazing kite Apr 14, 2026, 2:16 PM

#

500 {"error":"model runner has unexpectedly stopped, this may be due to resource limitations or an internal error, check ollama server logs for details"}

500 {"error":"llama runner process has terminated: %!w(\u003cnil\u003e)"}

qwen3.5:latest

finite lintelBOT Apr 14, 2026, 2:17 PM

#

Yep, that’s the smoking gun.

Those 500 errors are from Ollama itself, not from OpenClaw routing:

model runner has unexpectedly stopped
llama runner process has terminated

So OpenClaw is basically waiting on a model process that keeps dying. Increasing idle timeout alone won’t fix that.

Please run these next:

ollama run qwen3.5:latest "reply with hi"
systemctl status ollama
journalctl -u ollama -n 200 --no-pager

#

If you want live logs while reproducing it:

journalctl -u ollama -f

What this usually means:

resource problem
not enough RAM / VRAM for that model + prompt size
bad model pull / runner crash
Ollama model or backend is broken
Ollama backend issue on that machine
driver / GPU / llama runner crash

#

So at this point I’d treat it as:

primary issue: Ollama runner crashing
secondary issue: bootstrap may still be stuck because the first run never completed

If ollama run qwen3.5:latest "reply with hi" also crashes, that confirms it’s outside OpenClaw.

Paste the last ~50 lines from journalctl -u ollama -n 200 --no-pager and I can help read the crash. After Ollama is stable, if OpenClaw still shows 1 bootstrapping, then we should clear the leftover BOOTSTRAP.md.

Docs:

blazing kite Apr 14, 2026, 2:19 PM

#

this command: ollama run qwen3.5:latest "reply with hi"

is stuck on loading

finite lintelBOT Apr 14, 2026, 2:19 PM

#

That confirms it, the problem is before OpenClaw.

If plain:

ollama run qwen3.5:latest "reply with hi"

gets stuck on loading, OpenClaw is just waiting on Ollama.

I’d pause the OpenClaw side for now and check Ollama directly:

journalctl -u ollama -f

Then in another terminal, run the same ollama run ... again and watch what Ollama logs when it hangs/crashes.

#

Also paste these:

ollama ps
free -h

If you have a GPU, also:

nvidia-smi

My guess right now is one of:

model too large for available RAM / VRAM
Ollama runner crashing during load

#

GPU/backend issue

So, short version:

not a WhatsApp/OpenClaw routing problem
not mainly an idle-timeout problem
very likely an Ollama load/crash/resource problem

Paste the Ollama journal output and I’ll help decode it. After Ollama is healthy, we can clean up the stuck bootstrap if needed.

blazing kite Apr 14, 2026, 2:27 PM

#

the ollama run... command now gave an output, but journalctl shows nothing.

arch% ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5:latest 6488c96fa5fa 18 GB 100% CPU 262144 Stopping...
arch% free -h
total used free shared buff/cache available
Mem: 46Gi 31Gi 3.0Gi 377Mi 13Gi 15Gi
Swap: 23Gi 60Ki 23Gi
arch%

finite lintelBOT Apr 14, 2026, 2:28 PM

#

Ah, okay, this explains the whole thing.

You’re running:

18 GB model
100% CPU, no GPU
262144 context

That is a very heavy local setup for OpenClaw. A plain ollama run can eventually answer, but OpenClaw sends much larger prompts than a simple "reply with hi", so first-token latency gets bad enough that it looks hung or hits the idle timeout.

So the likely story is:

Ollama is not fully broken
It’s just too slow / too heavy for this model on CPU, especially with that context size
The stuck bootstrap is probably a side effect of the first run never finishing

Quick test

#

Temporarily disable the idle watchdog:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 0
openclaw gateway restart

If it eventually responds, that confirms this is mostly a latency/perf problem.

Better fix

Cap the effective runtime context for that Ollama model. OpenClaw supports:

models.providers.ollama.models[].contextTokens

That’s the right knob when you want a smaller effective context budget than the model’s native 262k.

A reasonable starting point would be something like:

#

{
  models: {
    providers: {
      ollama: {
        models: [
          {
            id: "qwen3.5",
            contextTokens: 32768,
            maxTokens: 4096
          }
        ]
      }
    }
  }
}

#Not getting responses

Quick test

Better fix