OpenClaw Keeps Using Claude Instead of Your Local Ollama Model — Fix

OpenClaw keeps calling Claude because the default chat model was never changed to your Ollama model, or because an environment variable is silently overriding your config. Set agents.defaults.models.chat to your local model id (for example ollama/qwen3:30b), confirm no OPENCLAW_ or ANTHROPIC_ env var is forcing a cloud model, and restart the gateway. Verify with openclaw models status and openclaw config get agents.defaults.models.

This is one of the most common “but I configured Ollama” complaints, and it is almost never a bug. OpenClaw resolves a model from a short chain of config sources, and an Anthropic model often sits higher in that chain than the local model you thought you set. Below are the three places it lives, in the order you should check them.

The 30-second fix

Run these in order. For most people the first command alone solves it.

# 1. Set your Ollama model as the default chat model
openclaw config set agents.defaults.models.chat "ollama/qwen3:30b"

# 2. Check for environment variables that override config
env | grep -i anthropic
env | grep -i openclaw

# 3. Restart the gateway so the new config is loaded
openclaw gateway restart

# 4. Confirm what OpenClaw will actually use
openclaw config get agents.defaults.models
openclaw models status

If openclaw models status now lists your ollama/ model as available and openclaw config get agents.defaults.models shows it as the chat default, you are done. If it still resolves to an Anthropic model, work through the rest of this page — one of the three layers below is still winning.

Why this happens: the model-resolution chain

OpenClaw picks a model from more than one place, and the highest-priority source wins. When you think you “set up Ollama” but only pulled a model and pointed Ollama at it, you changed the provider, not the default model OpenClaw asks for. Those are different settings.

In practice the order that matters is:

1. Environment variables (highest priority) — things like ANTHROPIC_API_KEY plus an Anthropic default, or an OPENCLAW_* override baked into your shell or a Docker env.
2. Per-agent model config — an individual agent can pin its own chat model and ignore the global default.
3. agents.defaults.models.chat — the global default every agent inherits unless overridden.

If you only edited the global default but an env var or a per-agent setting still names an Anthropic model, OpenClaw keeps using Claude. You have to clear the higher-priority source, not just set the default.

Layer 1: Make sure Ollama is running and the model is pulled

Before blaming OpenClaw, confirm the local model actually exists and is reachable. If OpenClaw tries ollama/qwen3:30b and Ollama can’t serve it, OpenClaw may fall back to a cloud model rather than fail outright.

# Is the Ollama daemon up?
ollama list

# Is the exact model+tag you referenced present?
# (the tag after the colon must match exactly)
ollama pull qwen3:30b

The single most common mistake here is a tag mismatch. ollama list shows the real tag. If it lists qwen3:30b but your OpenClaw config says ollama/qwen3 (no tag) or ollama/qwen3:30b-instruct, the id won’t resolve. Copy the tag verbatim. The model id you give OpenClaw is always provider/model, so the provider prefix ollama/ plus the exact name from ollama list.

For a deeper look at which local models actually behave well as the OpenClaw chat model — and which ones quietly break tool calling — see our best local models for OpenClaw writeup.

Not sure your machine can hold the model with room for OpenClaw’s own overhead? Match the model to your memory with our best local LLM by RAM guide.

Layer 2: Kill the environment override

This is the layer people miss most. Config files are only part of the story — environment variables can override what openclaw config set wrote. If env | grep -i anthropic returns an ANTHROPIC_API_KEY and OpenClaw is configured to prefer the Anthropic provider when a key is present, you’ll keep getting Claude no matter what your default says.

# What env is your shell exporting?
env | grep -i anthropic
env | grep -i openclaw

Look for anything that names a cloud provider or model. If you find an OPENCLAW_* variable pinning a model, remove it from wherever it’s set (~/.zshrc, ~/.bashrc, a .env file, or your service manager) and open a fresh shell.

In Docker, the gateway runs in its own environment, so check inside the container, not just your host shell:

# Inspect the gateway container's environment
docker exec <container_name> env | grep -i -E 'openclaw|anthropic'

If a model or provider is being injected via docker-compose.yml, edit it there and re-create the container. Host-side env changes won’t touch what’s baked into the container.

Note: having an ANTHROPIC_API_KEY set is fine if you also use cloud models. The problem is only when it causes the default to resolve to Anthropic. Setting agents.defaults.models.chat to your ollama/ model explicitly is what pins the local model regardless of which keys exist.

Layer 3: Per-agent overrides beat the default

If the global default is correct and there are no rogue env vars, but one agent still uses Claude, the culprit is a per-agent model setting. Per-agent config sits above agents.defaults, so an agent with its own chat model ignores the default entirely.

# See the resolved default and per-agent models
openclaw config get agents.defaults.models

If an individual agent pins a chat model, point that agent’s chat model at your Ollama id the same way you set the default. The exact key path is per-agent rather than under agents.defaults, but the value format is identical: ollama/qwen3:30b.

Verify it actually switched

Don’t trust the config alone — confirm what the gateway resolves at request time.

# 1. Which models resolve, and are they reachable?
openclaw models status

# 2. What is the default chat model now?
openclaw config get agents.defaults.models

# 3. Watch a live request and see the model that gets used
openclaw logs --follow

Send one message while openclaw logs --follow is running. The model id in the logs should be your ollama/ model. If the logs still show an anthropic/ model, the gateway hasn’t reloaded — run openclaw gateway restart and try again. If openclaw models status shows your local model as unavailable, jump back to Layer 1: Ollama is down or the tag is wrong.

If you want a single command that surfaces config, gateway, channel, and model state at once, openclaw status --all and openclaw doctor are the broad-strokes diagnostics described in the full troubleshooting guide.

Quick reference

Need help?

If you’ve worked through all three layers and OpenClaw still routes to Claude, we can screen-share and trace your model-resolution chain end to end. See how 1:1 OpenClaw training works.