OpenClaw Ollama auto-discovery missing: how to fix the false local-model failure

Problem statement: you installed Ollama, pulled the model, confirmed the server is live on 127.0.0.1:11434, and OpenClaw still reports the model as configured,missing. Then the really bad part starts: heartbeats or background tasks quietly run on a paid provider instead of the local model you thought you were using. This is not just a cosmetic health-check problem. It can turn a local inference setup into a silent cost leak.

What this error usually means

In plain language, configured,missing means OpenClaw believes a model should exist but cannot validate it from the runtime context it is actually using. That does not automatically mean Ollama is broken. Very often, Ollama is fine and the mismatch lives one layer above it.

The most common mistake is treating this like a simple install failure. Operators see the word missing, pull the model again, and lose an hour. But the real causes are usually more specific: the model name OpenClaw expects does not exactly match the model Ollama exposes, OpenClaw is running in a different network context than the host where Ollama listens, or a config edit created provider state that validates poorly even though the local daemon is healthy.

The four root causes that matter most

1) The model ID is not an exact match

Local-model stacks are unforgiving about names. If Ollama exposes one tag and OpenClaw references a slightly different one, discovery fails even though the model family is technically installed. The fresh issue is a good example: the runtime complained about ollama/llama3.2:1b. That is the sort of mismatch that looks plausible to a human but fails under exact provider lookup.

2) OpenClaw cannot reach 127.0.0.1 from where it actually runs

If OpenClaw is running in Docker, a VM, WSL, or a remote host, 127.0.0.1 may point at the wrong machine. Ollama can be healthy on your laptop while OpenClaw checks localhost inside a container that has never heard of it. This is one of the cleanest explanations for the pattern “curl works on the host, but OpenClaw still says missing.”

3) A fallback route is masking the real problem

This is the expensive one. Some OpenClaw workflows keep moving by selecting a different model when the local target is unavailable. That can make the assistant look alive while cost starts accumulating somewhere else. If your heartbeat still speaks, that is not proof Ollama is fixed. It may be proof that a paid provider quietly took over.

4) Hand edits created config drift

When operators start patching config files under pressure, they often solve one symptom and introduce another. Invalid provider sections, stale auth-profile references, or a default model still pointing at the old route can leave discovery half-fixed and production behavior still wrong.

Fast diagnostic flow that avoids wasted work

Step 1: prove Ollama is healthy from the same machine first

Start with the direct checks. If these fail, stop blaming OpenClaw and fix Ollama first.

• Run ollama list and confirm the exact installed tag.
• Run curl http://127.0.0.1:11434/api/tags and confirm the API returns the model list.
• Send one direct Ollama test prompt with the exact target model to prove local inference works.

Write down the exact returned model name. Not the family. Not the one you think you installed. The exact tag.

Step 2: check whether OpenClaw shares that network path

Now verify the part many operators skip: can the OpenClaw runtime reach the same Ollama endpoint? If OpenClaw is not on the same host network, the host-level health check is not enough.

• If OpenClaw is containerized, exec into the runtime context and test the Ollama endpoint from there.
• If OpenClaw is remote, confirm you are not assuming your laptop-local Ollama is visible to that remote instance.
• If you use WSL or Docker Desktop, verify the correct host bridge address instead of blindly using 127.0.0.1.

This single check explains a surprising number of “configured,missing” incidents.

Step 3: compare the exact OpenClaw model ID with the exact Ollama tag

Once reachability is proven, compare names literally. Use openclaw models list --provider ollama and inspect the exact model IDs OpenClaw is trying to resolve. If OpenClaw expects one tag while Ollama serves another, discovery will fail until they match.

Do not rely on “close enough” naming. Case, separators, namespaces, and tags matter. If the runtime error says Unknown model, trust the error and correct the name before changing anything else.

Step 4: inspect the default route and heartbeat model

If you care about local inference for cost control, this step is mandatory. Check what model your heartbeats, cron jobs, and default chat path actually use when discovery fails. A green app with the wrong route is worse than an app that fails loudly.

• Confirm the default model points at the intended Ollama model, not a cloud fallback.
• Review heartbeat or automation config for any secondary provider that can silently take over.
• After each change, run one fresh task and inspect whether usage appears on the local path or the paid one.

Step 5: restart cleanly after the smallest valid config change

Once you have identified the mismatch, make the smallest correction possible and then perform a real restart. Partial reloads are where stale provider state loves to hide. If you are comparing local versus managed deployment patterns, the broader operational tradeoff is laid out on the comparison page.

The safest fix pattern

1. Record the exact Ollama tag returned by ollama list.
2. Record the exact model ID OpenClaw is trying to resolve.
3. Fix the mismatch without renaming three other things at once.
4. Restart OpenClaw fully so provider state is rebuilt cleanly.
5. Run a fresh prompt and a fresh heartbeat test.
6. Check that the paid provider did not receive the request.

How to verify the fix actually worked

A passing probe is not enough. Verification needs both functionality and spend confirmation.

• Discovery check: openclaw models list --provider ollama no longer marks the target as missing.
• Execution check: a fresh prompt returns successfully through the intended model.
• Automation check: one heartbeat or cron run completes without jumping to the paid provider.
• Spend check: your cloud provider dashboard shows no new usage for that test window.
• Usage check: your runtime-level usage view reflects the expected route instead of zeros or misleading defaults.

That last point matters more than it sounds. If your usage summary path is unreliable, you can “fix” the model and still misread what happened. That is exactly why we treat usage verification as part of the repair, not as an optional extra.

Typical mistakes that keep this issue alive

• Re-pulling the model before verifying the exact tag mismatch.
• Testing Ollama only on the host and never from the OpenClaw runtime context.
• Changing provider config and default-model routing in the same edit.
• Assuming a successful heartbeat means the local model handled the request.
• Skipping the restart after a config correction.
• Declaring victory before checking cloud usage.

Edge cases worth checking

If the obvious fix still does not stick, look at the environment around it:

• Container boundary: Ollama lives on the host, but OpenClaw lives in Docker.
• Remote host mismatch: Ollama is local to your laptop while OpenClaw runs elsewhere.
• WSL split: the Windows side and Linux side do not share localhost the way you expect.
• Stale default model: discovery is fixed, but automations still point at the old cloud route.
• Multiple similar tags: you installed a newer variant and left the configured one behind.

When the real problem is operational overhead

Sometimes the right conclusion is not “debug harder.” If your OpenClaw setup keeps drifting across local models, host networking, provider config, restarts, and silent fallback behavior, the system is asking for more operator attention than it should. At that point, review the supported deployment path on OpenClaw Setup and the broader tradeoffs on OpenClaw cloud hosting.

Fix once. Stop recurring Ollama discovery failures.

If this keeps coming back, you can move your existing setup to managed OpenClaw cloud hosting instead of rebuilding the same stack. Import your current instance, keep your context, and move onto a runtime with lower ops overhead.

• Import flow in ~1 minute
• Keep your current instance context
• Run with managed security and reliability defaults

If you would rather compare options first, review OpenClaw cloud hosting or see the best OpenClaw hosting options before deciding.

Import your current OpenClaw instance in 1 click Compare managed vs self-hosted options

Final takeaway

When OpenClaw says Ollama is configured,missing, treat it as a routing and verification problem first, not just an install problem. Prove exact reachability, prove exact model naming, prove the default route, and prove that cloud spend stopped. If you do those in order, this incident becomes manageable instead of mysterious.

FAQ

Can I trust openclaw models status --probe alone?

No. It is useful, but it is not the whole story. Use it together with a real prompt and a spend check.

What if Ollama works directly but OpenClaw still fails after restart?

That usually points to either network-boundary mismatch or an exact model-ID mismatch. Re-check those two before touching anything else.

Should I disable fallback providers while debugging?

If cost control matters, yes. During diagnosis, it is safer to fail loudly than to let a paid model quietly take over and blur the signal.

Is managed hosting the answer if I still want local Ollama inference?

Not automatically. The better question is whether you want to keep owning the runtime complexity around the workflows that matter. If the answer is no, compare options before you sink more time into repetitive local ops.