Can OpenClaw Run on a Local Model? Ollama Setup Tested

Short answer: yes, and it is now a one-line setup. Ollama 0.32.8 (10 August 2026) added ollama launch openclaw --model muse-glimmer, and OpenClaw ships Ollama, LM Studio, vLLM and SGLang as first-class providers. The honest hardware floor is 24GB VRAM for a 30B-class agent model — muse-glimmer is an 18GB download at Q4_K_M per its Ollama tag listing. Below 16GB it runs, but tool-call reliability is what degrades, not speed.

OpenClaw was sitting at roughly 386,600 stars on GitHub when we checked on 18 August 2026 — a figure that moves every day, so read it as scale rather than as a current number. It is MIT-licensed (the LICENSE file opens "MIT License / Copyright (c) 2026 OpenClaw Foundation", though GitHub's detector labels the repo "Other"). The package version is 2026.8.1. That combination — enormous install base, permissive licence, and a genuine local-model path — is why this page exists. The rest of it is the exact config, the model that fits your card, and the parts nobody tells you until you have already wasted an evening.

---

What OpenClaw Actually Is

It is a personal AI assistant that runs on your own devices and plugs into the messaging channels you already use, brokered through a local Gateway. That is the project's own framing, and it matters for the hardware question.

A coding agent is bursty: you ask, it works, it stops. OpenClaw is always on. It sits there, receives messages, decides whether to act, calls tools, and feeds the results back into the next decision. That means the model behind it is doing long multi-turn tool loops, unattended, for hours. A model that scores well on a one-shot benchmark and falls apart on turn nine is worse than useless here — it will quietly do the wrong thing while you are asleep.

Install is a shell script on macOS, Linux and WSL2:

curl -fsSL https://openclaw.ai/install.sh | bash

Node version is a hard gate, not a suggestion. The repo's package.json pins >=22.22.3 <23 || >=24.15.0 <25 || >=25.9.0, and the docs name Node 26 as the recommended default. Those are unusually specific minimums within each major — a Node 22.19 install will refuse to run. The install script provisions Node for you when none is present, but it will not upgrade a Node you already have, which is exactly the case that bites. Check with node -v before you do anything else.

The harness itself needs essentially no GPU. Everything below is about the model.

---

Model Picks by VRAM Tier

On a 24GB card, run muse-glimmer (18GB, Q4_K_M). On 16GB, run gemma4:12b (7.6GB) or qwen3.5:9b (6.6GB) and accept less reliable tool loops. Under 12GB, treat OpenClaw as a chat assistant with light tooling, not an autonomous one.

Every size below is the download size from that model's own Ollama tag listing, checked directly. Download size is not the same as peak VRAM — context, KV cache and the runtime all sit on top, which is why the "fits" column is stricter than the raw number.

Two things in that table deserve their own paragraph.

nemotron-3.5-lightning is 25GB, not 18GB. NVIDIA's model was announced in Ollama 0.32.9 (11 August 2026) as "an open 30B mixture-of-experts model with 3B active parameters built for that execution layer of always-on agents… designed for harnesses like OpenClaw and Hermes Agent." That is a perfect description of this use case — but the default tag weighs 25GB, and so does the q4_K_M tag. It does not fit cleanly in 24GB. You are looking at partial offload to system RAM, which for a 3B-active MoE is more survivable than it would be for a dense model, but it is still a compromise. If you have exactly 24GB, muse-glimmer at 18GB is the less frustrating choice. If you want the NVIDIA family at large, our Nemotron 3 Ultra breakdown covers the top of that line.

MoE beats dense at this job for a given VRAM budget. Both muse-glimmer and nemotron-3.5-lightning are 30B total with a small active-parameter count, which is why they hold a lot of capability in an 18-25GB footprint and stay quick across many turns. For a broader view of what a 24GB card can hold, see our best Ollama models for 24GB VRAM picks.

---

Setup: Ollama

The fast path is one command; the manual path is four lines of config. Both work — but do not use Ollama's /v1 endpoint, which breaks tool calling.

The one-command path

ollama launch openclaw --model muse-glimmer

That is verbatim from the Ollama 0.32.8 release notes (10 August 2026), which added launch commands for OpenClaw and Hermes at the same time. Ollama pulls the model if you don't have it and starts OpenClaw pointed at it.

The guided path

openclaw onboard
openclaw models list --provider ollama
openclaw models set ollama/muse-glimmer

For a headless box, the docs give a non-interactive form:

openclaw onboard --non-interactive --accept-risk --skip-health \
  --auth-choice ollama \
  --custom-base-url "http://ollama-host:11434" \
  --custom-model-id "muse-glimmer"

--accept-risk and --skip-health are not optional in the docs' form of this command, and leaving them off is why the non-interactive path tends to stall waiting for a prompt nobody is there to answer. --custom-base-url and --custom-model-id genuinely are optional; omit them and you get the local default host and a suggested model.

The manual config

OpenClaw's config is JSON5. The provider block per the docs:

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",
        api: "ollama"
      }
    }
  }
}

And the default model:

{
  agents: {
    defaults: { model: { primary: "ollama/muse-glimmer" } },
  },
}

Three details that will save you an evening:

1. You do not need OLLAMA_API_KEY for a local box. This is the most-repeated bit of bad advice about OpenClaw + Ollama. The provider page is clear: loopback, private-network, .local and bare-hostname Ollama URLs need no real bearer token, and OpenClaw uses an internal ollama-local marker for them. A real key is required only for public remote hosts and https://ollama.com. There is even a reason not to set it blindly — a bare OLLAMA_API_KEY env value is read as the Ollama Cloud convention and is not sent to local or self-hosted hosts by default. Setting it does no harm; expecting it to fix a local connection failure will waste your evening.
2. api: "ollama", never the /v1 URL. The docs are blunt about it: pointing at http://host:11434/v1 breaks tool calling. Use the native API. If your agent chats happily but never fires a tool, this is your bug ninety percent of the time.
3. Raise the timeout. models.providers.<id>.timeoutSeconds is the knob, and the Ollama page suggests 300+ for cold starts on large models. An 18-25GB model loading from disk on first request will blow through a default timeout and look like a hang.

If Ollama is on a different machine on your LAN — a very common setup for an always-on assistant, with the GPU box in a cupboard — read our securing Ollama guide first. An unauthenticated Ollama on 0.0.0.0 is an open door.

---

Setup: LM Studio

LM Studio is the OpenAI-compatible route and it does use /v1, on port 1234. It also verifies your model is tool-trained before it will proceed — which is a feature.

Start the LM Studio server, then run openclaw onboard and pick LM Studio. Per the docs, setup automatically checks that your chosen model supports tool training and has at least 16K effective context. That check is the single most useful guardrail in the whole local-model story, because it stops you from wiring up a model that was never going to survive an agent loop.

{
  agents: {
    defaults: { model: { primary: "lmstudio/openai/gpt-oss-20b" } },
  },
}

Model IDs follow LM Studio's author/model-name format, and OpenClaw prepends the provider — so qwen/qwen3.5-9b becomes lmstudio/qwen/qwen3.5-9b. Default base URL is http://localhost:1234/v1; for a remote box use the reachable address, e.g. http://gpu-box.local:1234/v1. If LM Studio has auth enabled, export LM_API_TOKEN; leave it blank otherwise.

Two behaviours worth knowing. Token counting is recovered from llama.cpp metadata, because LM Studio does not always emit OpenAI-style usage data on streamed responses — so your token accounting will look slightly different from a cloud provider's. And JIT loading: set models.providers.lmstudio.params.preload: false to let LM Studio manage the model lifecycle itself instead of OpenClaw preloading. On a machine you also use for other things, that is usually what you want.

Verify connectivity before blaming OpenClaw:

curl http://localhost:1234/api/v1/models

Choosing between the two runtimes at all? Our Jan vs LM Studio vs Ollama comparison covers the trade-offs outside the agent context.

---

Setup: vLLM and SGLang

Both are supported as named providers with sensible localhost defaults — vLLM on http://127.0.0.1:8000/v1, SGLang on http://127.0.0.1:30000/v1.

{
  agents: {
    defaults: { model: { primary: "vllm/your-model-id" } },
  },
}

{
  agents: {
    defaults: { model: { primary: "sglang/your-model-id" } },
  },
}

The same models.providers.<id>.timeoutSeconds applies to these routes. This is the path to take if you already run a serving stack for other work and want OpenClaw to be one more client of it rather than a second copy of your weights on disk. It is also the path that scales past one user, which neither Ollama nor LM Studio is really designed for.

---

What Breaks Under 24GB

Small models do not get "a bit worse" at agent work. They fail in a specific, recognisable way: the tool call itself goes wrong, and the loop keeps running anyway.

Here is what actually degrades as you go down the tiers, in the order you will hit it:

• Tool-name hallucination. The model invents a plausible-sounding tool that does not exist, gets an error, and tries a variant of the same wrong name. Under 12GB this is the first thing you'll see.
• Dropped or malformed arguments. The right tool, called with a missing required field. The harness surfaces an error; a weak model often re-sends the same broken call rather than fixing it.
• Loop amnesia. By turn eight or nine the model re-runs something it already did, because the earlier result has slid out of an effectively short context. This is why the LM Studio route enforces a 16K effective-context minimum.
• Context truncation under long sessions. An always-on assistant accumulates history. A 9B model with a nominally large window still degrades in the middle of it long before a 30B does.

The mitigation on small hardware is to narrow the blast radius: expose fewer tools, keep sessions short, and don't grant unattended execution. An 8GB OpenClaw that answers questions and reads two files is genuinely useful. An 8GB OpenClaw with fifteen tools and shell access is a machine for generating confusing incidents.

If you want the general version of this problem — which local models can be trusted with function calls at all — that is our Ollama tool calling guide, and the ranked picks live in best Ollama models for tool calling.

---

Security: Always-On on Your Own Box

Read this section before you leave OpenClaw running. Running the model locally fixes the privacy problem; it does not fix the agency problem.

OpenClaw's own security guide is refreshingly direct about its trust model: it is built for a single trusted operator per gateway, and it states that OpenClaw "is not a hostile multi-tenant security boundary for multiple adversarial users sharing one agent or gateway." For adversarial environments the guidance is to split trust boundaries entirely — separate gateway, separate credentials, ideally separate OS users or hosts.

The default that surprises people: host command execution on the gateway is allowed without approval prompts. The docs describe this as intentional single-operator UX rather than a vulnerability. It is still a thing you should know before you connect a messaging channel to it.

The controls that exist:

• Identity: DM pairing by default, allowlists, or open access only via explicit opt-in. Per-channel and per-group policies.
• Gateway auth: token or password.
• Sandboxing and tool policy: optional tool sandboxing with Docker/Podman backends, plus exec approvals and interpreter allowlists. The docs' own recommendation for untrusted input is a read-only or tool-disabled "reader" agent that summarises the content before your main agent sees it — a pattern worth copying.
• Audit: run openclaw security audit after config changes and before exposing anything to a network.

On prompt injection, the docs cite a 2026 crowdsourced arena of 272,000 attacks across 41 agent scenarios, scored only when the agent both executed the harmful action and hid it from the user. Two things to hold onto: every headline figure they quote is for a frontier hosted model, not a local one, and the docs concede in the same breath that adaptive human attackers still succeed above 80% against state-of-the-art defenses once they tailor the attack. Smaller and older models, the docs say plainly, are markedly easier to steer. The practical reading: assume the model can be manipulated and design the blast radius accordingly. Tool allowlists and sandboxing are doing more work than model choice is.

Worth knowing that this is enough of a real problem that NVIDIA ships a stack for it. NemoClaw (github.com/NVIDIA/NemoClaw, Apache-2.0, ~22,200 stars as of 18 August 2026) describes itself as running "agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference." If you are deploying this beyond your own laptop, it is worth a look.

---

Local vs the Cloud Route

Local wins on privacy, cost and control. The cloud route still wins on tool-call reliability and injection resistance, and pretending otherwise would waste your time.

Genuinely better locally:

• Nothing leaves the box. For an assistant wired into your messages, calendar and files, this is the whole argument, and it is a strong one.
• No per-token cost on an always-on process. An agent that idles, polls and reacts all day is a bad shape for metered billing.
• No rate limits, no deprecations. The model you tested against is the model you have next year.
• Works offline, which for a home assistant is not a gimmick.

Genuinely worse locally:

• Tool-call reliability. A 30B local model is good. Frontier hosted models are still better at not mangling a call on turn twelve.
• Prompt-injection resistance. OpenClaw's security docs explicitly tie injection resistance to model choice, and the figures they cite are for frontier hosted models. A 9B local model is not in that conversation.
• Cold-start latency. Loading 18-25GB of weights takes real seconds. This is why the docs suggest 300+ second timeouts.
• Your electricity bill and a GPU that is now busy. If you game on the same card, you'll notice.

The pragmatic setup a lot of people land on: local model for everything routine, with the config ready to switch to a hosted provider for the occasional task that needs it. OpenClaw supports 60+ providers, so that switch is a config line, not a migration. If you are still choosing hardware for this, our local AI agent hardware guide and the hardware hub are the places to start.

---

Verdict

1. Yes, OpenClaw runs on a local model, and the setup is no longer fiddly. ollama launch openclaw --model muse-glimmer is a single command, added in Ollama 0.32.8 on 10 August 2026.
2. 24GB VRAM with muse-glimmer (18GB, Q4_K_M) is the sweet spot. It is the largest genuinely comfortable fit on a consumer card, and Meta built it for exactly this.
3. nemotron-3.5-lightning is the better-targeted model and the worse fit. 25GB against a 24GB card means offload. Take it if you have 32GB.
4. Do not use Ollama's /v1 endpoint. Native API, api: "ollama", or your tools silently never fire.
5. Under 16GB, scale down the agency, not just the model. Fewer tools, shorter sessions, no unattended execution.
6. Sandbox before you leave it running. Host exec is unprompted by default, and that is by design.

---

Sources

• github.com/openclaw/openclaw — README, LICENSE (MIT, OpenClaw Foundation), package.json Node engine range, version 2026.8.1, star count
• docs.openclaw.ai — model-provider concepts, Ollama and LM Studio provider pages, gateway security guide
• Ollama release notes — v0.32.7 through v0.32.11 (Muse Glimmer, launch commands, Nemotron 3.5 Lightning)
• ollama.com/library — tag listings and download sizes for muse-glimmer, nemotron-3.5-lightning, qwen3.5 and gemma4
• github.com/NVIDIA/NemoClaw — Apache-2.0 security and management stack for always-on agents

Model capability descriptions ("built for always-on agents", "optimized for tool use") are vendor claims from the Ollama model listings and release notes, not our measurements. Download sizes are read directly from the tag listings.

---

FAQ