openclaw agent not responding correctly ( at all) | Friends of the Crustacean 🦞🤝 | Page 1

chrome zodiac Apr 17, 2026, 2:40 AM

#

So I have built 2 machines, one with Ollama running qwen2.5:0.5b on 192.168.1.102. 2nd machine running Openclaw on 192.168.1.101. This took ages to get to talk to the web ui as all the favorite messages would come up. . do to not being localhost. I did try the tailscale optopn but that didn't work and I do not see the need to vpn between 2 machines on my local network.
But I finally got some answers and the webui comes up. I know the Ollama server is running and responding. However when the Openclaw UI comes up,, shows my heartbeat.md file. so I enter a hello "as you do" and all I get is the 3 wavy dots for about 5 seconds and then nothing. just comes back to his prompt (Assistant 12:25pm qwen2.5:0.5b) every time. ITs like its trying to respond but no one seems to be home.
What and where should I look for this. The logs keep telling me of pairing issues, but it has been doing that regardless. even when the agent was responding a while ago.
It has taken me 3 days and several rebuilds to get the UI to talk to me, to this point. ay suggestions where I may look to get it to respond properly

queen cypressBOT Apr 17, 2026, 2:40 AM

#

low parcelBOT Apr 17, 2026, 2:40 AM

#

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

queen cypressBOT Apr 17, 2026, 2:40 AM

#

pure willowBOT Apr 17, 2026, 2:42 AM

#

Let me check the docs and the local status, because this smells like a mix of model capability and agent/runtime state rather than just the UI.

#

This honestly sounds more like a model/runtime problem than a UI problem.

Two big suspects:

qwen2.5:0.5b is extremely small for OpenClaw
OpenClaw agent turns are much heavier than a plain “hello” in a normal chat UI. A 0.5B local model can look “alive” but then produce nothing useful, or just collapse on the full prompt.
Wrong Ollama endpoint mode
If you configured Ollama as http://192.168.1.102:11434/v1, that is likely wrong for OpenClaw. Docs say to use the native Ollama API, not OpenAI-compat mode:
- baseUrl: "http://192.168.1.102:11434"
- api: "ollama"
- no /v1

Docs:

#

What I’d check next, on the OpenClaw box (192.168.1.101):

openclaw --version
openclaw status --all
openclaw models status
curl http://192.168.1.102:11434/api/tags
openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: hello" --json

Then in another terminal:

openclaw logs --follow

…and while that is running, send hello again in the UI.

#

What the results mean:

If infer model run fails, the issue is provider config / Ollama connectivity / model.
If infer model run works but UI chat still returns nothing, the model is probably folding on the full agent prompt. In that case, try a much larger model, or reduce pressure with:
- agents.defaults.experimental.localModelLean: true

Also, the pairing errors may be a red herring if the dashboard is already connected and letting you send prompts. I’d focus on the model run path first.

If you paste:

openclaw --version
openclaw models status
the relevant bit of models.providers.ollama
the error lines from openclaw logs --follow

…I can usually tell pretty quickly which part is broken. Glad you got this far, 3 days on this stuff is rough. 🦐

chrome zodiac Apr 17, 2026, 2:48 AM

#

ok ran the suggest commands. got a long list. too big to paste here. cant see how to attach a file here to show the log output. . I am running the smaller model due to the spec on the ryzen 5 amd system for ollama. this is a proof of concept to get it working away from the net. once I know it works, I would invest in something a little more capable.

pure willowBOT Apr 17, 2026, 2:48 AM

#

No worries, don’t paste the whole thing, just the useful slices.

For this case, I’d paste only these 4 things, each in its own code block:

openclaw --version

openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: hello" --json

openclaw config get models.providers.ollama
openclaw config get agents.defaults.model

#

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
grep -iE 'error|warn|fail|ollama|timeout|tool|exception' "$LOG" | tail -80

If the config output shows Ollama using /v1, that is probably the first thing to fix. For remote Ollama it should be the native API, like:

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://192.168.1.102:11434",
        api: "ollama"
      }
    }

#

}
}

No /v1.

Also, for a proof-of-concept, I want to be blunt: 0.5B may be too small to prove full OpenClaw agent behavior. It can still be useful to prove the network/config path, but not necessarily the “real assistant works” part.

If you want one low-risk thing to try next, enable lean local mode:

{
  agents: {
    defaults: {
      experimental: {

#

        localModelLean: true
      }
    }
  }
}

Then restart:

openclaw gateway restart

That reduces prompt/tool pressure on smaller local models.

Docs:

#

Paste those 4 smaller outputs and I’ll help narrow it down. Glad that helped a bit, even if this setup has been a pain. 🦐

chrome zodiac Apr 17, 2026, 2:49 AM

#

Version │ 2026.4.12

pure willowBOT Apr 17, 2026, 2:49 AM

#

Nice, that helps, 2026.4.12 is recent enough, so this is probably not one of the older known broken-session bugs.

The next two outputs matter most now:

openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: hello" --json

and

openclaw config get models.providers.ollama

If you can only paste one thing first, paste the models.providers.ollama block, because I mainly want to check for:

baseUrl accidentally ending in /v1

#

wrong api mode
anything odd in the Ollama provider config

If you paste the config, redact any token/password value if one shows up.

So far:

✅ version looks fine
still most likely either wrong Ollama endpoint mode or the 0.5B model folding under the full agent prompt

Paste that provider block next and we can narrow it down fast.

chrome zodiac Apr 17, 2026, 2:50 AM

#

openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: hello" --json
02:50:05 [agent/embedded] embedded run agent end: runId=e1589e23-5619-407b-a9f8-84b9b860b1b9 isError=true model=qwen2.5:0.5b provider=ollama error=LLM request failed: provider rejected the request schema or tool payload. rawError=400 {"error":""qwen2.5:0.5b" does not support thinking"}
02:50:05 [agent/embedded] auth profile failure state updated: runId=e1589e23-5619-407b-a9f8-84b9b860b1b9 profile=sha256:9c018ec112cf provider=ollama reason=format window=cooldown reused=false
02:50:05 [agent/embedded] embedded run failover decision: runId=e1589e23-5619-407b-a9f8-84b9b860b1b9 stage=assistant decision=surface_error reason=format provider=ollama/qwen2.5:0.5b profile=sha256:9c018ec112cf
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "qwen2.5:0.5b",
"attempts": [],
"outputs": [
{
"text": "LLM request failed: provider rejected the request schema or tool payload.",
"mediaUrl": null
}
]
}

#

{
"baseUrl": "http://192.168.1.102:11434",
"apiKey": "OPENCLAW_REDACTED",
"api": "ollama",
"models": [
{
"id": "qwen2.5:0.5b",
"name": "qwen2.5:0.5b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "qwen2.5-coder:32b",
"name": "qwen2.5-coder:32b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 32768,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "qwen3.5:latest",
"name": "qwen3.5:latest",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 262144,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "qwen2.5:7b",
"name": "qwen2.5:7b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 32768,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "llama3:8b",
"name": "llama3:8b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 8192,
"maxTokens": 8192,
"api": "ollama"
}
]
}

pure willowBOT Apr 17, 2026, 2:51 AM

#

Aha, that’s the smoking gun. Let me verify the exact config shape to disable thinking cleanly.

#

Yep, that’s it, we found the real failure.

qwen2.5:0.5b is rejecting the request because OpenClaw is sending thinking, and Ollama is returning:

"qwen2.5:0.5b" does not support thinking

So the UI isn’t “doing nothing”, the model request is getting a 400 and the run dies.

Quickest fix

In the web chat, send this as a standalone message:

/think off

Then try hello again.

#

Docs: https://docs.openclaw.ai/tools/thinking

Important distinction

/think off = disables model thinking
/reasoning off = only hides reasoning output

For your error, /think off is the one that matters.

If that fixes it, make it permanent

Check whether you have a default thinking level set:

openclaw config get agents.defaults.thinkingDefault

#

If you have per-agent overrides, also check those.

In config, you want this to be off for that setup, for example:

{
  agents: {
    defaults: {
      thinkingDefault: "off"
    }
  }
}

If you change config, restart the gateway after:

#

openclaw gateway restart

One more note

Even after this, 0.5B is still very likely too weak for full OpenClaw agent use. But this specific error is not guesswork anymore, it’s a concrete thinking-mode mismatch.

If you want, next paste just this:

openclaw config get agents.defaults.thinkingDefault

and I can tell you whether the config is the thing forcing it.

chrome zodiac Apr 17, 2026, 2:51 AM

#

"primary": "ollama/qwen2.5:0.5b"

pure willowBOT Apr 17, 2026, 2:52 AM

#

That provider config actually looks good.

So we can rule out a bunch of stuff:

✅ baseUrl is correct
✅ api: "ollama" is correct
✅ no /v1
✅ the model is marked reasoning: false

That means the think flag is almost certainly being forced from somewhere else, usually one of these:

the current session has thinking enabled
agents.defaults.thinkingDefault is set to something other than off
a per-agent thinkingDefault override is set

Next thing to do

#

In the web UI chat itself, send this as a standalone message:

/think off

Then send:

hello

If that works, the problem was session/global thinking, not Ollama connectivity.

Why this can happen even though the model says `reasoning: false`

Because OpenClaw can still apply a session or config thinking default, and Ollama is rejecting that with:

#

"qwen2.5:0.5b" does not support thinking"

So your config and the runtime default can disagree. That’s what this looks like.

If `/think off` does not fix it

Run these next:

openclaw config get agents.defaults.thinkingDefault
openclaw config get agents.list

If either shows thinkingDefault set to low, medium, high, etc, change it to off for now, then:

#

openclaw gateway restart

If the session itself feels wedged after that, start a fresh one with:

/new

Then try again.

Docs:

Honestly, this is a good sign, the Ollama wiring looks sane now. We’re down to a much smaller bug surface.

#

Yep, that line just says the selected model is:

"primary": "ollama/qwen2.5:0.5b"

That part is fine, it does not explain the error by itself.

The missing bit is still the thinking setting.

Before digging any deeper, do the quickest test in the UI chat:

/think off

If it replies with something like “Thinking disabled.”, then send:

#

hello

If that starts working, we’ve confirmed the problem.

If not, the next thing I need is this exact output:

openclaw config get agents.defaults.thinkingDefault

and, if you have agent overrides:

openclaw config get agents.list

#

Right now the evidence still points to:

model = ollama/qwen2.5:0.5b
model itself = reasoning: false
but OpenClaw runtime/session is still trying to send thinking

So the most likely fix is still turn thinking off for that session or agent.

chrome zodiac Apr 17, 2026, 2:52 AM

#

it just queued the /think off message lol

pure willowBOT Apr 17, 2026, 2:53 AM

#

lol, that usually means the current session is wedged, not that /think off was the wrong idea.

I’d stop poking that session and do this instead:

Check the config directly on the OpenClaw box:

openclaw config get agents.defaults.thinkingDefault
openclaw config get agents.list

If either shows a thinkingDefault like low, medium, high, etc, change it to off in config.
Then restart the gateway:

#

openclaw gateway restart

After that, open a fresh session in the web UI and try again.

At this point I’m pretty confident the chain is:

Ollama/provider config = fine
model = selected correctly
current session / agent default = still trying to use thinking
broken run = now clogging that session queue

So the next useful thing to paste is:

#

openclaw config get agents.defaults.thinkingDefault

and if present:

openclaw config get agents.list

That should finally tell us where the thinking flag is coming from.

chrome zodiac Apr 17, 2026, 2:53 AM

#

Config path not found: agents.defaults.thinkingDefault

#

Config path not found: agents.defaults.thinkingDefault

pure willowBOT Apr 17, 2026, 2:54 AM

#

Let me double-check one subtle thing, because that “path not found” changes the diagnosis a bit.

#

Ah, okay, that changes the picture.

If agents.defaults.thinkingDefault is not set, then this is looking less like your config and more like a compatibility bug/edge case.

What I found in current source/tests is that for Ollama, OpenClaw can explicitly send:

"think": false

when thinking is “off”.

Some Ollama models appear to reject the presence of think entirely, and that would match your exact error:

"qwen2.5:0.5b" does not support thinking

Best next test

#

Run these directly against Ollama from the OpenClaw machine.

1. Without `think`

curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false}'

2. With `think:false`

curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false,"think":false}'

What I expect

#

If #1 works
and #2 fails with the same does not support thinking

then we’ve basically confirmed:

your network setup is fine
your Ollama provider config is fine
OpenClaw is tripping over an Ollama/model compat issue around the think field

Practical workaround

For the proof-of-concept, I’d temporarily switch to one of the other installed models on that Ollama box and see if it tolerates the same request shape. That would prove the OpenClaw↔Ollama plumbing is okay.

If the curl repro confirms it, I’d call that bug territory and file it here with the exact two curl examples plus the OpenClaw infer failure:

https://github.com/openclaw/openclaw/issues

#

This is actually good progress, we’re not guessing anymore.

#

Yep, that line means there is no global thinkingDefault override, so we can rule that out.

At this point the next useful step is the direct Ollama repro, because that should tell us whether qwen2.5:0.5b is choking on the think field itself.

Run these two:

curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false}'

curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false,"think":false}'

#

If the first works and the second fails, we’ve basically confirmed the bug/compat issue. Paste those two results and we can close the loop.

chrome zodiac Apr 17, 2026, 2:55 AM

#

Config path not found: agents.defaults.thinkingDefault

#

Config path not found: agents.list

pure willowBOT Apr 17, 2026, 2:55 AM

#

Yep, that one’s already useful, it means no global thinking default.

You can stop running that command now 🙂
The next test is the two curl calls I posted above. Those are the ones that should tell us whether this is a think:false compatibility issue with that Ollama model.

If it’s easier, just run this first one and paste the result:

curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false}'

Then we’ll compare it to the same request with "think":false.

#

Perfect, that actually helps a lot.

So now we’ve ruled out:

agents.defaults.thinkingDefault
agents.list overrides

That makes this look even more like a runtime compat issue, not your config.

Don’t run more `config get` commands

Next, run this exact one and paste the result:

curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false}'

#

If that works, I’ll give you the second version with "think":false so we can compare them directly.

We’re very close now.

chrome zodiac Apr 17, 2026, 2:56 AM

#

{"model":"qwen2.5:0.5b","created_at":"2026-04-17T02:56:27.626796458Z","message":{"role":"assistant","content":"Hello! How can I assist you today?"},"done":true,"done_reason":"stop","total_duration":486376190,"load_duration":156131551,"prompt_eval_count":34,"prompt_eval_duration":38855972,"eval_count":10,"eval_duration":272564542

pure willowBOT Apr 17, 2026, 2:57 AM

#

Nice, that’s exactly what I hoped to see.

So now we know:

✅ OpenClaw can reach Ollama
✅ Ollama can run qwen2.5:0.5b
✅ the model itself answers normal /api/chat requests

That means the failure is almost certainly in the request shape OpenClaw is sending.

Final comparison test

Run the same request again, but with "think":false added:

curl http://192.168.1.102:11434/api/chat \

#

  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false,"think":false}'

If this one fails with the same does not support thinking error, then we’ve basically confirmed:

OpenClaw is sending a think field
this model rejects that field
your setup is fine, this is a compat bug/edge case

Paste that result and we should have the answer nailed down.

chrome zodiac Apr 17, 2026, 2:57 AM

#

H 'content-type: application/json'
-d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false,"think":false}'
{"model":"qwen2.5:0.5b","created_at":"2026-04-17T02:57:15.970214248Z","message":{"role":"assistant","content":"Hello! How can I assist you today?"},"done":true,"done_reason":"stop","total_duration":452770780,"load_duration":156444102,"prompt_eval_count":34,"prompt_eval_duration":29873519,"eval_count":10,"eval_duration":252312967

pure willowBOT Apr 17, 2026, 2:58 AM

#

Interesting, that rules out the think:false theory. I’m going to check the infer/config path for per-model thinking, because that’s now the most likely culprit.

#

That’s useful, and it means I was wrong about think:false being the problem. Let me check whether infer model run supports an explicit thinking override, because that would isolate the exact layer fast.

#

That’s really helpful, and it means my last theory was off. Thanks for testing it.

Since both of these work:

normal /api/chat
/api/chat with "think": false

the problem is not simply “this model rejects think:false”.

So the next most likely culprit is a per-model override in:

agents.defaults.models

OpenClaw can store model-specific params there, including thinking.

#

Next command

Please run:

openclaw config get agents.defaults.models

If it’s huge, you do not need to paste the whole thing, just the part for:

ollama/qwen2.5:0.5b

What I’m looking for is something like:

#

"ollama/qwen2.5:0.5b": {
  params: {
    thinking: "low"
  }
}

If that exists, we’ve found it.

Where we are now

We’ve ruled out:

Ollama connectivity
bad base URL
/v1 mistake

#

model itself being broken
model rejecting think:false

So now this is narrowing to OpenClaw’s selected runtime params, not the Ollama server.

Paste the agents.defaults.models bit and I think we’ll finally pin it.

chrome zodiac Apr 17, 2026, 2:58 AM

#

-H 'content-type: application/json'
-d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false}'
{"model":"qwen2.5:0.5b","created_at":"2026-04-17T02:58:10.838298781Z","message":{"role":"assistant","content":"Hello! How can I assist you today?"},"done":true,"done_reason":"stop","total_duration":457344896,"load_duration":162827688,"prompt_eval_count":34,"prompt_eval_duration":29864549,"eval_count":10,"eval_duration":249853216

pure willowBOT Apr 17, 2026, 2:58 AM

#

Yep, that curl result is still good, which is actually reinforcing the same conclusion:

Ollama is fine
that model is fine
the problem is inside OpenClaw’s chosen runtime params

So the curl part is done now. You don’t need to rerun it again.

The one command I need next

openclaw config get agents.defaults.models

If it prints a lot, just paste the section for:

#

ollama/qwen2.5:0.5b

That’s the bit that can contain model-specific params like thinking.

I know this has been tedious, but we are past the network/debugging stage now. This next command is the one that should tell us where OpenClaw is getting the bad request shape from.

chrome zodiac Apr 17, 2026, 2:59 AM

#

-H 'content-type: application/json'
-d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false,"think":false}'
{"model":"qwen2.5:0.5b","created_at":"2026-04-17T02:58:56.460565051Z","message":{"role":"assistant","content":"Hello!"},"done":true,"done_reason":"stop","total_duration":244751204,"load_duration":138520053,"prompt_eval_count":34,"prompt_eval_duration":37590133,"eval_count":3,"eval_duration":56468949}

pure willowBOT Apr 17, 2026, 2:59 AM

#

Perfect, that settles it, both raw Ollama requests work.

So this is not:

network
base URL
Ollama itself
the model itself
think:false by itself

It’s now almost certainly something in OpenClaw config/runtime selection.

Please stop rerunning the curl commands

They’ve done their job.

Run this exact command next

#

openclaw config get agents.defaults.models

That is the one thing I need now.

If it’s long, paste only the part containing:

ollama/qwen2.5:0.5b

We’re down to the last likely config bucket.

chrome zodiac Apr 17, 2026, 3:00 AM

#

pure willow Perfect, that actually helps a lot. So now we’ve ruled out: - `agents.defaults...

-H 'content-type: application/json'
-d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false}'
{"model":"qwen2.5:0.5b","created_at":"2026-04-17T02:59:36.029956794Z","message":{"role":"assistant","content":"Hello! How can I assist you today?"},"done":true,"done_reason":"stop","total_duration":453976768,"load_duration":133970148,"prompt_eval_count":34,"prompt_eval_duration":29729377,"eval_count":10,"eval_duration":272263745

pure willowBOT Apr 17, 2026, 3:00 AM

#

Looks like Discord lagged and sent me one of the earlier curl replies 😅

We’re good on the curl tests now. Current state is:

normal Ollama call works
think:false Ollama call works
so the problem is not raw Ollama

The current next step

Please run this now:

openclaw config get agents.defaults.models

and paste just the part for:

#

ollama/qwen2.5:0.5b

That’s the last config bucket I still want to check.

chrome zodiac Apr 17, 2026, 3:01 AM

#

pure willow ```json5 "ollama/qwen2.5:0.5b": { params: { thinking: "low" } } ``` If ...

{
"ollama/qwen2.5:0.5b": {},
"ollama/llama3.2": {},
"ollama/llama2.75b": {},
"ollama/qwen3.5:latest": {},
"ollama/qwen2.5:7b": {}
}

pure willowBOT Apr 17, 2026, 3:02 AM

#

We’ve ruled out more than I expected. I’m going to check the exact openclaw agent CLI syntax, because an explicit --thinking off run may isolate whether this is the infer path or the session/UI path.

#

Okay, that rules out the last obvious config bucket too.

At this point, I’m pretty comfortable saying:

your LAN/Ollama setup is fine, and this is probably an OpenClaw bug or compat bug in the runtime path.

Why I think that

You’ve now proven all of this:

raw Ollama /api/chat works
raw Ollama /api/chat with "think": false works
models.providers.ollama is correct
no agents.defaults.thinkingDefault
no agents.list
no per-model params in agents.defaults.models

#

But OpenClaw infer still fails with:

400 {"error":"\"qwen2.5:0.5b\" does not support thinking"}

That’s enough evidence for “OpenClaw is constructing/sending something wrong on this path”, not “your box is broken”.

My recommendation

I would stop burning time on rebuilds and file this as a bug:

https://github.com/openclaw/openclaw/issues

Include these exact repro points

Version:

#

openclaw --version

Failing OpenClaw command:

openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: hello" --json

Working raw Ollama call:

curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false}'

Working raw Ollama call with think:false:

#

curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false,"think":false}'

Minimal config proof:

models.providers.ollama looks correct
agents.defaults.thinkingDefault not found
agents.list not found
agents.defaults.models["ollama/qwen2.5:0.5b"] is {}

Practical workaround for now

For the proof-of-concept, I’d temporarily switch the UI to one of the other installed models and keep going. That at least lets you validate the rest of the OpenClaw setup without being blocked by this specific model/runtime edge case.

If you want, I can help you write a tight GitHub issue body from the evidence you already collected, so you can just paste it.

chrome zodiac Apr 17, 2026, 3:03 AM

#

Krill you are a legend. I am fairly new to the AI world, and was using it outside and burning tokens. ok that would be great

pure willowBOT Apr 17, 2026, 3:04 AM

#

Aw, thank you, and yep, local-first is a very sane goal here.

Here’s a copy-paste GitHub issue you can use:

Title

Ollama qwen2.5:0.5b works via /api/chat, but `openclaw infer model run` fails with `"does not support thinking"`

Body

## Summary

I’m running OpenClaw on one machine and Ollama on another machine on the same LAN.

- OpenClaw host: `192.168.1.101`

#

- Ollama host: `192.168.1.102:11434`
- OpenClaw version: `2026.4.12`

The OpenClaw web UI connects, but chat requests return no visible answer.
Tracing it down, `openclaw infer model run` fails for `ollama/qwen2.5:0.5b` with:

```text
400 {"error":"\"qwen2.5:0.5b\" does not support thinking"}

However, direct calls to Ollama succeed, including the same request with "think": false.

This makes it look like an OpenClaw runtime/request-shaping issue rather than an Ollama connectivity or model issue.

OpenClaw version

#


```bash
openclaw --version

Output:

2026.4.12

Ollama provider config

{
  "baseUrl": "http://192.168.1.102:11434",

#

"apiKey": "OPENCLAW_REDACTED",
"api": "ollama",
"models": [
{
"id": "qwen2.5:0.5b",
"name": "qwen2.5:0.5b",
"reasoning": false,
"input": ["text"],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192,
"api": "ollama"

#

}
]
}


## Failing OpenClaw repro

```bash
openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: hello" --json

Output:

02:50:05 [agent/embedded] embedded run agent end: runId=e1589e23-5619-407b-a9f8-84b9b860b1b9 isError=true model=qwen2.5:0.5b provider=ollama error=LLM request failed: provider rejected the request schema or tool payload. rawError=400 {"error":"\"qwen2.5:0.5b\" does not support thinking"}
02:50:05 [agent/embedded] auth profile failure state updated: runId=e1589e23-5619-407b-a9f8-84b9b860b1b9 profile=sha256:9c018ec112cf provider=ollama reason=format window=cooldown reused=false
02:50:05 [agent/embedded] embedded run failover decision: runId=e1589e23-5619-407b-a9f8-84b9b860b1b9 stage=assistant decision=surface_error reason=format provider=ollama/qwen2.5:0.5b profile=sha256:9c018ec112cf

#

{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "qwen2.5:0.5b",
"attempts": [],
"outputs": [
{
"text": "LLM request failed: provider rejected the request schema or tool payload.",
"mediaUrl": null
}
]
}

#

## Working direct Ollama repro

### 1) Plain request works

```bash
curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false}'

Output:

{"model":"qwen2.5:0.5b","created_at":"2026-04-17T02:56:27.626796458Z","message":{"role":"assistant","content":"Hello! How can I assist you today?"},"done":true,"done_reason":"stop","total_duration":486376190,"load_duration":156131551,"prompt_eval_count":34,"prompt_eval_duration":38855972,"eval_count":10,"eval_duration":272564542}

#


### 2) Request with `think:false` also works

```bash
curl http://192.168.1.102:11434/api/chat \
  -H 'content-type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"Reply with exactly: hello"}],"stream":false,"think":false}'

Output:

{"model":"qwen2.5:0.5b","created_at":"2026-04-17T02:58:56.460565051Z","message":{"role":"assistant","content":"Hello!"},"done":true,"done_reason":"stop","total_duration":244751204,"load_duration":138520053,"prompt_eval_count":34,"prompt_eval_duration":37590133,"eval_count":3,"eval_duration":56468949}

#

## Config checks already ruled out

These do not exist / are not set:

```text
agents.defaults.thinkingDefault
agents.list

And agents.defaults.models contains:

{
  "ollama/qwen2.5:0.5b": {},
  "ollama/llama3.2": {},
  "ollama/llama2.75b": {},

#

"ollama/qwen3.5:latest": {},
"ollama/qwen2.5:7b": {}
}


So I do not see an obvious config-driven `thinking` override.

## Expected behavior

`openclaw infer model run --model ollama/qwen2.5:0.5b ...` should succeed the same way the direct Ollama `/api/chat` request succeeds.

## Actual behavior

OpenClaw returns:

```text
400 {"error":"\"qwen2.5:0.5b\" does not support thinking"}

#


while equivalent direct Ollama requests succeed.

## Notes

The initial symptom in the web UI was:
- prompt gets sent
- typing/wavy dots appear briefly
- no visible reply comes back

This appears to be the same underlying failure surfaced through the UI path.

You can drop that into https://github.com/openclaw/openclaw/issues.

Also, glad we got to an actual repro instead of “have you tried reinstalling it again” nonsense 😅

chrome zodiac Apr 17, 2026, 3:16 AM

#

sorry i had a phone call come in. ok so i got lost in the stream here . so much info. what do I need to do exactly many apologies

pure willowBOT Apr 17, 2026, 3:16 AM

#

No apology needed at all.

What to do, exactly

Stop debugging for now.
You’ve already proven your network + Ollama setup works.
In OpenClaw, switch away from qwen2.5:0.5b
and try one of the larger models you already have installed.
If you want maintainers to fix it, file a GitHub issue
here:
https://github.com/openclaw/openclaw/issues

Use the issue text I wrote above, basically copy/paste it.

Short version of the diagnosis

#

Your LAN setup is okay
Ollama is okay
Raw requests to the model work
OpenClaw specifically is choking on this model/runtime combo

So the practical path is

For now: use a different local model
Later: file the bug report so it can be fixed

If you want, I can give you a super short 3-line version of the GitHub bug report next.

chrome zodiac Apr 17, 2026, 3:16 AM

#

yes please

pure willowBOT Apr 17, 2026, 3:17 AM

#

Sure, here’s the short version to paste into GitHub:

Title

OpenClaw infer/web UI fails with ollama/qwen2.5:0.5b, but direct Ollama /api/chat works

Body

OpenClaw 2026.4.12 on 192.168.1.101, Ollama on 192.168.1.102:11434.

`openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: hello" --json`
fails with:
`400 {"error":"\"qwen2.5:0.5b\" does not support thinking"}`

But direct Ollama calls to `/api/chat` with the same model work, including with `"think": false`.

#

So this looks like an OpenClaw runtime/request-shaping bug, not an Ollama connectivity issue.

Issue link:
https://github.com/openclaw/openclaw/issues

If switching to one of your larger installed models gets you unstuck, and this thread helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

chrome zodiac Apr 17, 2026, 3:28 AM

#

which model would be the best to use on this ryzen system

pure willowBOT Apr 17, 2026, 3:28 AM

#

Short answer: not the 0.5B one 🙂

For OpenClaw on a Ryzen box, I’d aim for the largest local model your machine can run without becoming unusably slow, ideally in the 7B to 8B class or larger for a proof-of-concept.

My practical advice:

Avoid 0.5B for OpenClaw agent testing
Try a larger model already installed on your Ollama box
If it’s CPU-only, expect it to be slow, but it should still be a much better test than 0.5B
For real everyday agent use, cloud models are still much more reliable

For exact current model picks, ask in #models and check:

If you want, tell me whether that Ryzen machine has a GPU and how much VRAM/RAM it has, and I can give you a size class recommendation like “stay around 7B” vs “try bigger”.

chrome zodiac Apr 17, 2026, 3:29 AM

#

no GPU . as its a test unit. just the ryzen 5 12 core processor 16GB ram

pure willowBOT Apr 17, 2026, 3:29 AM

#

Got it. On CPU-only, 16GB RAM, I’d keep expectations modest.

My honest recommendation:

Aim around 7B-ish
8B can be okay if quantized and you can tolerate slow replies
0.5B is too small for OpenClaw agent behavior
32B is not realistic on that box for a good experience

So for your test unit, the sweet spot is basically:

small enough to fit comfortably
big enough to not fall over immediately

That usually means 7B class first, maybe 8B class second.

For actual day-to-day OpenClaw use, I’d still expect:

#

local CPU-only = okay for experiments / proof-of-concept
cloud = much better for real agent reliability

If switching to a larger local model gets you unstuck, glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

chrome zodiac Apr 17, 2026, 4:06 AM

#

geez interrupted by a bunch of support calls. now lets see if can change the model

pure willowBOT Apr 17, 2026, 4:06 AM

#

Yep, sounds like one of those days 😅

That’s the right next move. Try switching to a larger local model and see if the UI starts replying normally.

If it gets weird again, just paste:

the model you switched to
whether the UI replied or stayed blank

and I’ll help you narrow it down fast.

chrome zodiac Apr 17, 2026, 4:07 AM

#

ok now another issue andi killed that PID already but it keels coming back up with this. 03:43:20 Gateway failed to start: gateway already running (pid 73595); lock timeout after 5000ms
If the gateway is supervised, stop it with: openclaw gateway stop
03:43:20 Port 18789 is already in use.
03:43:20 - pid 73595 openclaw: openclaw-gateway (*:18789)
03:43:20 - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
03:43:20 Gateway service appears enabled. Stop it first.
03:43:20 Tip: openclaw gateway stop
03:43:20 Or: systemctl --user stop openclaw-gateway.service

pure willowBOT Apr 17, 2026, 4:08 AM

#

Yep, that means the Gateway is being supervised, so killing the PID just makes it come right back.

Do this instead:

openclaw gateway stop
openclaw gateway status

If it still respawns, stop the user service directly:

systemctl --user stop openclaw-gateway.service
systemctl --user status openclaw-gateway.service

Then once it is actually stopped, start it cleanly again:

#

openclaw gateway start

Short version

Don’t kill the PID
Stop the service
then start it once

Docs:

https://docs.openclaw.ai/gateway/troubleshooting

If openclaw gateway stop says it stopped but status still shows running, paste the output of:

openclaw gateway status

#

systemctl --user status openclaw-gateway.service

chrome zodiac Apr 17, 2026, 4:09 AM

#

ok it does not seem to want to stop the service

pure willowBOT Apr 17, 2026, 4:09 AM

#

Got it. Then I’d go one level lower and stop the user service directly.

Run these:

systemctl --user stop openclaw-gateway.service
systemctl --user disable openclaw-gateway.service
systemctl --user status openclaw-gateway.service
openclaw gateway status

If it is still coming back after that, then something else is relaunching it, and the two status outputs above will tell us what.

So for now:

stop
disable

#

then paste the output of the two status commands

You’re close, this sounds more like service supervision than anything fundamentally broken.

chrome zodiac Apr 17, 2026, 4:11 AM

#

Apr 17 04:08:24 openclaw systemd[966]: Stopping openclaw-gateway.service - OpenClaw Gateway (v2026.4.12)...
Apr 17 04:08:25 openclaw node[74986]: 2026-04-17T04:08:25.221+00:00 [ws] ⇄ res ✗ chat.history 0ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during>
Apr 17 04:08:25 openclaw node[74986]: 2026-04-17T04:08:25.227+00:00 [gateway] signal SIGTERM received
Apr 17 04:08:25 openclaw node[74986]: 2026-04-17T04:08:25.228+00:00 [gateway] received SIGTERM; shutting down
Apr 17 04:08:26 openclaw node[74986]: 2026-04-17T04:08:26.566+00:00 [ws] ⇄ res ✗ chat.history 0ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during>
Apr 17 04:08:26 openclaw node[74986]: 2026-04-17T04:08:26.567+00:00 [ws] ⇄ res ✓ node.list 1345ms conn=d485ba47…0da2 id=38c2bc04…a35c
Apr 17 04:08:26 openclaw node[74986]: 2026-04-17T04:08:26.569+00:00 [plugins] embedded acpx runtime backend registered (cwd: /home/openclaw/.openclaw/workspace)
Apr 17 04:08:26 openclaw node[74986]: 2026-04-17T04:08:26.592+00:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=password)
Apr 17 04:08:26 openclaw systemd[966]: Stopped openclaw-gateway.service - OpenClaw Gateway (v2026.4.12).
Apr 17 04:08:26 openclaw systemd[966]: openclaw-gateway.service: Consumed 20.517s CPU time.

#

Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-04-17.log
Command: /usr/bin/node /home/openclaw/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.1.101:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006):

Port 18789 is already in use.

Port is in use but process details are unavailable (install lsof or run as an admin user).
Troubles: run openclaw status

pure willowBOT Apr 17, 2026, 4:12 AM

#

That actually looks good. It did stop cleanly.

The important lines are:

received SIGTERM; shutting down
Stopped openclaw-gateway.service

And the chat.history unavailable during... lines are normal during shutdown, not the main problem.

Next step

Check it is really down:

openclaw gateway status

#

If it shows stopped, start it cleanly again:

openclaw gateway start

If you want it under systemd again afterward:

systemctl --user enable openclaw-gateway.service
systemctl --user start openclaw-gateway.service

So the short answer is: the stop worked.
Now you can do a clean start instead of fighting the respawning PID.

#

Nice, this narrows it down a lot.

systemd is not the problem anymore.
The service is stopped and disabled.

Your current blocker is simply:

something else is still holding port 18789

Next step, identify the process

Try one of these:

ss -ltnp | grep 18789

#

or, if that does not show the owner:

sudo ss -ltnp | grep 18789

Alternative:

sudo fuser -v 18789/tcp

What we’re looking for

The command should show the PID/program that still owns :18789.

Then:

#

if it is an old manual OpenClaw gateway, stop/kill that one
if it is something unexpected, don’t kill it blindly, paste the output here first

Short summary

✅ OpenClaw service stopped
✅ systemd disabled
❌ port 18789 still occupied by some other process

Paste the output of ss -ltnp | grep 18789 and we can finish this bit.

chrome zodiac Apr 17, 2026, 4:13 AM

#

LISTEN 0 128 [::1]:18789 [::]:*

pure willowBOT Apr 17, 2026, 4:13 AM

#

That’s helpful.

So something is listening on:

[::1]:18789

which means loopback only, not the LAN bind you expect.
That strongly smells like a stray old local gateway/manual process.

Next step, get the owner PID/program

Run one of these with sudo so it shows the process name:

#

sudo ss -ltnp | grep 18789

or

sudo fuser -v 18789/tcp

If you have lsof installed:

sudo lsof -i :18789

What I expect

#

Probably an old node / openclaw-gateway process started manually.

If that’s what it is, stop that process, then start OpenClaw cleanly again.

If you want, paste the sudo ss -ltnp | grep 18789 output and I’ll tell you exactly what to kill.

chrome zodiac Apr 17, 2026, 4:14 AM

#

LISTEN 0 128 [::1]:18789 [::]:* users:(("ssh",pid=6783,fd=4))

#

ssh 6783 root 4u IPv6 26222 0t0 TCP ip6-localhost:18789 (LISTEN)

pure willowBOT Apr 17, 2026, 4:14 AM

#

Aha, there it is.

Port 18789 is not being held by OpenClaw now, it’s being held by:

ssh (pid 6783)

So you have an SSH tunnel/port forward sitting on 18789.

What to do

Either:

Close that SSH session / tunnel
or kill that PID:

#

kill 6783

Then start OpenClaw again:

openclaw gateway start

Why this happened

That SSH process is binding local port 18789, so OpenClaw cannot bind the same port.

If you still need the SSH tunnel

Use a different local port for the tunnel, for example 18889, instead of 18789.

#

So yeah, this one is just a port collision with SSH, not another OpenClaw bug.

#

Yep, that confirms it.

That is a root-owned SSH tunnel listening on 18789.

If you just want to get unstuck fast:

sudo kill 6783
openclaw gateway start

If you want to see what started it first:

ps -fp 6783

#

But the main thing is: that SSH process is the port conflict. Once it is gone, OpenClaw should be able to bind 18789 again.

chrome zodiac Apr 17, 2026, 4:15 AM

#

ahhh i get it. I am using ssh into the laptops, but the laptop itself is running it for some unknown reason

pure willowBOT Apr 17, 2026, 4:15 AM

#

Yep, exactly, that’s the collision.

You’ve basically got two ways of reaching the same thing fighting each other:

OpenClaw trying to bind 18789
your SSH tunnel also binding 18789

Since your Gateway is already set to LAN bind, you probably do not need the SSH port forward at all for this setup.

Easiest path

Use OpenClaw directly at:

http://192.168.1.101:18789/

#

and don’t forward 18789 over SSH.

If you do want SSH anyway

Forward a different local port, for example:

ssh -L 18889:127.0.0.1:18789 ...

Then you’d browse to:

http://127.0.0.1:18889/

So yeah, this one finally makes sense: the SSH tunnel was stealing the same port OpenClaw wanted.

queen cypressBOT Apr 17, 2026, 4:16 AM

#

chrome zodiac Apr 17, 2026, 4:17 AM

#

i dont know how that happened as I dont use the direct device at all. I only use it via an SSH connection. ok it has started up again. and the ui is showing the same issue as we started but now it is Assistant qwen3.5:latest which I change in the json file but still no response

pure willowBOT Apr 17, 2026, 4:18 AM

#

Got it. If it is still blank even on qwen3.5:latest, then I think we’ve moved past the 0.5B-specific weirdness.

At this point the most likely problem is:

the full OpenClaw agent prompt/tool load is too heavy for this local CPU-only setup

Best next thing to try

Turn on lean local model mode.

Add this to your config:

{
  agents: {
    defaults: {

#

      experimental: {
        localModelLean: true
      }
    }
  }
}

Then restart the gateway and try again in a new session.

Docs:

https://docs.openclaw.ai/gateway/local-models

Why

That mode drops a bunch of heavyweight default tool/prompt pressure, which is exactly what smaller or slower local setups tend to choke on.

#

If it still does nothing after that

Run just this one command and paste the result:

openclaw infer model run --model ollama/qwen3.5:latest --prompt "Reply with exactly: hello" --json

So, short version:

enable localModelLean
restart gateway
try a fresh session
if still blank, paste the new infer model run output

That’s the cleanest next move from here.

chrome zodiac Apr 17, 2026, 4:24 AM

#

ive messsed it upo. I had to ad a bunch of quotes " to your last but somehow I have jinxed it lol

#

"controlUi": {
"dangerouslyAllowHostHeaderOriginFallback": true,
"allowedOrigins": [
"http://12.168.1.101:18789"
],
"allowInsecureAuth": true,
"dangerouslyDisableDeviceAuth": true
}
},
{
" agents": {
"defaults": {
"experimental": {
"localModelLean": true
}
}
}
}
"workspace": "/home/openclaw/.openclaw/workspace",
"models": {
"ollama/qwen2.5:0.5b": {},
"ollama/llama3.2": {},
"ollama/llama2.75b": {},
"ollama/qwen3.5:latest": {},
"ollama/qwen2.5:7b": {}
},
"model": {
"primary": "ollama/qwen3.5:latest"
}

pure willowBOT Apr 17, 2026, 4:24 AM

#

Let me grab the exact openclaw config set pattern so I don’t make you fight quoting again.

#

No worries, easiest fix is: don’t hand-edit that bit.

Use the CLI so you don’t have to fight quotes:

openclaw config set agents.defaults.experimental.localModelLean true
openclaw config validate
openclaw gateway restart

Important

For that command, true is just:

true

#

not "true".

If config validate complains, paste the error and I’ll help un-jinx it 🙂

#

Yep, I can see what went wrong.

You accidentally pasted a second object into the middle of the config, and this key is also wrong:

" agents"

That leading space breaks it.

What to do

1. Remove this whole broken block

Delete this entire part:

#

{
 " agents": {
    "defaults": {
      "experimental": {
        "localModelLean": true
        }
    }
  }
}

2. Then use the CLI instead of hand-editing

Run:

#

openclaw config set agents.defaults.experimental.localModelLean true
openclaw config validate

3. One more important thing

I think this is also a typo:

"http://12.168.1.101:18789"

I’m pretty sure that should be:

"http://192.168.1.101:18789"

#

because your OpenClaw box has been 192.168.1.101 the whole time.

So the shortest recovery path is

openclaw config set agents.defaults.experimental.localModelLean true
openclaw config validate

If validate still fails, paste the error, and I’ll tell you exactly which line to fix.

chrome zodiac Apr 17, 2026, 4:28 AM

#

<root>: JSON5 parse failed: SyntaxError: JSON5: invalid character '{' at 23:1

pure willowBOT Apr 17, 2026, 4:28 AM

#

Yep, that confirms it, there is still an extra { in the file.

It is almost certainly this one from the block you pasted in manually.

What the file should not have

It should not look like this:

  },
{
 " agents": {

That extra { starts a second root object, which is why JSON5 blows up.

What it should look like instead

#

Also fix this typo

Change:

"http://12.168.1.101:18789"

#

to:

"http://192.168.1.101:18789"

Then run again

openclaw config validate

If it still errors, paste about 10 lines around line 23 and I’ll point to the exact character.

chrome zodiac Apr 17, 2026, 4:30 AM

#

<root>: JSON5 parse failed: SyntaxError: JSON5: invalid character ',' at 23:3
i pasted exactly whatyou asked me to do

pure willowBOT Apr 17, 2026, 4:30 AM

#

Ah, damn, that’s on me. Sorry, I gave you a partial snippet, and the comma placement depends on what is above it in your actual file.

Don’t edit it again yet.
Let’s look at the exact lines around the error.

Please run:

nl -ba ~/.openclaw/openclaw.json | sed -n '18,30p'

and paste the output here.

That will show line numbers around line 23, and then I can tell you the exact line to delete/fix instead of guessing.

chrome zodiac Apr 17, 2026, 4:31 AM

#

found that. had 1 too many { still there. now it tries but this happens - agents.defaults: Unrecognized key: "experimental"

pure willowBOT Apr 17, 2026, 4:32 AM

#

Yep, that means your installed version does not support that config key. Sorry, that one is on me.

Do this now

Remove this whole block:

"experimental": {
  "localModelLean": true
},

Then run:

openclaw config validate

#

openclaw gateway restart

What that means

Your config file is getting cleaner again, but experimental.localModelLean is not available in your version (2026.4.12).

So for now, keep the config simple:

use the larger model
don’t add that experimental block
restart cleanly

If the UI is still blank after that, I’d stop tweaking config and treat it as the same local-model/runtime bug/limitation we already narrowed down.

chrome zodiac Apr 17, 2026, 4:35 AM

#

ok once more I have screwed the pooch lol - <root>: JSON5 parse failed: SyntaxError: JSON5: invalid character ',' at 38:4

pure willowBOT Apr 17, 2026, 4:35 AM

#

No worries, you didn’t screw anything beyond normal config surgery 😅

That new error means there is now a bad comma around line 38.

Don’t guess.
Please run:

nl -ba ~/.openclaw/openclaw.json | sed -n '34,42p'

and paste the output.

Then I can tell you exactly which comma to remove instead of us playing config whack-a-mole.

chrome zodiac Apr 17, 2026, 4:36 AM

#

34 "model": {
35 "primary": "ollama/qwen3.5:latest"
36 }
37 }
38 },
39 "wizard": {
40 "lastRunAt": "2026-04-14T10:26:01.428Z",
41 "lastRunVersion": "2026.4.12",
42 "lastRunCommand": "configure",

pure willowBOT Apr 17, 2026, 4:36 AM

#

Thanks, that helps, but I need just a tiny bit more above it because lines 34-38 can be valid or invalid depending on what line 33 is opening.

Please run this one:

nl -ba ~/.openclaw/openclaw.json | sed -n '28,39p'

and paste it.

I know this is annoying, but I don’t want to guess and break it again. The issue is definitely in the brace/comma balance right above wizard.

chrome zodiac Apr 17, 2026, 4:37 AM

#

28 "ollama/qwen2.5:0.5b": {},
29 "ollama/llama3.2": {},
30 "ollama/llama2.75b": {},
31 "ollama/qwen3.5:latest": {},
32 "ollama/qwen2.5:7b": {}
33 },
34 "model": {
35 "primary": "ollama/qwen3.5:latest"
36 }
37 }
38 },
39 "wizard": {

pure willowBOT Apr 17, 2026, 4:37 AM

#

Almost there. These lines tell me the tail of the block is fine if the opener above it is correct, but I still need to see whether you still have:

"agents": {
  "defaults": {

above it.

Please run one last check:

nl -ba ~/.openclaw/openclaw.json | sed -n '20,28p'

and paste that.

#

The key thing I need to verify is whether the "agents" wrapper is still there. If it is missing, then line 38 is the extra close. If it is present, line 38 is correct.

chrome zodiac Apr 17, 2026, 4:38 AM

#

20 "dangerouslyDisableDeviceAuth": true
21 }
22 },
23 "agents": {
24 "defaults": {
25 },
26 "workspace": "/home/openclaw/.openclaw/workspace",
27 "models": {
28 "ollama/qwen2.5:0.5b": {},

pure willowBOT Apr 17, 2026, 4:38 AM

#

Found it. 🎯

This is the bad line:

25        },

You open defaults on line 24, then immediately close it on line 25, which breaks the whole block.

Fix

Delete line 25 entirely so it becomes:

23    "agents": {

#

24      "defaults": {
25        "workspace": "/home/openclaw/.openclaw/workspace",
26        "models": {

Then run:

openclaw config validate

That stray }, is the problem. Once that is gone, the later closing braces should make a lot more sense again.

chrome zodiac Apr 17, 2026, 4:40 AM

#

fixed. that is awesome. back to it. old mate assistant is still not home so I guess we are done until a fix is released or a workaround?

pure willowBOT Apr 17, 2026, 4:40 AM

#

Yep, I think that’s the honest read now.

You’ve already proven:

the network path works
Ollama works
the UI/gateway can come up
the config is fixed again

So the thing still failing is the OpenClaw + local-model runtime path on this box/version, not your basic setup.

Practical options from here

Try another larger local model if you want one more shot
Use a cloud model for now if you want OpenClaw working today
File the GitHub issue and wait for a fix/workaround

#

So, yes, unless another local model suddenly works better, I’d stop grinding on this specific setup for tonight. You’ve already done the hard part and found a pretty legit edge case.

And honestly, after 3 days of this, I’d call that enough suffering for one thread 😅

chrome zodiac Apr 17, 2026, 4:41 AM

#

hahah Krill you are a legend. I have never had so much help fixing an issue. 11 out of 10 stars .

#

awesome work.

pure willowBOT Apr 17, 2026, 4:42 AM

#

Hah, thank you, that genuinely made my night 🦐

You did the hard part, honestly, you stuck with a really gnarly one and got all the useful evidence out of it.

Glad that helped! 🎉
If this thread was useful, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

#

Thanks, really glad we untangled it 🦐

If this thread helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next poor soul who hits the same mess.

chrome zodiac Apr 17, 2026, 4:43 AM

#

gosh im so noooob. i cant even find that lol

pure willowBOT Apr 17, 2026, 4:43 AM

#

No worries at all 😄

On Discord:

Desktop: right-click the message you want to mark
choose Apps
then click ✅ Mark Solution

On mobile it is usually:

long-press the message
Apps
✅ Mark Solution

If you don’t see it, no stress, you already survived the hard part.

#openclaw agent not responding correctly ( at all)

Quickest fix

Important distinction

If that fixes it, make it permanent

One more note

Next thing to do

Why this can happen even though the model says reasoning: false

If /think off does not fix it

Best next test

1. Without think

2. With think:false

What I expect

Practical workaround

Don’t run more config get commands

Final comparison test

Next command

Where we are now

The one command I need next

Please stop rerunning the curl commands

Run this exact command next

The current next step

Why I think that

My recommendation

Include these exact repro points

Practical workaround for now

OpenClaw version

Ollama provider config

What to do, exactly

Short version of the diagnosis

So the practical path is

Short version

Next step

Next step, identify the process

What we’re looking for

Short summary

Next step, get the owner PID/program

What I expect

What to do

Why this happened

If you still need the SSH tunnel

Easiest path

If you do want SSH anyway

Best next thing to try

Why

If it still does nothing after that

Important

What to do

1. Remove this whole broken block

2. Then use the CLI instead of hand-editing

3. One more important thing

So the shortest recovery path is

What the file should not have

What it should look like instead

Also fix this typo

Then run again

Do this now

What that means

Fix

Practical options from here

Why this can happen even though the model says `reasoning: false`

If `/think off` does not fix it

1. Without `think`

2. With `think:false`

Don’t run more `config get` commands