My fresh OpenClaw install kept failing. The model wasn’t the problem.

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 hello 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:

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5-coder:14b",
    "messages": [
      {"role": "user", "content": "hello"}
    ]
  }'

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 42,967 token context window.

No, that does not mean you have 42,967 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 /v1/chat/completions 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: openclaw logs --follow, 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:

openclaw status
openclaw status --all
openclaw gateway probe
openclaw gateway status
openclaw doctor
openclaw channels status --probe
openclaw logs --follow

If I were debugging a fresh local setup, these would happen before any model swap.

At minimum:

openclaw status
openclaw status --all
openclaw gateway status
openclaw doctor
openclaw logs --follow

Why this matters:

• if raw HTTP works but openclaw infer model run 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:

models:
  providers:
    local:
      models:
        - name: your-model
          compat:
            requiresStringContent: true
            supportsTools: false

What they mean in practice:

• requiresStringContent: true helps when the backend rejects structured messages[].content
• supportsTools: false 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.

reserve_tokens_floor can make failures more frequent

This one surprised me because it looks like a safety setting.

In the Reddit thread, one commenter mentioned checking reserve_tokens_floor and setting it to 20,000 if it had been increased, because a higher value made the error happen more often.

That makes sense once you do the math.

If OpenClaw is reserving a huge chunk of context for the response, then the usable budget for everything else shrinks fast.

Add:

• skill prompts
• memory
• tool schemas
• system instructions
• some history

and suddenly the turn doesn’t fit, even though the model’s advertised context window looks generous.

So if you’ve been increasing reserve settings because the model feels unstable, you may be manufacturing the instability.

/compact can help with history:

/compact

But it won’t magically remove large system prompts, loaded skills, memory payloads, or tool definitions that still get injected every turn.

Skill bloat is real

This is the annoying answer nobody wants.

You install an agent framework because you want more capabilities.

Then the capabilities become the problem.

One of the most useful comments I saw in those OpenClaw discussions was basically: something is eating your context window, and if you downloaded a bunch of skills, it’s probably that.

That’s blunt. It’s also probably correct a lot of the time.

A few things that add up fast:

• dreaming features
• memory plugins
• LanceDB-backed memory
• extra operator skills
• broad tool profiles
• long-running session history

The result is simple: the model gets a turn that no longer fits cleanly.

Strip the agent down before changing the model

If I’m debugging a local OpenClaw install, I want the smallest possible reproducible setup.

That means:

1. reduce loaded skills
2. simplify or disable memory
3. test without LanceDB
4. use the narrowest tool profile possible
5. keep the prompt boring

OpenClaw’s tool profile defaults matter here. New local configs often default to coding, while:

• minimal only allows session_status
• messaging stays narrow
• full removes profile restrictions

That means your tool profile changes behavior before Qwen, Llama, or any other model generates a token.

If a minimal profile works and a broader profile fails, you’ve learned something important.

My practical checklist before ollama model-hopping

This is the order I’d use.

1. Prove the model works directly

Run a plain request against Ollama.

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b",
    "messages": [
      {"role": "user", "content": "Write one sentence about Redis."}
    ]
  }'

If this fails, fix Ollama first.

If this works, keep going.

2. Run OpenClaw diagnostics

openclaw status
openclaw doctor
openclaw logs --follow

Don’t skip the logs.

3. Look for context blowout

If the logs point to context pressure, believe them.

Don’t keep arguing with the evidence because the model’s advertised window looks big enough.

4. Shrink the agent

Temporarily remove the extras:

• fewer skills
• less memory
• no LanceDB
• narrower tool profile
• short test prompt

You want to know whether the failure is caused by agent overhead.

5. Revisit reserve settings

If you increased reserve_tokens_floor, back off and retest.

A reserve budget that looks “safe” can make fitting the turn much harder.

6. Check compat flags

If the backend is flaky with structured content or tools, try:

compat:
  requiresStringContent: true
  supportsTools: false

7. Only then switch models or backends

And switch for a reason:

• better context behavior
• better OpenAI-compat handling
• more stable tool support
• fewer runtime quirks

Not because you ran out of patience.

When switching stacks is the rational move

I like local stacks for experimentation.

They’re great for testing prompts, trying agent ideas, and validating workflows before you commit to anything bigger.

But if you’re trying to run agents every day, the bar changes.

You need:

• stable OpenAI-compatible behavior
• predictable tool calling
• fewer compat edge cases
• less babysitting of context and token budgets
• cost predictability when automations run 24/7

That’s where a lot of teams eventually stop fighting their local stack and move to a cleaner API layer.

If you’re building agents in n8n, Make, Zapier, OpenClaw, or custom workflows, the problem usually isn’t just “can this model answer?”

The real question is:

Can this endpoint behave consistently under real agent load?

That’s a different standard.

It’s also why flat-rate OpenAI-compatible services are attractive for production automations. When your workflow is doing tool calls, retries, memory, long prompts, and constant background runs, per-token billing turns every debugging session into cost math.

That gets old fast.

Standard Compute is interesting here because it gives you an OpenAI-compatible endpoint with unlimited AI compute at a flat monthly price, so you can run agents and automations without watching token spend on every turn. If you’re tired of debugging around local backend quirks and then getting punished by per-token pricing in production, that model makes a lot of sense.

The main point

If your model works in Ollama and dies in OpenClaw, don’t start with a model funeral.

Start by asking what else is riding along in the prompt.

Most fresh-install failures are not “this model is dumb.”

They’re usually one of these:

• hidden prompt overhead
• reserve-budget mistakes
• tool/profile bloat
• memory injection
• backend compatibility mismatches

Those are fixable.

And if they aren’t, at least you’ll know whether you need a better model, a better backend, or a better stack.