OpenClaw + Ollama (2026): Setup, Best Models and Differences

We tested every recommended Ollama model with OpenClaw. Some chat fine. Many call tools fine — once you fix the one config setting almost every guide gets wrong.

OpenClaw + Ollama works for both chat and tool calling when you point the gateway at Ollama's native /api/chat endpoint. If your baseUrl ends in /v1, tool calls drop silently (the /v1 OpenAI-compat path doesn't preserve tool-call delta chunks under streaming — the bug originally tracked in GitHub Issue #5769). Drop the /v1 suffix, restart the gateway, and tool calls flow through correctly. This guide covers the working config, the three gotchas that still trip people up, model picks for 2026, and the cost trade-off vs. cheap cloud APIs. Checked against Ollama 0.40.3 and OpenClaw 2026.10.2 on 13 October 2026.

I spent a Saturday afternoon trying to get Qwen3 8B running through Ollama as my OpenClaw agent's primary model. Zero API costs. Full privacy. The dream setup.

The model loaded. The gateway started. I typed "hello." It responded instantly. Then I asked it to check my calendar. The agent generated a narrative essay about how it would check my calendar if it could, instead of actually calling the calendar tool. Beautiful prose about web searching, zero actual web searches.

Three hours later I found the actual cause: my config pointed at http://localhost:11434/v1. The /v1 path is OpenAI-compatible but drops tool-call deltas. The native /api/chat path doesn't. One config change, and the agent started calling tools normally.

Here's the full picture: what works, what still breaks, the three gotchas that eat hours, and when Ollama is — and isn't — worth the effort.

OpenClaw vs Ollama: they are not the same kind of thing

People search "OpenClaw vs Ollama" as if you pick one. You don't. OpenClaw is the agent; Ollama is the model server. You run OpenClaw on Ollama: OpenClaw decides what to do, and every time it needs a model to think, it sends the request to Ollama on port 11434. Swap Ollama for a cloud API and OpenClaw still works; remove OpenClaw and Ollama is just a model waiting for prompts. You can also skip running the agent yourself and connect Ollama to a cloud agent with BetterClaw Desktop.

In more detail:

• Ollama runs models. It downloads open-weight models, loads them on your CPU, GPU or Apple Silicon, and serves them over a local HTTP API on port 11434. It doesn't read your email, remember your preferences or run scheduled jobs.
• OpenClaw is the agent. It holds the conversation, the memory, the skills and the chat channels, and it calls a model whenever it needs one. That model can be a cloud API or a local one served by Ollama.

So "OpenClaw + Ollama" means OpenClaw is the agent and Ollama is its model backend. Everything below is about wiring those two together. If you want your local models to power agents that run in the cloud instead, BetterClaw Desktop bridges Ollama, LM Studio or llama.cpp on your computer to BetterClaw's cloud agents (macOS 13 or later on Apple Silicon, plus Windows and Linux).

One thing to watch: OpenClaw's 2026.10.5 beta adds a native worker inference runtime with Gateway dispatch ("worker-local inference"). That's beta only and not in the current stable release, 2026.10.3. For now, Ollama is still the standard way to give OpenClaw a local model.

Native API vs /v1: where tool calls actually live or die

The root cause of most "Ollama tool calling broken" reports is the endpoint your OpenClaw Ollama provider points at, not Ollama itself. GitHub Issue #5769 originally documented streaming dropping tool calls on the OpenAI-compatible /v1 path. That's the path that's broken — and it's still broken — because Ollama's /v1 streaming doesn't emit tool_calls delta chunks correctly.

OpenClaw's native Ollama provider uses /api/chat instead and preserves tool calls under streaming. The official Ollama provider docs explicitly warn against using /v1 because it still breaks tool calling.

The working config

OpenClaw reads its config from ~/.openclaw/openclaw.json, which is JSON5 (comments and trailing commas are allowed). A minimal working setup sets the agent's default model and declares the Ollama provider:

{
  "agents": {
    "defaults": {
      "model": { "primary": "ollama/qwen3.8:27b" }
    }
  },
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434",
        "apiKey": "ollama-local",
        "api": "ollama",
        "models": [{
          "id": "qwen3.8:27b",
          "name": "qwen3.8:27b",
          "contextWindow": 65536
        }]
      }
    }
  }
}

Four things matter here:

1. No /v1 suffix on baseUrl. If you've followed an older guide that wrote http://localhost:11434/v1, drop the /v1.
2. api: "ollama" explicitly selects the native provider. Don't rely on auto-detection.
3. Model id uses the exact Ollama tag. Use qwen3.8:27b (with colon), not qwen3.8-27b (hyphen) — and not prefixed with ollama/ inside the provider block, since the provider is already declared. Give each model a name as well as an id; custom provider models need both.
4. agents.defaults.model.primary uses provider/model. That's where the ollama/ prefix goes: ollama/qwen3.8:27b. Older guides show a top-level "agent": { "model": ... } key; that isn't a valid OpenClaw config shape.

After saving, restart OpenClaw and verify with openclaw doctor --deep. openclaw models status shows which models OpenClaw sees, and openclaw config get prints the config it actually loaded. If your version of OpenClaw is recent enough to ship the native provider as default, you're done.

How to verify Ollama is actually being used (not silent cloud fallback)

OpenClaw can silently fall back to a cloud provider if your Ollama config isn't recognized — meaning your agent looks like it's working but is quietly burning your Anthropic credits. To confirm Ollama is in the loop:

# 1. From the OpenClaw gateway logs, watch a request go out
openclaw logs --follow --filter provider=ollama

# 2. Or hit Ollama's own request log
tail -f ~/.ollama/logs/server.log
# A live request from OpenClaw shows up as POST /api/chat with your model name.

If openclaw doctor --deep reports the Ollama provider as healthy and you see live /api/chat requests hit Ollama when your agent runs, the config is wired correctly.

Falling back to the older workaround

If you're stuck on an OpenClaw build that pre-dates the native /api/chat provider, the community workaround is to patch streaming off when tools are present:

const shouldStream = !(context.tools?.length && isOllamaProvider(model));

This requires modifying OpenClaw's source and rebuilding. Updating to a current release and switching baseUrl is the easier path.

For a detailed breakdown of all five ways local models fail in OpenClaw (including discovery timeouts, WSL2 networking, and the CLI vs API confusion), our troubleshooting guide covers each failure mode.

What works well with OpenClaw + Ollama

Once you're on the native /api/chat provider with a tool-capable model, almost everything OpenClaw does works locally. Here are the parts you should expect to work cleanly.

Basic conversation

Ask questions, get answers, have discussions. The agent responds through whatever chat platform you've connected (Telegram, WhatsApp, Slack). If all you want is a private chatbot that runs on your hardware, Ollama delivers.

Memory and context

Ollama models maintain conversation context through OpenClaw's memory system. The agent remembers previous messages, stores preferences, and builds context over time. This works the same as with cloud models, and the same as it does on a hosted AI agent builder if you later decide the local hardware is not worth the maintenance.

SOUL.md personality

Your agent's personality configuration works normally with local models. Customize tone, behavior rules, and working context. The model follows the system prompt instructions.

Tool calling (on the native API + a tool-capable model)

With the native /api/chat provider and a model that was trained for function calling (qwen3-coder:30b, glm-4.7-flash, hermes3, gemma4:e4b, gpt-oss:20b, mistral:7b), tool calls flow through. Skills execute. Web searches happen. File operations land. You can verify by watching ~/.ollama/logs/server.log for the actual /api/chat requests as the agent runs.

Model switching mid-conversation

The /model command works with Ollama models. You can switch between local and cloud providers on the fly. Type /model ollama/qwen3-coder:30b for a quick local response, then /model anthropic/claude-sonnet-5-5 when you want the heavier reasoning ceiling of a cloud model.

This hybrid approach is one of the strongest uses of Ollama in OpenClaw: local for routine work and privacy-sensitive tasks, cloud for complex reasoning.

What still breaks (and what to do about it)

Tool calling on the /v1 OpenAI-compat path

This is the original "Ollama tool calling is broken" story, and it's still broken. If your baseUrl ends in /v1, the tool-call delta chunks get dropped on the streaming response and your agent narrates what it would do instead of doing it. Fix is the one above: drop /v1 from baseUrl and use the native provider.

Models that weren't trained for function calling

Even on the native provider, models like phi3:mini or older 3B-7B builds without explicit tool-calling training will fail with "model does not support tools" errors or by ignoring the tools entirely. See the "model does not support tools" fix for the full list of safe vs. unsafe model picks.

Sub-agent parallel processing at small model sizes

Sub-agents that need precise multi-step tool sequencing struggle on local models under ~30B parameters even when tool calling mechanically works. Reasoning, not protocol, is the limit at smaller sizes. Use a 30B-class model (or a cloud model) for orchestrator roles and keep the smaller local model for individual workers.

Browser relay

OpenClaw's browser automation requires precise, long sequences of structured tool calls to click elements, fill forms, and navigate pages. Local models can produce correct tool-call syntax but the format-fidelity over a long browser session is still well below cloud-model reliability. Most browser-relay workflows are better served by cloud models today.

Best model for OpenClaw on Ollama in 2026

An OpenClaw agent is only as good as its model's tool calling, so start from models that Ollama's own library tags with tools. As of 13 October 2026, these are the picks:

The RAM column is the model's download size from its ollama.com/library page (ranges cover the different quantizations Ollama lists). Treat it as a floor: the model's weights must fit in memory, and the context window and OpenClaw's system prompt need several GB on top. On Apple Silicon, Ollama also lists -mlx variants (qwen3.8:27b-mlx, gemma4:26b-mlx, gemma4:e4b-mlx).

ollama pull qwen3.8:27b
ollama pull gemma4:26b
ollama pull gemma4:e4b

Then set agents.defaults.model.primary to ollama/qwen3.8:27b (or ollama/gemma4:26b) as shown in the config above. If Qwen3.8 hangs mid-task as an agent, update Ollama first (the agent hang fix).

What about Ornith 1.5 35B? Its ollama.com/library page (ornith-1.5:35b, 23GB) carries only a vision tag, not tools, so we can't recommend it as an OpenClaw primary on Ollama until that changes. See our Ornith 1.5 setup guide for other ways to run it.

Other local models that work with OpenClaw

Beyond the top picks, these are the other models people run, with their trade-offs:

For agent workflows, plan for 30B+ parameters with at least 64K context window. Anything smaller struggles with OpenClaw's system prompts and multi-turn conversations.

One-command setup: Ollama 0.17+ (current release: 0.40.3) ships a launch subcommand that auto-installs and configures OpenClaw to use the local daemon:

ollama launch openclaw --model glm-4.7-flash

That picks the right native baseUrl, pulls the model if needed, and writes the provider config for you.

Apple Silicon notes

Since Ollama v0.40.0 (released 25 September 2026), models run on MLX on Apple Silicon by default: on M-series Macs, any model architecture the MLX runtime supports automatically runs on MLX instead of Ollama's own engine. The release notes name gemma4, qwen3.6 and qwen3.5 as newly covered, and Ollama's library lists -mlx tags for qwen3.8 and gemma4. You don't change anything in OpenClaw for this: the provider config stays the same, and the speed-up happens inside Ollama. Models MLX doesn't support still run on Ollama's engine with Metal acceleration. The current stable release is v0.40.3 (11 October 2026).

Either way, the unified-memory architecture changes the numbers: a 32GB M3 Pro or M4 Pro can comfortably run 30B-class models at q4 — the same models that need a 24GB discrete NVIDIA card on Linux/Windows. A Mac mini with 16GB unified memory handles 7B-14B models smoothly; the 24GB configuration unlocks the 30B tier. As of 13 October 2026, Apple sells the Mac mini with the M6 chip (16GB, 24GB or 32GB) or the M5 Pro chip (24GB or 64GB); check apple.com for current prices.

For guidance on choosing the right model for your specific use case, our model comparison covers cost-per-task data across local and cloud providers.

The three Ollama gotchas that waste hours

Beyond the tool calling bug, three configuration issues eat the most time.

Gotcha 1: Model discovery timeout

When OpenClaw starts, it tries to auto-discover Ollama models. If Ollama is slow (common when the model isn't pre-loaded), discovery times out silently. Your gateway starts. Your model is listed. But requests fail.

Fix: Pre-load the model before starting OpenClaw:

ollama run qwen3:8b
# Wait for "success," then Ctrl+C
openclaw gateway start

Or define models explicitly in your config to skip discovery entirely (shown above).

Gotcha 2: WSL2 networking

If you're running OpenClaw in WSL2 and Ollama on the Windows host (or vice versa), 127.0.0.1 doesn't resolve across the boundary. Your config says localhost. Your curl works. But OpenClaw can't reach Ollama.

Fix: Use the actual WSL2 IP from hostname -I. Or bind Ollama to 0.0.0.0 with OLLAMA_HOST=0.0.0.0:11434 ollama serve.

Gotcha 3: The CLI vs API confusion

GitHub Issue #11283 documents this bizarre behavior: you configure Ollama as a remote API provider with a baseUrl. OpenClaw should make HTTP API calls. Instead, it tries to execute ollama run as a shell command on your local machine. This happens when OpenClaw's model routing falls back to a cloud model that then tries to "help" by calling Ollama via CLI.

Fix: Make sure your Ollama model is explicitly defined in the models.providers section with api: "ollama" and is listed in the models array. Don't rely on auto-discovery for remote Ollama.

The honest cost comparison: Ollama vs cheap cloud providers

The appeal of Ollama is zero API costs. But "zero API costs" and "zero cost" are different things.

Running Ollama on hardware you own means electricity, hardware depreciation, and your time debugging issues. A base Mac mini (now on the M6 chip) running 24/7 consumes roughly $3-5/month in electricity. The machine itself depreciates over its useful life. At the high end, DGX-class hardware starts at $4,999 for the 64 GB DGX Spark, or $6,950 for the 128 GB model.

Meanwhile, cloud providers in 2026 remain cheap enough that the numbers rarely favors local on cost alone. Cheap models like DeepSeek V4.1 Flash (deepseek/deepseek-flash, $0.30 / $1.20 per million tokens at peak, $0.15 / $0.60 off-peak), Gemini 3.8 Flash ($0.75 / $3.75 through December 31, 2026, then $1.50 / $7.50) and Claude Haiku 5.5 ($0.10 / $0.50 for prompts up to 100K tokens) run a moderately active agent for a few dollars a month with reliable tool calling (prices per million input / output tokens, checked 13 October 2026). For up-to-date pricing across providers, see our cheapest cloud providers for OpenClaw breakdown.

The cheapest model isn't the one with the lowest per-token price. It's the one that can do the job. With native /api/chat working, local Ollama models can absolutely do the job for chat and many tool-calling tasks — the trade-off shifts from "tool calling vs. no tool calling" to "raw speed/quality vs. privacy and zero token costs."

If you'd rather skip the Ollama debugging entirely, BetterClaw runs your agent in the cloud with Telegram, Slack, Discord and Gmail built in, plus webhooks, 500+ connectors, unlimited skills and 28+ model providers via your own API key with no markup. Free plan: 1 agent, 100 credits a month, 3 connectors, no card.

When Ollama with OpenClaw makes sense

I'm not going to pretend Ollama is never the right choice. Three scenarios justify the setup.

Privacy-first deployments

If your data absolutely cannot leave your network, local models are the only option. Government, healthcare, legal, defense: these environments have compliance requirements that no cloud provider can satisfy. Local models have a lower reasoning ceiling than frontier cloud models, but with a tool-capable model on the native API, Ollama delivers complete data sovereignty.

Offline and air-gapped environments

No internet? No API calls. Ollama runs entirely locally. If you need an AI assistant in an environment without reliable connectivity, local models are it.

Hybrid heartbeat routing

Use Ollama for heartbeats (the 48 daily status checks that cost tokens on cloud providers) and a cloud model for everything else. Heartbeats don't require tool calling. They're simple status checks. Running them locally saves $4-15/month depending on your cloud model pricing.

{
  "agents": {
    "defaults": {
      "model": { "primary": "anthropic/claude-sonnet-5-5" },
      "heartbeat": { "model": "ollama/hermes3" }
    }
  }
}

For the full model routing setup, our intelligent provider switching guide covers the config patterns.

Where this leaves you

With native /api/chat working, the gap between local and cloud has narrowed for the subset of tasks that don't require frontier-level reasoning — but "narrowed" isn't "closed." Cloud models like Claude Sonnet 5.5 ($2 / $10 per million tokens) still outperform local models on complex multi-step reasoning, long-context accuracy, and prompt-injection resistance, and they're simply faster per-token on hosted GPUs. The practical answer is hybrid: cloud for the heavy stuff, local for privacy-sensitive tasks and high-volume background work like heartbeats.

If you want an agent without debugging streaming protocols or maintaining your own hardware, give BetterClaw a try. BetterClaw runs your agent in the cloud with Telegram, Slack, Discord and Gmail built in, plus webhooks, 500+ connectors, unlimited skills and 28+ model providers via your own API key with no markup. Free plan: 1 agent, 100 credits a month, 3 connectors, no card.

Frequently Asked Questions

Does OpenClaw work with Ollama local models?

Yes — for both chat and tool calling. Use OpenClaw's native Ollama provider (api: "ollama", baseUrl: "http://127.0.0.1:11434" with no /v1 suffix). The native /api/chat path preserves tool-call deltas under streaming. The legacy /v1 OpenAI-compat path drops them, which is the original cause of GitHub Issue #5769.

Why is my OpenClaw agent not calling tools when using Ollama?

Two likely causes. First: your baseUrl ends in /v1 — drop it. The native /api/chat path supports tool calling; the /v1 path doesn't. Second: your model wasn't trained for function calling (e.g., phi3:mini). Switch to a model Ollama's library tags with tools, like qwen3.8:27b, gemma4:26b or gemma4:e4b. Restart the gateway and run openclaw doctor --deep to confirm.

How does Ollama compare to cloud providers for OpenClaw?

Ollama gives you zero token costs and full data privacy; cloud providers give you higher reasoning ceilings and faster per-token latency on hosted GPUs. Cheap models like DeepSeek V4.1 Flash, Gemini 3.8 Flash and Claude Haiku 5.5 run a moderate agent for a few dollars a month. Most teams settle on hybrid: cloud primary, Ollama for heartbeats and privacy-sensitive tasks.

How do I set up Ollama with OpenClaw?

Easiest path: ollama launch openclaw --model glm-4.7-flash (Ollama 0.17+). Manual path: install Ollama, run ollama pull qwen3.8:27b, configure ~/.openclaw/openclaw.json with the Ollama provider (api: "ollama", baseUrl: "http://127.0.0.1:11434", no /v1, a model entry with both id and name, contextWindow: 65536) and set agents.defaults.model.primary to ollama/qwen3.8:27b. Restart and run openclaw doctor --deep.

Is running OpenClaw with Ollama cheaper than cloud APIs?

Usually not on cost alone. Ollama has zero token costs but needs capable hardware (a Mac mini with 24GB+ unified memory or a GPU-equipped desktop) and electricity. Cheap cloud providers run a full agent for a few dollars a month. Ollama wins for privacy, offline operation, and high-volume heartbeats — not for cost savings alone.

Which Ollama models work best with OpenClaw?

For agent workflows in 2026: qwen3.8:27b (18GB download, 256K context) and gemma4:26b (16-19GB download, 256K context), both tagged tools on ollama.com/library. Other options: glm-4.7-flash, qwen3-coder:30b (strong for code) and qwen3.6:35b-a3b. For 16GB machines: gemma4:e4b (6.6-9.5GB download), qwen3.5:9b or hermes3. Avoid models without a tools tag, such as phi3:mini, for agent work. Set context window to 64K+.