How to fix "ollama launch openclaw error: unknown integration"

You ran the one command path to a local model with OpenClaw and hit:

ollama launch openclaw
Error: unknown integration: openclaw

ollama launch is Ollama's shortcut to install and wire tools against your local daemon. unknown integration means the Ollama binary you invoked does not register openclaw as a launch target. That usually means an outdated Ollama build, or an old ollama earlier on your PATH.

Step one: upgrade Ollama to 0.17 or newer

OpenClaw onboarding through ollama launch landed in Ollama v0.17.0 (February 2026). Older packages print unknown integration because the subcommand table never included OpenClaw.

Check what runs:

ollama --version
which ollama

If the version is below 0.17, update from ollama.com/download or your OS package channel, restart the Ollama app or ollama serve, then retry:

ollama launch openclaw --model glm-4.7-flash

Official flow from Ollama's OpenClaw integration page: install OpenClaw via npm when missing, show a first launch security notice, pick a model, write the provider block, install the gateway daemon, and open the TUI. Headless installs use:

ollama launch openclaw --model kimi-k2.5:cloud --yes

The legacy name still works on supported builds:

ollama launch clawdbot

When version and PATH look correct but the error persists, compare which -a ollama on macOS and Linux. Homebrew, the desktop app, and a manual install can each ship a different binary.

What a successful launch configures

Ollama's launcher points OpenClaw at the native Ollama HTTP API, pulls the model if needed, and sets your primary model. Cloud models can enable bundled Ollama web search; local web search may require ollama signin per the integration docs. To change models without the full TUI:

ollama launch openclaw --config

The Ollama blog walkthrough lists prerequisites: Ollama 0.17+, Node for npm global install, and macOS or Linux (Windows via WSL for the OpenClaw CLI path).

Step two: manual provider setup

Plenty of working setups predate ollama launch. Manual wiring also avoids the follow on Unknown model errors when the launch helper and your gateway version disagree. Follow the OpenClaw Ollama provider docs.

If Ollama itself is new to you, IBM Technology's overview installs it on macOS, Windows, or Linux, runs a model with one command, and shows the local server on port 11434, which is the daemon the provider block below points its baseUrl at.

Start the daemon and pull a tool capable model. Small chat only tags such as phi3:mini struggle with agent tool loops:

ollama serve
ollama pull qwen3-coder:30b
ollama list

Add the provider to ~/.openclaw/openclaw.json:

{
  models: {
    providers: {
      ollama: {
        apiKey: "ollama-local",
        baseUrl: "http://127.0.0.1:11434",
        api: "ollama",
        models: [{ id: "qwen3-coder:30b", contextWindow: 65536 }],
      },
    },
  },
}

Three details matter:

No /v1 on baseUrl. http://127.0.0.1:11434/v1 forces OpenAI compatible mode. Under streaming, tool call deltas can drop and the model may emit raw JSON in chat. OpenClaw's native integration uses /api/chat. This behavior is documented in the provider guide and tracked historically as ollama/ollama#5769.

Set api: "ollama" so the gateway uses the native path instead of guessing OpenAI compatibility.

Model ids match ollama list exactly, colon included (qwen3-coder:30b). Do not prefix with ollama/ in the id field when the provider key is already ollama.

Restart and verify:

openclaw gateway restart
openclaw doctor --deep

Cloud and hybrid Ollama modes

Recent OpenClaw onboarding supports three shapes, and they come from openclaw onboard rather than from ollama launch alone.

Remote Ollama hosts need a reachable baseUrl and credentials when the host is public or Ollama Cloud.

Unknown model errors

After launch or manual edit, you may see:

FailoverError: Unknown model: ollama/qwen3.5:4b. Ollama requires authentication to be registered as a provider. Set OLLAMA_API_KEY="ollama-local" (any value works) or run "openclaw configure".

OpenClaw registers the Ollama provider only after it sees an auth marker, even though the daemon accepts anonymous local calls:

export OLLAMA_API_KEY="ollama-local"

Either set OLLAMA_API_KEY only and leave models.providers.ollama undefined so OpenClaw auto discovers models from the daemon, or define the full provider block with baseUrl, api, and models and skip auto discovery. Mixing a half filled block (only apiKey, no baseUrl or models) fails schema validation. Registration bugs in older releases were fixed in openclaw/openclaw#61209; upgrade OpenClaw before you rewrite config repeatedly.

connection refused at this stage means nothing listens on 11434. Confirm with curl -sS http://127.0.0.1:11434/api/tags and start ollama serve.

Ollama on another host or in Docker

When the daemon runs on another machine or in a container, point baseUrl at the reachable host rather than only 127.0.0.1. A LAN address or a published Docker port works if the gateway process can reach it. The thing to keep in mind while you do that is that Ollama answers on port 11434 with no authentication of its own, so anything that can reach the port can list your models, run inference on your GPU, pull new models onto your disk, and delete what is there.

That is why Ollama binds to 127.0.0.1 out of the box, and it is a good default to leave in place. When you need it reachable from another box, the clean way is to keep Ollama on loopback and reach it over an SSH tunnel, ssh -L 11434:127.0.0.1:11434 user@host and then point baseUrl at your own 127.0.0.1:11434, or to put a reverse proxy with authentication in front of it. Binding Ollama straight to 0.0.0.0 opens it to the whole network with nothing in the way, so reach for the tunnel or the proxy first. Public or Ollama Cloud endpoints need a real API key in OLLAMA_API_KEY or in the provider block, as described in the provider docs.

Inside Docker Compose, bind Ollama's port to the host or attach OpenClaw and Ollama to the same user defined network, then set baseUrl to http://ollama:11434 (service name) from the OpenClaw container. Test from inside that container with curl http://ollama:11434/api/tags before you restart the gateway.

Tools not firing

If replies work but tools never fire, re check baseUrl for a /v1 suffix and swap to a model trained for function calling (qwen3-coder, glm-4.7-flash, hermes3, and similar tags from the Ollama library). Run openclaw doctor --deep after changes.

Memory embeddings using Ollama as a provider can show CLI probe errors separate from chat; see openclaw/openclaw#66077 if memory status --deep disagrees with working memory_search.

Local or managed

Ollama fits when data and inference should stay on your hardware or offline. Agent grade local models want substantial GPU memory, and multi step tool use still differs from current hosted models from OpenAI, Google, and Anthropic for many workflows.

If you reached for Ollama mainly to skip API keys and token billing rather than to keep everything local, Operator.io runs OpenClaw as a managed service with model usage included in the plan: no daemon, no openclaw.json provider block, no GPU purchase. See pricing for a trial. If local and private is the goal, upgrade Ollama to 0.17+, run ollama launch openclaw, or use the manual native provider block above without /v1 on the URL.