I hit a failure pattern recently that’s way more common than people admit: install OpenClaw connect it to Ollama pull a decent local model test the model directly and it works run the first real agent turn and everything falls apart At that point, most people do the obvious thing: blame the model.
Swap Qwen for Llama.
Try a bigger model.
Try a smaller model.
Re-pull weights.
Tweak quantization.
Repeat.
I think that’s usually the wrong first move.
The real issue is often prompt baggage, context budgeting, or backend compatibility.
Not the model itself.
A direct Ollama prompt is a tiny test.
An OpenClaw agent turn is not.
The tell: direct Ollama works, OpenClaw fails I was reading a thread on r/openclaw where someone on Ubuntu Server said even a brand-new session with just could trigger the recurring error.
The strange part was that the same model felt “lightning fast and great” when used directly through Ollama with a 4096 context.
That’s the giveaway.
If this works: but OpenClaw falls over on a normal turn, the model is probably not your first problem.
You’re usually dealing with one of these: context blowout oversized system instructions too many skills loaded memory payloads getting injected every turn tool schema overhead output reservation settings that are too aggressive OpenAI-compat quirks in the backend That pattern shows up outside OpenClaw too.
I’ve seen the same thing in n8n, Make, Zapier, and custom OpenAI-compatible agent stacks: the hello-world prompt passes, then the real automation fails because the production request is much heavier than anyone realized.
A “fresh” OpenClaw install is not actually empty This is the part people miss.
By the time your local model sees a real OpenClaw turn, it may already be carrying: system instructions tool definitions skill prompts memory context chat history compacted summaries reserved output budget So yes, your model may advertise a token context window.
No, that does not mean you have tokens available for the next response.
That gap is where a lot of “the model is broken” debugging goes off the rails.
Direct prompt vs agent turn Header 1 Header 2 Direct Ollama prompt Usually a clean call with a short prompt and no agent overhead OpenClaw agent turn Adds tools, memory, skills, system instructions, history, and output reservation before generation starts Typical failure mode Works directly, then fails inside OpenClaw with refusals, tool errors, or silent turn failures First thing to inspect Direct prompt: model context size.
Agent turn: , tool profile, compat flags, memory usage A direct chat test proves the model can answer.
It does not prove your backend can support agent behavior reliably.
Start with diagnostics, not vibes Before changing models, I’d run the boring commands.
OpenClaw’s docs are actually pretty good here because they separate backend health from agent/runtime issues.
This is the sequence I’d use first: If I were debugging a fresh local setup, these would happen before any model swap.
At minimum: Why this matters: if raw HTTP works but fails, that points to compatibility or runtime issues if logs show context pressure, stop pretending it’s a model IQ problem if tool calls are malformed, the backend contract may be wrong That’s a much better use of time than randomly bouncing between Qwen and Llama.
The two compat flags I’d check early A lot of local OpenAI-compatible backends are only mostly compatible.
That’s enough to waste an afternoon.
OpenClaw calls out two flags that solve a surprising number of failures: What they mean in practice: helps when the backend rejects structured helps when the backend claims tool support but behaves badly under actual tool-calling That is not a “bad weights” issue.
That is plumbing.
If the plumbing is wrong, switching from Qwen to Llama is just redecorating a leaking house. can make failures more frequent This one surprised me because it looks like a safety setting.
In the Reddit thread, one commenter mentioned checking and