Openclaw is kinda slow | Friends of the Crustacean 🦞🤝 | Page 1

pure oracle Feb 28, 2026, 11:22 PM

#

So I setup openclaw to use Ollama. When I use ollama directly it takes 10 seconds. When I use openclaw it takes 1 minute or more. I'm using openclaw from the web browser and direct terminal. Does not make a difference what I use they are all really slow. I don't have any plugins/skills currently setup. I also do not have any other models listed in the config that could cause timeouts.

clear ferryBOT Feb 28, 2026, 11:22 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

round shadowBOT Feb 28, 2026, 11:24 PM

#

A 10s ollama run … vs ~60s in OpenClaw usually means OpenClaw is not actually hitting Ollama immediately, or it’s sending way more context (history + system prompt + tool schemas) than your direct Ollama test.

A few quick checks to pinpoint which one it is:

1) Version + status dump (fastest way to debug)

Please paste:

openclaw --version
openclaw status --all

(status --all is designed to be shareable; it redacts secrets.)

2) Is it waiting ~60s before doing anything? (fallback/timeout)

Run this in one terminal:

#

openclaw logs --follow

Then send a single short message (“hi”) and watch the logs. We’re looking for whether it:

tries another provider/model first and only falls back to Ollama after a timeout, or
goes to Ollama right away but the request itself takes forever.

Docs for logs: https://docs.openclaw.ai/help/faq#where-are-logs

3) Remote-mode / wrong host (super common)

If your Gateway is on a different machine than where Ollama is running, http://127.0.0.1:11434 points to the gateway host, not your laptop — which can cause long timeouts.

Paste these (they’re safe):

#

openclaw config get gateway.mode
openclaw config get models.providers.ollama
openclaw config get agents.defaults.model

4) “Legacy OpenAI-compatible” Ollama mode can feel extra bad

If your Ollama config uses a /v1 baseUrl + api: "openai-completions", you’re in the legacy compatibility path, which can break/disable streaming+tools and make everything feel slower.

Ollama provider doc: https://docs.openclaw.ai/providers/ollama

5) Make it an apples-to-apples test

OpenClaw includes chat history by default. Try a fresh session (/new in the UI/CLI), then ask one short question again. If that drops back near ~10s, it’s mainly prompt size/history, not connectivity.

If you paste the --version + status --all + a small log snippet around one slow request, I can tell you which bucket you’re in and what to change.

pure oracle Feb 28, 2026, 11:30 PM

#

2026.2.26

round shadowBOT Feb 28, 2026, 11:30 PM

#

Nice — 2026.2.26 is recent enough that we can debug this pretty cleanly.

A consistent ~60s slowdown (vs 10s direct) usually points to connection / wrong host / IPv6→IPv4 fallback, not “Ollama is slower under OpenClaw”.

1) Paste this (redacts secrets)

openclaw status --all

2) Verify the Gateway can reach Ollama from where the Gateway runs

On the machine that runs the Gateway, run:

time curl -s http://127.0.0.1:11434/api/tags >/dev/null

If this takes ~60s (or hangs), OpenClaw will too.

#

If it’s instant, then it’s likely prompt/context size or streaming/tool-mode issues.

3) Check if you’re accidentally in remote mode / wrong “localhost”

Paste:

openclaw config get gateway.mode
openclaw config get models.providers.ollama
openclaw config get agents.defaults.model

If your Gateway is on a different machine than Ollama, 127.0.0.1:11434 will be the gateway machine, not your Ollama box.

4) Common “1 minute” fix: avoid `localhost` (IPv6 timeout)

If your config uses baseUrl: "http://localhost:11434", switch it to 127.0.0.1:
http://127.0.0.1:11434

#

(IPv6 ::1 failing first often looks exactly like a ~60s delay.)

5) Log a single slow request

Run in one terminal:

openclaw logs --follow

Send one short message, then paste the few lines around the LLM request showing duration.

Docs that match the above:

Logs: https://docs.openclaw.ai/help/faq#where-are-logs
Ollama provider: https://docs.openclaw.ai/providers/ollama

If you paste (1) + (2) + (3), I can tell you which bucket it is and the exact config change to fix it.

pure oracle Feb 28, 2026, 11:31 PM

#

! Port 18789
  Port 18789 is already in use.
  - pid 28382 keddyc: openclaw-gateway (127.0.0.1:18789)
  - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown

round shadowBOT Feb 28, 2026, 11:31 PM

#

That output isn’t the “slow Ollama” issue yet — it’s OpenClaw telling you the Gateway is already running on port 18789 (pid 28382), so when you try to start another gateway instance it refuses.

That can lead to confusing behavior (you think you’re testing one process, but you’re talking to another), so let’s first make sure we’re measuring the right thing, then isolate the 60s delay.

1) Confirm which gateway you’re actually talking to

Paste:

openclaw gateway status
openclaw status --all

2) Confirm OpenClaw is really using Ollama (and not timing out then falling back)

Paste:

#

openclaw models status --plain

This will show the resolved primary + fallbacks.

Docs: https://docs.openclaw.ai/cli/models

3) Test Ollama latency from the gateway host (this is the key)

On the same machine where the gateway runs:

time curl -s http://127.0.0.1:11434/api/tags >/dev/null

If this is slow/hangs, OpenClaw will be slow too.

#

4) Very common 60s culprit: `localhost` (IPv6) vs `127.0.0.1`

If your Ollama provider baseUrl is http://localhost:11434, switch to:

http://127.0.0.1:11434

To check what you have, paste:

openclaw config get models.providers.ollama

(Ollama docs mention the expected baseUrl + native /api/chat path: https://docs.openclaw.ai/providers/ollama)

Once you paste the outputs from (1)–(3), it’ll be obvious whether you’re hitting the wrong gateway process, doing a provider fallback timeout, or actually seeing slow HTTP to Ollama.

pure oracle Feb 28, 2026, 11:33 PM

#

user@24d:~/.openclaw/workspace$ openclaw config get gateway.mode

🦞 OpenClaw 2026.2.26 (bc50708) — The only bot that stays out of your training set.

local
user@24d:~/.openclaw/workspace$ openclaw config get models.providers.ollama

🦞 OpenClaw 2026.2.26 (bc50708) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

{
"baseUrl": "http://127.0.0.1:11434/v1",
"apiKey": "OPENCLAW_REDACTED",
"api": "ollama",
"models": [
{
"id": "qwen3:8b",
"name": "qwen3:8b",
"reasoning": true,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 40960,
"maxTokens": 8192,
"api": "ollama"
}
]
}
user@24d:~/.openclaw/workspace$ openclaw config get agents.defaults.model

🦞 OpenClaw 2026.2.26 (bc50708) — I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

{
"primary": "ollama/qwen3:8b"
}

round shadowBOT Feb 28, 2026, 11:36 PM

#

Cool, this config explains the “~1 minute” pretty well.

You’re running qwen3:8b and you’ve told OpenClaw it has a 40,960 token context window:

"contextWindow": 40960

OpenClaw’s native Ollama path (api: "ollama") will pass that through to Ollama as num_ctx (context size) on every request. That can make Ollama dramatically slower than your normal ollama run … test (which typically runs with a much smaller default num_ctx unless you override it).

Also, you marked the model as:

"reasoning": true

In OpenClaw, that tends to default the session into “reasoning on”, which can make Qwen3 produce a lot more “thinking” text / tokens (more time).

#

Try this quick “speed sanity” config tweak

Run these, restart the gateway, and test again:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"
openclaw config set models.providers.ollama.models[0].contextWindow 8192
openclaw config set models.providers.ollama.models[0].reasoning false
openclaw gateway restart

(You can try 16384 instead of 8192 if you want, but start smaller to confirm the cause.)

If it’s still slow: reduce tool-schema bloat (big win for local 8B)

Even with “no plugins”, OpenClaw can still include a lot of tool definitions in the prompt. For a fast chat test:

#

openclaw config set tools.profile minimal
openclaw gateway restart

Then try a fresh /new session and a short prompt.

If those changes drop you back near your 10s baseline, we can re-enable stuff step-by-step (bigger context, more tools) until you find the sweet spot.

pure oracle Feb 28, 2026, 11:44 PM

#

are you able to understand this?

round shadowBOT Feb 28, 2026, 11:44 PM

#

Yep. Your config + symptoms make sense.

What I see:

You’re running local gateway (gateway.mode: local) and the agent is pinned to ollama/qwen3:8b.
Your Ollama provider entry sets contextWindow: 40960. In OpenClaw’s native Ollama path, that gets sent to Ollama as num_ctx on every request. A big num_ctx can easily turn a “~10s” prompt into “~60s+”, even for short questions, because the model is configured to reserve/work with a much larger context.
You also marked the model reasoning: true, which can increase generated tokens (more thinking/output), again increasing latency.
The baseUrl: "http://127.0.0.1:11434/v1" is not the main issue here: OpenClaw strips /v1 for the native /api/chat call path.

So yes: I understand it, and the next step is to test with smaller context + no reasoning:

openclaw config set models.providers.ollama.models[0].contextWindow 8192
openclaw config set models.providers.ollama.models[0].reasoning false
openclaw gateway restart

#Openclaw is kinda slow

1) Version + status dump (fastest way to debug)

2) Is it waiting ~60s before doing anything? (fallback/timeout)

3) Remote-mode / wrong host (super common)

4) “Legacy OpenAI-compatible” Ollama mode can feel extra bad

5) Make it an apples-to-apples test

1) Paste this (redacts secrets)

2) Verify the Gateway can reach Ollama from where the Gateway runs

3) Check if you’re accidentally in remote mode / wrong “localhost”

4) Common “1 minute” fix: avoid localhost (IPv6 timeout)

5) Log a single slow request

1) Confirm which gateway you’re actually talking to

2) Confirm OpenClaw is really using Ollama (and not timing out then falling back)

3) Test Ollama latency from the gateway host (this is the key)

4) Very common 60s culprit: localhost (IPv6) vs 127.0.0.1

Try this quick “speed sanity” config tweak

If it’s still slow: reduce tool-schema bloat (big win for local 8B)

4) Common “1 minute” fix: avoid `localhost` (IPv6 timeout)

4) Very common 60s culprit: `localhost` (IPv6) vs `127.0.0.1`