OpenClaw + Ollama Small Models: "Does Not Support Thinking" 400 Error
You've set up OpenClaw on one machine pointing to Ollama running on another machine on your local network. You pick a small, fast model like qwen2.5:0.5b, run a test, and get silence — nothing in the dashboard, no response in chat. Check the logs and you'll find:
400 {"error":"\"qwen2.5:0.5b\" does not support thinking"}
Meanwhile, a direct curl to Ollama's /api/chat with the exact same model works perfectly. So what's OpenClaw doing differently?
The Cause
OpenClaw injects a think or thinking parameter into Ollama API requests. For larger models that support extended reasoning (like qwen3 or deepseek-r1), this is intentional. But smaller models — qwen2.5:0.5b, phi3:mini, gemma:2b, and others — don't implement the thinking interface at all. Ollama rejects the request with a 400 before it ever generates a response.
OpenClaw doesn't fall back gracefully — it just drops the response, leaving the UI blank and the gateway silent.
Workarounds
Option 1: Disable Thinking for the Model in Config (Recommended)
Add a model entry in your openclaw.json that explicitly disables thinking for the small model:
{
"models": {
"providers": {
"ollama": {
"models": [
{
"id": "qwen2.5:0.5b",
"thinkingDefault": "off",
"params": {
"think": false
}
}
]
}
}
}
}
Add a similar entry for each small model you use. After editing, restart the gateway:
openclaw gateway restart
Option 2: Use a Model That Supports Thinking
If your hardware can handle it, switch to a model that supports Ollama's thinking interface. These work without any config changes:
qwen3:8b— solid reasoning, runs on 8–12GB RAMqwen3:4b— lighter option, still supports thinkingdeepseek-r1:7b— strong at structured reasoning tasks
ollama pull qwen3:4b
# Then update your openclaw config to point to qwen3:4b
Option 3: Pin to OpenClaw 2026.4.10
If you need the small model specifically and don't want to fiddle with config, rolling back to 2026.4.10 avoids the thinking injection entirely for Ollama providers:
npm install -g openclaw@2026.4.10
openclaw gateway restart
Option 4: Use openai-compat Format with Ollama
Ollama exposes an OpenAI-compatible API at port 11434. Routing OpenClaw through the openai provider with a custom base URL bypasses the Ollama-specific thinking injection:
{
"models": {
"providers": {
"openai": {
"baseURL": "http://192.168.1.102:11434/v1",
"apiKey": "ollama",
"models": [{ "id": "qwen2.5:0.5b" }]
}
}
}
}
This is especially useful in multi-machine setups where you want fine-grained control over which models get which parameters.
Diagnosing the Problem
# Test directly from OpenClaw machine to Ollama machine
curl http://192.168.1.102:11434/api/chat \
-d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"hello"}],"think":false}'
# Should return a valid response
# Now test with think:true — this is what OpenClaw was sending:
curl http://192.168.1.102:11434/api/chat \
-d '{"model":"qwen2.5:0.5b","messages":[{"role":"user","content":"hello"}],"think":true}'
# Returns: 400 {"error":"\"qwen2.5:0.5b\" does not support thinking"}
Multi-Machine Ollama Setup Tips
While you're here — a few things that trip people up in remote Ollama setups:
- Ollama binds to localhost by default. You need to set
OLLAMA_HOST=0.0.0.0in Ollama's systemd service (or environment) for remote access to work at all. - Firewall rules. Port 11434 must be open between machines — check with
curl http://192.168.1.102:11434/from the OpenClaw machine. - Model availability.
openclaw infer model listshould show the remote models if connectivity is working.
Setting up a multi-machine Ollama + OpenClaw environment? ClawReady's setup service covers remote Ollama configuration, model selection for your hardware, and cost optimization across local and cloud providers.