llm request failed | Friends of the Crustacean 🦞🤝 | Page 1

rough starBOT Apr 10, 2026, 1:31 PM

#

sinful frigateBOT Apr 10, 2026, 1:31 PM

#

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

rough starBOT Apr 10, 2026, 1:31 PM

#

jade plank Apr 10, 2026, 1:33 PM

#

that is my config file for my models, why can't I connect to it from telegram?

balmy escarpBOT Apr 10, 2026, 1:34 PM

#

That Ollama block itself looks basically fine:

native Ollama URL, no /v1, good
api: "ollama", good
models are explicitly defined, so OpenClaw will use exactly those entries

The catch is, this alone does not prove the failing run is actually using one of those models.

Please paste these next:

openclaw models status
openclaw config get agents.defaults.model
ollama list
openclaw status

#

And if you want the fastest isolate-the-problem check:

openclaw infer model run --model ollama/gemma4 --prompt "hi" --json

Why I’m asking:

if infer model run fails, it’s the Ollama/provider side
if it works, but normal chats still fail, it’s usually the selected model, session/tool pressure, or fallback routing
since models.providers.ollama is explicit, model IDs must match what ollama list shows exactly

Also, some local Ollama models can do plain chat but still fall over on full agent/tool turns, so the exact error text matters a lot. If you have it, paste the actual LLM request failed ... line too.

Docs:

#

https://docs.openclaw.ai/gateway/troubleshooting

#

Because Telegram is not connecting to Ollama directly, OpenClaw is.

The important bit is this:

baseUrl: "http://127.0.0.1:11434" means “connect to Ollama on the same machine as the OpenClaw gateway”
127.0.0.1 is always localhost of the gateway process, not your Telegram client, not your phone, not another server

So this works only if:

OpenClaw gateway and Ollama are running on the same host
the gateway was restarted after the config change
your default agent model is actually set to an ollama/... model

A few common gotchas:

Gateway on VPS / Docker / another machine + Ollama on your laptop
→ 127.0.0.1 is wrong there

#

provider is configured, but default model is still something else
Ollama is up locally, but the gateway service hasn’t reloaded the config yet

Please run these on the gateway host and paste them:

openclaw models status
openclaw config get agents.defaults.model
curl http://127.0.0.1:11434/api/tags
openclaw gateway restart
openclaw status

If gateway and Ollama are on different machines, change baseUrl to the host/IP that the gateway can actually reach. Prefer a private network or Tailscale, not exposing Ollama publicly.

Docs:

https://docs.openclaw.ai/providers/ollama

#

If you paste openclaw models status next, I can usually spot the problem pretty fast.

jade plank Apr 10, 2026, 1:39 PM

#

openclaw infer model run --model ollama/gemma4 --prompt "hi" --json
Error: Model override "ollama/gemma4" is not allowed for agent "main".

balmy escarpBOT Apr 10, 2026, 1:40 PM

#

Nice, that error is actually the clue.

OpenClaw did not reach Ollama yet.

openclaw infer model run reuses the normal agent runtime, and your main agent is rejecting the override because ollama/gemma4 is not in the allowed model list.

So the problem is likely:

agents.defaults.models is set as an allowlist
your Ollama models are not included there
Telegram is hitting that same agent policy

Please run:

openclaw config get agents.defaults.models

#

openclaw models list
openclaw config get agents.defaults.model

If agents.defaults.models exists, either:

add your Ollama models to it, and set one as primary, or
remove the allowlist if you don’t want model restrictions

Minimal example:

{
  agents: {
    defaults: {

#

      model: { primary: "ollama/gemma4" },
      models: {
        "ollama/gemma4": {},
        "ollama/qwen3-coder:latest": {}
      }
    }
  }
}

Then restart:

openclaw gateway restart

#

So, short version: this is not a Telegram connection problem yet, it’s a model allowlist/policy problem.

Docs:

If you paste openclaw config get agents.defaults.models, I can tell you the exact fix.

jade plank Apr 10, 2026, 1:41 PM

#

here is the output:

openclaw config get agents.defaults.models

🦞 OpenClaw 2026.4.9 (0512059) — I autocomplete your thoughts—just slower and with more API calls.

{
"copilot-proxy/gpt-5.2": {},
"copilot-proxy/gpt-5.2-codex": {},
"copilot-proxy/gpt-5.1": {},
"copilot-proxy/gpt-5.1-codex": {},
"copilot-proxy/gpt-5.1-codex-max": {},
"copilot-proxy/gpt-5-mini": {},
"copilot-proxy/claude-opus-4.6": {},
"copilot-proxy/claude-opus-4.5": {},
"copilot-proxy/claude-sonnet-4.5": {},
"copilot-proxy/claude-haiku-4.5": {},
"copilot-proxy/gemini-3-pro": {},
"copilot-proxy/gemini-3-flash": {},
"copilot-proxy/grok-code-fast-1": {}
}

balmy escarpBOT Apr 10, 2026, 1:42 PM

#

Yep, that’s the problem.

Your agent is currently allowlisting only copilot-proxy/... models.
So even though models.providers.ollama is configured, Ollama is blocked by policy and Telegram can’t use it.

Right now your allowed list contains only things like:

copilot-proxy/gpt-5.2
copilot-proxy/claude-opus-4.6
copilot-proxy/gemini-3-pro

and does not include:

ollama/gemma4
ollama/qwen3-coder:latest

Fix

#

Either:

Option A, add Ollama to the allowlist

Keep your current models, but add:

{
  "ollama/gemma4": {},
  "ollama/qwen3-coder:latest": {}
}

under agents.defaults.models, and set:

agents.defaults.model.primary = "ollama/gemma4"

#

Option B, remove the allowlist

If you don’t want model restrictions, remove agents.defaults.models entirely.

Then restart the gateway:

openclaw gateway restart

Important

After that, test again with:

openclaw models status
curl http://127.0.0.1:11434/api/tags

#

So the order is:

fix allowlist
restart gateway
test Ollama reachability

Right now you were failing at step 1, before OpenClaw even tried to talk to Ollama.

Docs:

If you want, paste openclaw config get agents.defaults.model next and I’ll tell you exactly what to change.

jade plank Apr 10, 2026, 1:43 PM

#

i want to remove the model restrictions, tell me step by step how to do that

balmy escarpBOT Apr 10, 2026, 1:46 PM

#

Yep, here’s the clean step-by-step.

Remove the model restrictions

1. Remove the allowlist

This is the actual restriction:

openclaw config unset agents.defaults.models

2. Restart the gateway

So it reloads the config:

openclaw gateway restart

#

3. Verify the allowlist is gone

This should now return nothing / empty:

openclaw config get agents.defaults.models

If you want Ollama to be the default too

4. Set the default model to Ollama

If you want Telegram chats to use Ollama by default:

openclaw config set agents.defaults.model '"ollama/gemma4"' --strict-json

5. Restart again

#

openclaw gateway restart

6. Verify

openclaw config get agents.defaults.model
openclaw models status
curl http://127.0.0.1:11434/api/tags

Then test from Telegram

If Telegram is reaching the gateway correctly, it should now be able to use Ollama.

If you want to switch in-chat, you can also try:

#

/model list
/model ollama/gemma4

Important note

If OpenClaw and Ollama are not on the same machine, 127.0.0.1:11434 is still wrong.
That address must be reachable from the gateway host.

Docs:

If any step throws an error, paste it and I’ll walk you through the next one.

jade plank Apr 10, 2026, 1:52 PM

#

still showing LLM request failed: network connection error, despite openclaw gateway status showing this:

openclaw gateway status

🦞 OpenClaw 2026.4.9 (0512059) — Like having a senior engineer on call, except I don't bill hourly or sigh audibly.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-10.log
Command: /usr/bin/node /home/azureadmin/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://172.20.136.184:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 15571, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: *:18789

balmy escarpBOT Apr 10, 2026, 1:53 PM

#

You’re close, and this output is consistent with one specific thing:

openclaw gateway status only proves Gateway is up, not that it can reach your model backend (Ollama).

Do this exact check sequence on the gateway host

Confirm what model is actually selected:

openclaw config get agents.defaults.model

If it is not Ollama, set it:

openclaw config set agents.defaults.model '"ollama/gemma4"' --strict-json
openclaw gateway restart

#

Test Ollama reachability from that same machine:

curl -sS http://127.0.0.1:11434/api/tags

Test OpenClaw inference directly:

openclaw infer model run --prompt "hi" --json

Get provider diagnostics:

openclaw models status --probe

If step 3 fails, that is the root cause (Ollama not running on that host, wrong host, or blocked port).
If Ollama is on another machine, change:

#

openclaw config set models.providers.ollama.baseUrl '"http://<OLLAMA_HOST>:11434"' --strict-json
openclaw gateway restart

Paste steps 1, 3, and 5 output, and I’ll pinpoint it fast.

jade plank Apr 10, 2026, 1:58 PM

#

inference test result:

openclaw infer model run --prompt "hi" --json
13:57:30+00:00 [agent] embedded run agent end: runId=e4983e33-d39b-4f10-9006-f95e8b48503c isError=true model=gemma4 provider=ollama error=404 {"error":"model 'gemma4' not found"} rawError=404 {"error":"model 'gemma4' not found"}
13:57:30+00:00 [agent] auth profile failure state updated: runId=e4983e33-d39b-4f10-9006-f95e8b48503c profile=sha256:9c018ec112cf provider=ollama reason=model_not_found window=cooldown reused=false
13:57:30+00:00 [agent] embedded run failover decision: runId=e4983e33-d39b-4f10-9006-f95e8b48503c stage=assistant decision=surface_error reason=model_not_found provider=ollama/gemma4 profile=sha256:9c018ec112cf
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "gemma4",
"attempts": [],
"outputs": [
{
"text": "404 {"error":"model 'gemma4' not found"}",
"mediaUrl": null
}
]
}

balmy escarpBOT Apr 10, 2026, 1:58 PM

#

Perfect, this is the root cause.

Your gateway can reach Ollama, but Ollama says:

404 {"error":"model 'gemma4' not found"}

So this is not a Telegram network issue now, it is a missing model on the Ollama host.

Fix

Check what Ollama actually has:

ollama list

Pull the model(s) your OpenClaw config references:

#

ollama pull gemma4
ollama pull qwen3-coder:latest

Restart gateway:

openclaw gateway restart

Re-test:

openclaw infer model run --prompt "hi" --json

If pull fails

If ollama pull gemma4 fails, use a model name that exists in ollama list, then update OpenClaw to that exact model id.

#

If you paste ollama list, I can tell you the exact config line to use.

jade plank Apr 10, 2026, 2:00 PM

#

I have been struggling with getting WSL or any environment to notice my Ollama version. It is the latest from Ollama's website:

ollama list
NAME ID SIZE MODIFIED
qwen3-coder:latest 06c1097efce0 18 GB 3 hours ago
azureadmin@Win10-Personal:~$ ollama pull gemma4
pulling manifest
Error: pull model manifest: 412:
The model you are attempting to pull requires a newer version of Ollama.

Please download the latest version at:

    https://ollama.com/download

balmy escarpBOT Apr 10, 2026, 2:00 PM

#

This is super helpful, we found it.

You currently have only this model installed:

qwen3-coder:latest

And gemma4 fails with 412 because your WSL Ollama daemon is older than what gemma4 requires.

Also, Windows Ollama and WSL Ollama are separate installs, updating one does not update the other.

Fastest unblock (right now)

Use the model you already have:

openclaw config set agents.defaults.model '"ollama/qwen3-coder:latest"' --strict-json

#

openclaw gateway restart
openclaw infer model run --prompt "hi" --json

Fix WSL Ollama version mismatch

Run in WSL:

which ollama
ollama --version
curl -s http://127.0.0.1:11434/api/version

Then update WSL Ollama itself:

#

curl -fsSL https://ollama.com/install.sh | sh

Restart Ollama daemon in WSL (whichever you use):

sudo systemctl restart ollama
# or, if you run manually:
pkill ollama || true
ollama serve

Then retry:

#

ollama pull gemma4

If you paste ollama --version and /api/version, I can tell you immediately if client/server are mismatched.

jade plank Apr 10, 2026, 2:11 PM

#

pulling gemma4 successful, gateway restarted, still getting "LLM request failed: network connection error" after a very long wait on Telegram

balmy escarpBOT Apr 10, 2026, 2:12 PM

#

Great, pulling gemma4 was a big step.

If it still fails after a long wait, we should isolate whether it is model runtime vs Telegram session state.

1) Hard-pin default to Ollama only (no fallback noise)

openclaw config set agents.defaults.model '{"primary":"ollama/gemma4","fallbacks":[]}' --strict-json
openclaw gateway restart
openclaw config get agents.defaults.model

2) Test model path directly from CLI

openclaw infer model run --model ollama/gemma4 --prompt "reply with exactly: ok" --json

3) Check what Telegram session is using

#

In Telegram chat:

/model status
/model ollama/gemma4

4) Capture the real error line while reproducing

Terminal A:

openclaw logs --follow

Terminal B: send one short Telegram message (hi), then paste the first error= line from logs.

If CLI infer succeeds but Telegram still fails, the model is fine and we are looking at session/channel routing state.
If CLI infer fails, paste that output and I can give the exact next fix.

jade plank Apr 10, 2026, 2:19 PM

#

infer test output:

"openclaw infer model run --model ollama/gemma4 --prompt "reply with exactly: ok" --json
14:17:27+00:00 [agent] Profile ollama:default timed out. Trying next account...
14:17:27+00:00 [agent] embedded run failover decision: runId=e4983e33-d39b-4f10-9006-f95e8b48503c stage=assistant decision=surface_error reason=model_not_found provider=ollama/gemma4 profile=sha256:9c018ec112cf
[agent] run e4983e33-d39b-4f10-9006-f95e8b48503c ended with stopReason=error
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "gemma4",
"attempts": [],
"outputs": [
{
"text": "404 {"error":"model 'gemma4' not found"}",
"mediaUrl": null
}
]
}"

On Telegram, /model status returns:

Current: ollama/gemma4 (selected)
Active: copilot-proxy/gpt-5.2 (runtime)
Default: ollama/gemma4
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[amazon-bedrock] endpoint: default auth: missing
• amazon-bedrock/anthropic.claude-3-haiku-20240307-v1:0
• amazon-bedrock/anthropic.claude-3-5-haiku-20241022-v1:0
• amazon-bedrock/anthropic.claude-haiku-4-5-20251001-v1:0
• amazon-bedrock/eu.anthropic.claude-haiku-4-5-20251001-v1:0
• amazon-bedrock/global.anthropic.claude-haiku-4-5-20251001-v1:0
• amazon-bedrock/us.anthropic.claude-haiku-4-5-20251001-v1:0

...as well as many, many other models

balmy escarpBOT Apr 10, 2026, 2:20 PM

#

Nice, this output is super clear now.

You still have a model-source mismatch:

OpenClaw is calling http://127.0.0.1:11434 and getting model 'gemma4' not found
So the Ollama endpoint OpenClaw uses does not currently have gemma4

Also, Active: copilot-proxy/gpt-5.2 means runtime fallback is still in play.

Do this exactly

Check what OpenClaw’s exact endpoint sees:

curl -sS http://127.0.0.1:11434/api/tags

Force Ollama CLI to that same endpoint, then pull:

#

echo "$OLLAMA_HOST"
OLLAMA_HOST=127.0.0.1:11434 ollama list
OLLAMA_HOST=127.0.0.1:11434 ollama pull gemma4

Test both models directly:

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json
openclaw infer model run --model ollama/qwen3-coder:latest --prompt "ok" --json

In Telegram, switch to the one that passes infer:

/model ollama/qwen3-coder:latest
/model status

#

If step 1 does not show gemma4, that is the whole issue.
If step 3 passes but Telegram still fails, paste fresh /model status and we’ll clear the runtime fallback state next.

jade plank Apr 10, 2026, 2:22 PM

#

openclaw endppoint sees:
"curl -sS http://127.0.0.1:11434/api/tags
{"models":[{"name":"gemma4:latest","model":"gemma4:latest","modified_at":"2026-04-10T14:06:03.186784909Z","size":9608350718,"digest":"c6eb396dbd5992bbe3f5cdb947e8bbc0ee413d7c17e2beaae69f5d569cf982eb","details":{"parent_model":"","format":"gguf","family":"gemma4","families":["gemma4"],"parameter_size":"8.0B","quantization_level":"Q4_K_M"}}]}"

how do I force ollama cli to that endpoint?

balmy escarpBOT Apr 10, 2026, 2:22 PM

#

Nice, that confirms it. ✅

To force Ollama CLI to a specific endpoint, set OLLAMA_HOST.

One command only (temporary)

OLLAMA_HOST=127.0.0.1:11434 ollama list
OLLAMA_HOST=127.0.0.1:11434 ollama pull gemma4

For current shell session

export OLLAMA_HOST=127.0.0.1:11434
ollama list

Persist it (future shells)

#

echo 'export OLLAMA_HOST=127.0.0.1:11434' >> ~/.bashrc
source ~/.bashrc

Also, your endpoint shows gemma4:latest, so set OpenClaw to the exact tag to avoid mismatch:

openclaw config set agents.defaults.model '"ollama/gemma4:latest"' --strict-json
openclaw gateway restart

Then retest:

openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json

jade plank Apr 10, 2026, 2:31 PM

#

'openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json' is still running; no output yet. On Telegram, I set the model to 'ollama/gemma4', got confirmation from Telegram, but on a follow-up message (I said 'so what now'), I got the same error: "LLM request failed"

balmy escarpBOT Apr 10, 2026, 2:31 PM

#

Got it, you’re very close.
At this point, do these exact changes so everything uses the same exact model tag.

Stop the hanging infer (Ctrl+C).
Update OpenClaw model id/name to exact Ollama tag:

openclaw config set models.providers.ollama.models[0].id '"gemma4:latest"' --strict-json
openclaw config set models.providers.ollama.models[0].name '"gemma4:latest"' --strict-json
openclaw config set agents.defaults.model '"ollama/gemma4:latest"' --strict-json
openclaw gateway restart

Verify raw Ollama speed on that endpoint:

OLLAMA_HOST=127.0.0.1:11434 ollama run gemma4:latest "reply with exactly: ok"

#

In Telegram, set exact same tag:

/model ollama/gemma4:latest
/model status

If step 3 is very slow/hangs, OpenClaw will timeout and surface LLM request failed.
Then the issue is model runtime speed on that machine, not Telegram routing.

If you paste step 3 timing + /model status after this, I can give the final tuning step.

jade plank Apr 10, 2026, 2:31 PM

#

actually, I just got the output from the inference test: "openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json
14:26:48+00:00 [agent] Profile ollama:default timed out. Trying next account...
14:26:48+00:00 [agent] embedded run failover decision: runId=e4983e33-d39b-4f10-9006-f95e8b48503c stage=assistant decision=surface_error reason=model_not_found provider=ollama/gemma4 profile=sha256:9c018ec112cf
[agent] run e4983e33-d39b-4f10-9006-f95e8b48503c ended with stopReason=error
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "gemma4",
"attempts": [],
"outputs": [
{
"text": "404 {"error":"model 'gemma4' not found"}",
"mediaUrl": null
}
]
}"

balmy escarpBOT Apr 10, 2026, 2:32 PM

#

Great catch, your pasted config is the key.

It still has:

id: "gemma4" (not gemma4:latest)

So OpenClaw keeps resolving to gemma4, which your Ollama endpoint rejects.

Run this exactly:

openclaw config set models.providers.ollama.models[0].id '"gemma4:latest"' --strict-json
openclaw config set models.providers.ollama.models[0].name '"gemma4:latest"' --strict-json
openclaw config set agents.defaults.model '"ollama/gemma4:latest"' --strict-json
openclaw models auth order clear --provider ollama
openclaw gateway restart

#

Then verify:

openclaw config get models.providers.ollama.models
openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json

If it still logs Profile ollama:default timed out, paste openclaw models auth order get --provider ollama next, that means stale profile ordering is still in play.

jade plank Apr 10, 2026, 2:43 PM

#

yes, profile ollama still timing out. here is output of requested command:

azureadmin@Win10-Personal:~$ openclaw models auth order get --provider ollama

🦞 OpenClaw 2026.4.9 (0512059) — Deployed locally, trusted globally, debugged eternally.

Agent: main
Provider: ollama
Auth state file: ~/.openclaw/agents/main/agent/auth-state.json
Order override: (none)

balmy escarpBOT Apr 10, 2026, 2:44 PM

#

Thanks, this confirms two separate issues are still happening:

OpenClaw is still resolving to gemma4 (not gemma4:latest)
A stale Ollama auth profile is timing out first

Let’s hard-fix both.

1) Force exact model id in config (and verify)

openclaw config set models.providers.ollama.models[0].id gemma4:latest
openclaw config set models.providers.ollama.models[0].name gemma4:latest
openclaw config set agents.defaults.model ollama/gemma4:latest
openclaw config get models.providers.ollama.models[0].id
openclaw config get agents.defaults.model

2) Force local Ollama auth marker

#

openclaw config set models.providers.ollama.apiKey ollama-local
openclaw gateway restart

3) Retest

openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json

If it still says Profile ollama:default timed out, paste this next:

openclaw models status --probe --json

We’ll read the Ollama credential candidates and remove the stale one cleanly.

jade plank Apr 10, 2026, 2:45 PM

#

I need you to clarify something for me: these code snippets that you paste here, do you want me to run them one by one, or can I copy the entire window? If I copy the entire window into the WSL terminal, the formatting becomes unreadable, and I don't know if the commands are executed. Please try to put each command into a separate line

balmy escarpBOT Apr 10, 2026, 2:45 PM

#

100%, great call.
Please run them one by one, not as one big paste.

Use this exact sequence, one command per line:

openclaw config set models.providers.ollama.models[0].id gemma4:latest

openclaw config set models.providers.ollama.models[0].name gemma4:latest

openclaw config set agents.defaults.model ollama/gemma4:latest

#

openclaw config set models.providers.ollama.apiKey ollama-local

openclaw gateway restart

openclaw config get models.providers.ollama.models[0].id

openclaw config get agents.defaults.model

#

openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json

If anything errors, stop there and paste that single error.

jade plank Apr 10, 2026, 2:48 PM

#

got stuck after restarting gateway, can't ctrl+c to cancel, can't get cursor back after spamming enter

balmy escarpBOT Apr 10, 2026, 2:49 PM

#

Got it, terminal is likely paused. Try this in order:

Press Ctrl+Q

Press Ctrl+C

Type reset and press Enter (even if you can’t see text)

If still frozen, close that WSL tab/window and open a new one.

Then run:

openclaw gateway status

If that works, continue with:

#

openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json

You’re not far off, this is just terminal state weirdness.

jade plank Apr 10, 2026, 2:52 PM

#

infer test output:

openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json
14:50:57+00:00 [agent] Removed orphaned user message to prevent consecutive user turns. runId=e4983e33-d39b-4f10-9006-f95e8b48503c sessionId=e4983e33-d39b-4f10-9006-f95e8b48503c trigger=user
14:51:57+00:00 [agent] Profile ollama:default timed out. Trying next account...
14:51:57+00:00 [agent] embedded run failover decision: runId=e4983e33-d39b-4f10-9006-f95e8b48503c stage=assistant decision=surface_error reason=model_not_found provider=ollama/gemma4 profile=sha256:9c018ec112cf
[agent] run e4983e33-d39b-4f10-9006-f95e8b48503c ended with stopReason=error
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "gemma4",
"attempts": [],
"outputs": [
{
"text": "404 {"error":"model 'gemma4' not found"}",
"mediaUrl": null
}
]
}

balmy escarpBOT Apr 10, 2026, 2:53 PM

#

Perfect, thanks for the log.
We need to verify the config change actually applied.

Please run these one by one and paste each output:

openclaw config get models.providers.ollama.models[0].id

openclaw config set models.providers.ollama.models[0].id '"gemma4:latest"' --strict-json

openclaw config set models.providers.ollama.models[0].name '"gemma4:latest"' --strict-json

#

openclaw config get models.providers.ollama.models[0]

openclaw gateway restart

openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json

Right now OpenClaw is still sending gemma4, so we need to confirm that [0].id really changed to gemma4:latest.

jade plank Apr 10, 2026, 2:54 PM

#

azureadmin@Win10-Personal:~$ openclaw config get models.providers.ollama.models[0].id

🦞 OpenClaw 2026.4.9 (0512059) — Running on your hardware, reading your logs, judging nothing (mostly).

gemma4:latest
azureadmin@Win10-Personal:~$

azureadmin@Win10-Personal:~$ openclaw config set models.providers.ollama.models[0].id '"gemma4:latest"' --strict-json

🦞 OpenClaw 2026.4.9 (0512059) — Powered by open source, sustained by spite and good documentation.

Config overwrite: /home/azureadmin/.openclaw/openclaw.json (sha256 6bef83c821c0f1dd33dabd329ed83c6ee78dbe0f99e19362cc93b21fd7449276 -> 3b462aa060eed0d0f34c4ae883474da09b9bee5d71f69572ab9ade2fac5698b5, backup=/home/azureadmin/.openclaw/openclaw.json.bak)
Updated models.providers.ollama.models.0.id. Restart the gateway to apply.
azureadmin@Win10-Personal:~$

should i stop here and restart the gateway?

balmy escarpBOT Apr 10, 2026, 2:54 PM

#

Yes, perfect. 👍
Run these next, one by one:

openclaw config set models.providers.ollama.models[0].name '"gemma4:latest"' --strict-json

openclaw gateway restart

openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json

Then paste that final infer output.

jade plank Apr 10, 2026, 2:57 PM

#

openclaw infer model run --model ollama/gemma4:latest --prompt "ok" --json
14:56:54+00:00 [agent] Profile ollama:default timed out. Trying next account...
14:56:54+00:00 [agent] embedded run failover decision: runId=e4983e33-d39b-4f10-9006-f95e8b48503c stage=assistant decision=surface_error reason=model_not_found provider=ollama/gemma4 profile=sha256:9c018ec112cf
[agent] run e4983e33-d39b-4f10-9006-f95e8b48503c ended with stopReason=error
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "gemma4",
"attempts": [],
"outputs": [
{
"text": "404 {"error":"model 'gemma4' not found"}",
"mediaUrl": null
}
]
}

balmy escarpBOT Apr 10, 2026, 2:57 PM

#

Thanks, this proves it.
OpenClaw is still sending gemma4 (without tag), and your Ollama only has gemma4:latest.

Let’s do a direct workaround now:

OLLAMA_HOST=127.0.0.1:11434 ollama cp gemma4:latest gemma4

OLLAMA_HOST=127.0.0.1:11434 ollama list

openclaw gateway restart

#

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json

If that works, Telegram should work too with:

/model ollama/gemma4

The Profile ollama:default timed out line is a separate stale-profile issue, but first let’s get a successful model response.

jade plank Apr 10, 2026, 2:59 PM

#

before I restart the gateway again, look at this:

azureadmin@Win10-Personal:~$ OLLAMA_HOST=127.0.0.1:11434 ollama cp gemma4:latest gemma4
copied 'gemma4:latest' to 'gemma4'
azureadmin@Win10-Personal:~$ OLLAMA_HOST=127.0.0.1:11434 ollama list
NAME ID SIZE MODIFIED
gemma4:latest c6eb396dbd59 9.6 GB 52 minutes ago
azureadmin@Win10-Personal:~$

did the renaming actually work?

balmy escarpBOT Apr 10, 2026, 2:59 PM

#

Good question. It might have worked, ollama list can still show only the canonical tag.

Let’s verify directly, one line at a time:

OLLAMA_HOST=127.0.0.1:11434 ollama show gemma4

If that command succeeds, alias works.
Then continue:

openclaw gateway restart

#

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json

If ollama show gemma4 fails, paste that exact error and we’ll use a different workaround.

jade plank Apr 10, 2026, 2:59 PM

#

azureadmin@Win10-Personal:~$ OLLAMA_HOST=127.0.0.1:11434 ollama show gemma4
Model
architecture gemma4
parameters 8.0B
context length 131072
embedding length 2560
quantization Q4_K_M
requires 0.20.0

Capabilities
completion
vision
audio
tools
thinking

Parameters
temperature 1
top_k 64
top_p 0.95

License
Apache License
Version 2.0, January 2004
...

azureadmin@Win10-Personal:~$

balmy escarpBOT Apr 10, 2026, 2:59 PM

#

Excellent, that means aliasing worked. ✅

Now do these next, one by one:

openclaw gateway restart

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json

If that succeeds, test Telegram again:

/model ollama/gemma4

#

Then send a short message like ok.

Paste the infer output after restart, that will confirm we’re finally past the model_not_found part.

jade plank Apr 10, 2026, 3:02 PM

#

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json is taking a very long time again. I have a feeling it is going to fail. while it is doing that, please tell me: is there some way to easily deploy openclaw? all the tools and settings and dependencies that need to be configured during onboarding are extremely confusing, and would require a lot of time, research and setup for each individual tool. surely someone has made some kind of automation for this. I just want to be able to run openclaw and talk to the simplest model possible, through telegram

balmy escarpBOT Apr 10, 2026, 3:03 PM

#

Totally fair, you’re right, this is too much friction.

Yes, there is an easier automated path.
If your goal is just Telegram + one local model, do this minimal flow.

Run one by one:

openclaw onboard --non-interactive --mode local --auth-choice ollama --custom-base-url "http://127.0.0.1:11434" --custom-model-id "gemma4" --gateway-port 18789 --gateway-bind loopback --install-daemon --accept-risk --skip-skills

openclaw config set channels.telegram.botToken "<YOUR_BOTFATHER_TOKEN>"

#

openclaw config set channels.telegram.dmPolicy pairing

openclaw gateway restart

Now in Telegram, DM your bot and send /start.

Then approve pairing in terminal:

openclaw pairing list telegram

#

openclaw pairing approve telegram <CODE>

That is the simplest secure setup, no extra tool config needed.

Docs:

jade plank Apr 10, 2026, 3:06 PM

#

after the first command, we already have problems:

openclaw onboard --non-interactive --mode local --auth-choice ollama --custom-base-url "http://127.0.0.1:11434" --custom-model-id "gemma4" --gateway-port 18789 --gateway-bind loopback --install-daemon --accept-risk --skip-skills

🦞 OpenClaw 2026.4.9 (0512059) — I've survived more breaking changes than your last three relationships.

Downloading gemma4...
Downloaded gemma4
Default Ollama model: gemma4
Config overwrite: /home/azureadmin/.openclaw/openclaw.json (sha256 a43983de6f55f7a971c0c267b73c47858bca0d60bd0a0929e3867dc4bb1aff1d -> 6eec584670bbb7ddb205165c3bb93d2f0df4fdaccf91ddddb1e348d26ecb0f1e, backup=/home/azureadmin/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Workspace OK: ~/.openclaw/workspace
Sessions OK: ~/.openclaw/agents/main/sessions

Installed systemd service: /home/azureadmin/.config/systemd/user/openclaw-gateway.service
Previous unit backed up to: /home/azureadmin/.config/systemd/user/openclaw-gateway.service.bak
│
◇
Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/azureadmin/.openclaw/openclaw.json
Bind: loopback

balmy escarpBOT Apr 10, 2026, 3:06 PM

#

You did nothing wrong, onboarding mostly succeeded.
That timeout usually means the service did not come up fast enough.

Run these one by one:

openclaw gateway status

openclaw gateway start

openclaw gateway status

#

If it still shows timeout/not running:

systemctl --user daemon-reload

systemctl --user restart openclaw-gateway

openclaw gateway status

If still failing, get the service error:

#

journalctl --user -u openclaw-gateway -n 120 --no-pager

Paste the output of openclaw gateway status after restart, and I’ll give the exact next command.

jade plank Apr 10, 2026, 3:07 PM

#

ok, let's assume the gateway is working.. i'm proceeding with the telegram token

balmy escarpBOT Apr 10, 2026, 3:07 PM

#

Sounds good 👍
Just do one quick check first, then continue.

openclaw gateway status

Then:

openclaw config set channels.telegram.botToken "<YOUR_BOTFATHER_TOKEN>"

openclaw config set channels.telegram.dmPolicy pairing

#

openclaw gateway restart

openclaw channels status --probe

Then in Telegram, DM your bot and send /start, then approve:

openclaw pairing list telegram

openclaw pairing approve telegram <CODE>

#

If any command errors, paste that exact output and I’ll give the next line.

jade plank Apr 10, 2026, 3:08 PM

#

is it ok?

openclaw gateway status

🦞 OpenClaw 2026.4.9 (0512059) — Running on your hardware, reading your logs, judging nothing (mostly).

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-10.log
Command: /usr/bin/node /home/azureadmin/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 22969, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

balmy escarpBOT Apr 10, 2026, 3:08 PM

#

Yes, this is good. ✅
Runtime: running + RPC probe: ok means gateway is healthy.

Now continue, one command per line:

openclaw config set channels.telegram.botToken "<YOUR_BOTFATHER_TOKEN>"

openclaw config set channels.telegram.dmPolicy pairing

openclaw gateway restart

#

openclaw channels status --probe

Then DM your bot in Telegram with /start, then:

openclaw pairing list telegram

openclaw pairing approve telegram <CODE>

(Loopback bind is fine for Telegram polling mode.)

jade plank Apr 10, 2026, 3:09 PM

#

after setting my bot token, it is asking for a gateway restart again

balmy escarpBOT Apr 10, 2026, 3:09 PM

#

Yep, that is expected.
Run this now:

openclaw gateway restart

Then:

openclaw channels status --probe

Paste that output, and we’ll confirm Telegram is connected.

jade plank Apr 10, 2026, 3:10 PM

#

openclaw channels status --probe

🦞 OpenClaw 2026.4.9 (0512059) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

│

◇
Gateway reachable.

Telegram default: enabled, configured, running, mode:polling, bot:@REDACTEDt, token:config, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

balmy escarpBOT Apr 10, 2026, 3:10 PM

#

Perfect, this is good. Telegram is fully connected. ✅

Now do the final activation steps:

In Telegram, DM your bot:

/start

Then in terminal:

openclaw pairing list telegram

#

openclaw pairing approve telegram <CODE>

Then test in Telegram:

hi

If it still returns LLM request failed, paste that exact bot error and we’ll do the last model-only fix.

jade plank Apr 10, 2026, 3:12 PM

#

here's the thing: I already have the bot setup on Telegram. "/start" only returns the LLM request failed error, and in the terminal, there are no pending pairing requests

balmy escarpBOT Apr 10, 2026, 3:13 PM

#

Yep, that makes sense.
No pending pairing means Telegram auth is already fine. This is now purely a model-runtime issue.

Let’s refresh the Ollama auth profile (the timeout line points to stale profile state):

openclaw models auth login --provider ollama --set-default

(If prompted, choose the local Ollama option.)

openclaw gateway restart

#

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json

If that infer works, Telegram will work too.
If it still fails, paste this next:

openclaw models status --probe --json

and I’ll tell you exactly which profile entry to remove.

jade plank Apr 10, 2026, 3:15 PM

#

it's stuck on this:

openclaw models auth login --provider ollama --set-default

🦞 OpenClaw 2026.4.9 (0512059) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

│
◆ Ollama base URL
│ http://127.0.0.1:11434

pressing Enter does nothing.........

rough starBOT Apr 10, 2026, 3:15 PM

#

balmy escarpBOT Apr 10, 2026, 3:15 PM

#

Yep, abort that one, it’s interactive and flaky in your terminal right now.

Do this instead:

Press Ctrl+C

Then run:

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json

If that still fails, run this and paste output:

openclaw models status --probe --json

#

We can fix without the interactive auth login flow.

jade plank Apr 10, 2026, 3:18 PM

#

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json

taking forever again

balmy escarpBOT Apr 10, 2026, 3:19 PM

#

Yeah, that’s frustrating, and you’re right to pause.
Let’s do one quick split test so we stop guessing.

Press Ctrl+C, then run these one by one:

time OLLAMA_HOST=127.0.0.1:11434 ollama run gemma4 "ok"

openclaw models status --probe --json

Why:

if ollama run is slow, the model/runtime is the bottleneck
if ollama run is fast but OpenClaw is slow/failing, it is OpenClaw auth-profile routing (ollama:default timed out) and we can fix that directly next

#

Paste both outputs and I’ll give you the shortest final fix path.

jade plank Apr 10, 2026, 3:19 PM

#

ctrl+c has no effect

balmy escarpBOT Apr 10, 2026, 3:19 PM

#

Got it. Kill the stuck process with this sequence:

Press Ctrl+\

If still stuck, press Ctrl+Z

Then type:

kill %1

Then fix terminal state:

stty sane

#

reset

If you still cannot recover, open a new WSL tab and run:

pkill -f "openclaw infer model run"

pkill -f "openclaw models auth login"

Then:

#

openclaw gateway status

Paste that result and we continue.

jade plank Apr 10, 2026, 3:20 PM

#

ctrl+\ does nothing either

balmy escarpBOT Apr 10, 2026, 3:20 PM

#

No worries, just hard-reset that shell.

Close that WSL tab/window completely.

Open a new WSL terminal and run:

pkill -9 -f "openclaw infer model run"

pkill -9 -f "openclaw models auth login"

openclaw gateway restart

#

openclaw gateway status

Paste the gateway status output after this.

jade plank Apr 10, 2026, 3:25 PM

#

time OLLAMA_HOST=127.0.0.1:11434 ollama run gemma4 "ok" output:

Thinking...
Thinking Process:

Analyze the input: The input is simply "ok".
Determine the intent: This is a very ambiguous input. It can mean:
- Confirmation ("Okay, I understood.")
- Acknowledgment ("Okay.")
- A prompt for the next action (implying a pause or readiness).
Formulate a suitable response: Since there is no preceding context or specific request, the best response is to be helpful, confirm readiness, and prompt the
user to continue or state their goal.

Self-Correction/Refinement: A simple "ok" back is unhelpful. A question asking what I can do is the most direct way to proceed.

Generate response options:
- "How can I help you?" (Professional, standard)
- "What's next?" (Casual, direct)
- "Ready when you are." (Friendly, implies waiting)
Select the best option: Combining professionalism with openness is ideal.
...done thinking.

I'm here and ready when you are! 😊

What would you like to talk about or work on next?

real 1m45.744s
user 0m0.297s
sys 0m0.329s

======================================
probe output: in the next propmt

balmy escarpBOT Apr 10, 2026, 3:25 PM

#

This is the key result.
ollama run gemma4 "ok" took 1m45s, so OpenClaw’s ~60s provider timeout is being hit first.

So yes, the failure is expected with current speed.

Do this now (one per line):

openclaw config set agents.defaults.thinkingDefault off

openclaw gateway restart

#

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json

And in Telegram, send once:

/thinking off

If it is still too slow, switch to a smaller local model. I can give you a minimal 3-command version for that next.

jade plank Apr 10, 2026, 3:26 PM

#

here it is:

openclaw models status --probe --json

│

◇
{
"configPath": "/home/azureadmin/.openclaw/openclaw.json",
"agentDir": "/home/azureadmin/.openclaw/agents/main/agent",
"defaultModel": "ollama/gemma4",
"resolvedDefault": "ollama/gemma4",
"fallbacks": [],
"imageModel": null,
"imageFallbacks": [],
"aliases": {},
"allowed": [],
"auth": {
"storePath": "/home/azureadmin/.openclaw/agents/main/agent/auth-profiles.json",
"shellEnvFallback": {
"enabled": false,
"appliedKeys": []
},
"providersWithOAuth": [
"copilot-proxy (1)"
],
"missingProvidersInUse": [],
"providers": [
{
"provider": "copilot-proxy",
"effective": {
"kind": "profiles",
"detail": "~/.openclaw/agents/main/agent/auth-profiles.json"
},
"profiles": {
"count": 1,
"oauth": 0,
"token": 1,
"apiKey": 0,
"labels": [
"copilot-proxy:local=token:n...a"
]
},
"modelsJson": {
"value": "n...a",
"source": "models.json: ~/.openclaw/agents/main/agent/models.json"
}
},
{
"provider": "ollama",
"effective": {
"kind": "profiles",
"detail": "~/.openclaw/agents/main/agent/auth-profiles.json"
},
"profiles": {
"count": 1,
"oauth": 0,
"token": 0,
"apiKey": 1,
"labels": [
"ollama:default=marker(ollama-local)"
]
},
"modelsJson": {
"value": "OL...EY",
"source": "models.json: ~/.openclaw/agents/main/agent/models.json"
}
}
],
"unusableProfiles": [],
"oauth": {

I can't paste the rest cause of discord's character limits

balmy escarpBOT Apr 10, 2026, 3:26 PM

#

This snippet is enough, thanks.
Auth looks clean, no broken profiles. So the issue is speed: gemma4 is too slow for the request timeout.

Let’s switch to a tiny local model now.

Run one by one:

OLLAMA_HOST=127.0.0.1:11434 ollama pull llama3.2:1b

openclaw config set models.providers.ollama.models[0].id llama3.2:1b

#

openclaw config set models.providers.ollama.models[0].name llama3.2:1b

openclaw config set agents.defaults.model ollama/llama3.2:1b

openclaw config set agents.defaults.thinkingDefault off

openclaw gateway restart

#

openclaw infer model run --model ollama/llama3.2:1b --prompt "ok" --json

If pull fails for that model name, run ollama list and I’ll give you the exact fastest one to use.

jade plank Apr 10, 2026, 3:30 PM

#

ok, waiting for the infer test. not looking very promising.. and this is running on an 8-core, 64GB RAM machine by the way

balmy escarpBOT Apr 10, 2026, 3:31 PM

#

Yep, on CPU-only that can still happen, even with 8 cores and 64 GB RAM.
OpenClaw also adds tool/runtime prompt overhead, which hurts local latency.

If this infer fails, do this “speed mode” immediately:

openclaw config set tools.profile minimal

openclaw config set agents.defaults.thinkingDefault off

openclaw gateway restart

#

Then test again:

openclaw infer model run --model ollama/llama3.2:1b --prompt "ok" --json

tools.profile minimal is the big one for local speed.

jade plank Apr 10, 2026, 3:33 PM

#

it's still going to time out

balmy escarpBOT Apr 10, 2026, 3:33 PM

#

Yep, I agree, stop waiting on that run.

Let’s do this decisively, pick one path:

Recommended now (works fastest): switch to cloud temporarily

pkill -9 -f "openclaw infer model run"

openclaw config set agents.defaults.model copilot-proxy/gpt-5-mini

openclaw gateway restart

#

Then test in Telegram (hi).

If you want to stay local-only right now

pkill -9 -f "openclaw infer model run"

openclaw config set tools.profile minimal

openclaw config set agents.defaults.thinkingDefault off

#

openclaw gateway restart

Then test in Telegram again.

If you choose local-only and it still times out, we’ll lock to a tiny Ollama model next.

jade plank Apr 10, 2026, 3:36 PM

#

after a long wait on telegram, same error

balmy escarpBOT Apr 10, 2026, 3:36 PM

#

Understood. Let’s stop burning time on local for now and unblock you.

Run these exactly:

openclaw config set agents.defaults.model copilot-proxy/gpt-5-mini

openclaw gateway restart

Then in Telegram:

/model copilot-proxy/gpt-5-mini

#

Send:

hi

If that still fails, run this in terminal while sending hi once:

openclaw logs --follow

and paste the first error line.
But first let’s try the cloud switch, it should respond quickly.

jade plank Apr 10, 2026, 3:38 PM

#

failure again, let me get you the logs sir

balmy escarpBOT Apr 10, 2026, 3:39 PM

#

Perfect, thank you. 🙏
Please capture logs with this exact sequence (one line at a time):

openclaw config get agents.defaults.model

openclaw channels status --probe

openclaw status --all

Now reproduce one failure from Telegram, then run:

#

tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | rg -i "error|timeout|model_not_found|telegram|ollama|copilot|provider|runId"

Paste all outputs, and I’ll pinpoint the exact cause.

jade plank Apr 10, 2026, 3:41 PM

#

first i need a non-dangerous version of ripgrep

sudo snap install ripgrep # version 12.1.0 --classic
error: This revision of snap "ripgrep" was published using classic confinement and thus may perform
arbitrary system changes outside of the security sandbox that snaps are usually confined to,
which may put your system at risk.

   If you understand and want to proceed repeat the command including --classic.

we can install with --classic, but I don't know the command format

balmy escarpBOT Apr 10, 2026, 3:41 PM

#

Great catch, do not use snap --classic here.

You don’t need ripgrep at all. Use built-in grep:

tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | grep -Ei "error|timeout|model_not_found|telegram|ollama|copilot|provider|runId"

Also run these and paste output:

openclaw config get agents.defaults.model

openclaw status --all

#

If you still want ripgrep later, safer route is apt (not snap classic):

sudo apt update

sudo apt install -y ripgrep

jade plank Apr 10, 2026, 3:42 PM

#

the output is gigantic, I can't paste it in discord

balmy escarpBOT Apr 10, 2026, 3:42 PM

#

No problem, let’s compress it.

Run these and paste only the output:

openclaw config get agents.defaults.model

tail -n 600 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | grep -Ei "llm request failed|profile .* timed out|model_not_found|provider=|error=|telegram|ollama" | tail -n 60

openclaw status --all | grep -Ei "runtime|rpc probe|default model|ollama|telegram|error|missing auth"

That will be short enough for Discord and enough for me to pinpoint it.

jade plank Apr 10, 2026, 3:46 PM

#

balmy escarpBOT Apr 10, 2026, 3:47 PM

#

Got it, let’s do one tiny isolate test (no huge output):

openclaw infer model run --model copilot-proxy/gpt-5-mini --prompt "ok" --json

If this returns quickly, then your Telegram session is still pinned to Ollama.

Then in Telegram send, in this order:

/model copilot-proxy/gpt-5-mini

/thinking off

#

hi

If it still fails, send only the first 5 lines of /model status (Current/Active/Default/Agent/Auth file). That part is short.

jade plank Apr 10, 2026, 3:49 PM

#

openclaw infer model run --model copilot-proxy/gpt-5-mini --prompt "ok" --json
15:48:21+00:00 [agent] embedded run agent end: runId=e4983e33-d39b-4f10-9006-f95e8b48503c isError=true model=gpt-5-mini provider=copilot-proxy error=LLM request failed: network connection error. rawError=Connection error.
15:48:24+00:00 [agent] embedded run agent end: runId=e4983e33-d39b-4f10-9006-f95e8b48503c isError=true model=gpt-5-mini provider=copilot-proxy error=LLM request failed: network connection error. rawError=Connection error.
15:48:30+00:00 [agent] embedded run agent end: runId=e4983e33-d39b-4f10-9006-f95e8b48503c isError=true model=gpt-5-mini provider=copilot-proxy error=LLM request failed: network connection error. rawError=Connection error.
15:48:39+00:00 [agent] embedded run agent end: runId=e4983e33-d39b-4f10-9006-f95e8b48503c isError=true model=gpt-5-mini provider=copilot-proxy error=LLM request failed: network connection error. rawError=Connection error.
15:48:39+00:00 [agent] embedded run failover decision: runId=e4983e33-d39b-4f10-9006-f95e8b48503c stage=assistant decision=surface_error reason=timeout provider=copilot-proxy/gpt-5-mini profile=sha256:d3c3e7a4e267
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "copilot-proxy",
"model": "gpt-5-mini",
"attempts": [],
"outputs": [
{
"text": "LLM request failed: network connection error.",
"mediaUrl": null
}
]
}

and on telegram, the 'hi' only gave the same error, after I disable thinking via telegram

balmy escarpBOT Apr 10, 2026, 3:50 PM

#

Perfect, this finally gives the root cause.

You have two separate problems:

copilot-proxy/* = real network/connectivity failure (Connection error)
ollama/gemma4 = too slow for timeout on your setup

Since you want simplest Telegram chat, use a tiny local model and skip cloud for now.

Run one by one:

OLLAMA_HOST=127.0.0.1:11434 ollama pull llama3.2:1b

#

time OLLAMA_HOST=127.0.0.1:11434 ollama run llama3.2:1b "ok"

openclaw config set models.providers.ollama.models[0].id llama3.2:1b

openclaw config set models.providers.ollama.models[0].name llama3.2:1b

openclaw config set agents.defaults.model ollama/llama3.2:1b

#

openclaw config set agents.defaults.thinkingDefault off

openclaw config set tools.profile minimal

openclaw gateway restart

openclaw infer model run --model ollama/llama3.2:1b --prompt "ok" --json

If that infer succeeds, Telegram should finally work.

jade plank Apr 10, 2026, 3:50 PM

#

why are you repeating the same steps? I already downloeard llama 3.2 1b

balmy escarpBOT Apr 10, 2026, 3:51 PM

#

You’re right, my bad, thanks for calling that out.

No more repeats.
Since you already downloaded it, run only these:

openclaw config set models.providers.ollama.models[0].id llama3.2:1b

openclaw config set models.providers.ollama.models[0].name llama3.2:1b

openclaw config set agents.defaults.model ollama/llama3.2:1b

#

openclaw config set tools.profile minimal

openclaw config set agents.defaults.thinkingDefault off

openclaw gateway restart

openclaw infer model run --model ollama/llama3.2:1b --prompt "ok" --json

Paste only that last command’s output. If it succeeds, Telegram will work with the same model.

jade plank Apr 10, 2026, 3:51 PM

#

i give up. I have spent over 10 hours trying to set this up. this entire process needs to be simplified

balmy escarpBOT Apr 10, 2026, 3:51 PM

#

You’re absolutely right, and I’m really sorry, this was way too painful.

10 hours is not acceptable for “simple Telegram + local model”.
If you want to stop here, that is totally fair.

If you’re open to one last helpful step, please file this as a bug so maintainers can fix it properly:
https://github.com/openclaw/openclaw/issues

Use this title/body:

Title: WSL + Telegram + Ollama setup repeatedly fails with LLM request failed / timeouts (2026.4.9)

Body (paste):

OpenClaw version: 2026.4.9
Environment: WSL (8-core CPU, 64GB RAM), Telegram polling mode
Telegram channel status shows works
ollama run gemma4 "ok" works but takes ~1m45s

#

openclaw infer model run --model ollama/gemma4 --prompt "ok" --json times out/fails
copilot-proxy/gpt-5-mini also returns LLM request failed: network connection error
Pairing/token setup completed, but Telegram replies still return LLM request failed
Setup flow felt too complex and brittle for a minimal “chat via Telegram” use case

If you want, I can help you polish the issue text further before you post it.

jade plank Apr 10, 2026, 3:52 PM

#

the problem here is with the main instructions on the official site, they are not detailed enough

balmy escarpBOT Apr 10, 2026, 3:52 PM

#

I completely agree, and that feedback is spot on.

The docs need a true “minimal path” guide, not just generic setup.
If you post a docs issue, I’d suggest asking for these exact improvements:

Single-goal quickstart: “Telegram + local Ollama only” (no extra tools)
WSL-specific section: systemd quirks, terminal freeze recovery, restart flow
Model speed expectations: CPU-only latency + timeout behavior explained upfront
Copy-paste command blocks: one-command-per-line, no mixed prose
Failure decision tree: LLM request failed → exact checks in order

If you want, I can draft a ready-to-paste docs issue text for GitHub.

jade plank Apr 10, 2026, 3:53 PM

#

notify whoever created this

balmy escarpBOT Apr 10, 2026, 3:53 PM

#

I can’t directly notify maintainers from here, but the right path is a GitHub issue so it gets tracked:

https://github.com/openclaw/openclaw/issues

Paste this:

Title: Docs are not detailed enough for minimal Telegram + Ollama setup (WSL)

Body:
I spent ~10 hours trying to set up OpenClaw for a simple use case: Telegram chat + local Ollama model only.
The current docs are not detailed enough for this flow.

Please add:

A minimal “Telegram + local Ollama only” guide (one command per line).
WSL-specific troubleshooting (systemd behavior, terminal freeze recovery).
Clear timeout guidance for CPU-only local models.

#

A strict failure decision tree for LLM request failed / network connection error.
A simpler onboarding path that avoids unrelated tool setup.

If you want, I can help tighten this wording further before you post.

jade plank Apr 10, 2026, 3:54 PM

#

this entire endeavor was a waste of my life

balmy escarpBOT Apr 10, 2026, 3:54 PM

#

You’re right, this was brutal, and I’m really sorry.
You shouldn’t have had to fight it this hard.

I won’t push more setup steps.

If you want, I can give you one final copy-paste bug report with all the key findings so you can drop it into GitHub in 30 seconds and be done with this.

jade plank Apr 10, 2026, 3:55 PM

#

give me some simple commands to deploy an azure linux vm that can run open claw.

balmy escarpBOT Apr 10, 2026, 3:55 PM

#

Got you. Here is the quickest Azure VM path (copy one line at a time).

1) Create VM (from your local machine)

az login

RG="rg-openclaw-quick"

LOC="westus2"

#

VM="vm-openclaw-quick"

USER="openclaw"

az group create -n "$RG" -l "$LOC"

az vm create -g "$RG" -n "$VM" --image "Canonical:ubuntu-24_04-lts:server:latest" --size "Standard_B2as_v2" --admin-username "$USER" --generate-ssh-keys --public-ip-sku Standard

#

IP=$(az vm show -d -g "$RG" -n "$VM" --query publicIps -o tsv) && echo "$IP"

2) SSH into VM and install OpenClaw

ssh "$USER@$IP"

curl -fsSL https://openclaw.ai/install.sh -o /tmp/install.sh

bash /tmp/install.sh

#

rm -f /tmp/install.sh

openclaw gateway status

3) (Optional) Access dashboard safely via SSH tunnel from your laptop

ssh -L 18789:127.0.0.1:18789 "$USER@$IP"

Then open http://127.0.0.1:18789.

If you want, next I can give you the hardened Azure Bastion/no-public-IP version too (official doc): https://docs.openclaw.ai/install/azure

jade plank Apr 10, 2026, 3:58 PM

#

change all the commands to cloud shell

balmy escarpBOT Apr 10, 2026, 3:58 PM

#

Perfect, here is the Cloud Shell version only.

Run in Azure Cloud Shell

RG="rg-openclaw-quick"

LOC="westus2"

VM="vm-openclaw-quick"

#

USER="openclaw"

az group create -n "$RG" -l "$LOC"

az vm create -g "$RG" -n "$VM" --image "Canonical:ubuntu-24_04-lts:server:latest" --size "Standard_B2as_v2" --admin-username "$USER" --generate-ssh-keys --public-ip-sku Standard

IP=$(az vm show -d -g "$RG" -n "$VM" --query publicIps -o tsv) && echo "$IP"

#

ssh "$USER@$IP"

Then run these inside the VM shell

curl -fsSL https://openclaw.ai/install.sh -o /tmp/install.sh

bash /tmp/install.sh

rm -f /tmp/install.sh

#

openclaw onboard --install-daemon

openclaw gateway status

If you want, I can also give you a Cloud-Shell-friendly non-interactive onboard command next.

jade plank Apr 10, 2026, 4:06 PM

#

and let the tsunami of problems begin

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

openclaw@vm-openclaw-quick:~$ curl -fsSL https://openclaw.ai/install.sh -o /tmp/install.sh
openclaw@vm-openclaw-quick:~$ bash /tmp/install.sh
╭───────────────────────────────────────────────────────────────────────────────╮
│ │
│ 🦞 OpenClaw Installer │
│ Welcome to the command line: where dreams compile and confidence segfaults. │
│ modern installer mode │
│ │
╰───────────────────────────────────────────────────────────────────────────────╯

✓ gum bootstrapped (temp, verified, v0.17.0)
✓ Detected: linux

Install plan

OS linux
Install method npm
Requested version latest

[1/3] Preparing environment

INFO Node.js not found, installing it now
INFO Installing Node.js via NodeSource
INFO Installing Linux build tools (make/g++/cmake/python3)
inappropriate ioctl for device
inappropriate ioctl for device
✓ Build tools installed
inappropriate ioctl for device
inappropriate ioctl for device
✓ Node.js v22 installed
ERROR Node.js v22+ is required but could not be activated on PATH
Detected node: (not found)
Current version: unknown
Install Node.js 22+ manually: https://nodejs.org

balmy escarpBOT Apr 10, 2026, 4:06 PM

#

Totally fair reaction.
This one is fixable fast, the installer got Node installed but PATH did not refresh in that shell.

Run these inside the VM, one by one:

hash -r

source /etc/profile

node -v

#

If node -v still fails, run:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -

sudo apt-get install -y nodejs

node -v

Then install OpenClaw directly (skip installer script now):

#

sudo npm install -g openclaw@latest

openclaw --version

openclaw onboard --install-daemon

The inappropriate ioctl for device lines are annoying but usually harmless in this context.

jade plank Apr 10, 2026, 4:13 PM

#

I need a model that doesn't require api keys or other setups

Model/auth provider
│ ● Anthropic (Claude CLI + API key)
│ ○ Arcee AI
│ ○ BytePlus
│ ○ Chutes
│ ○ Cloudflare AI Gateway
│ ○ Copilot Proxy
│ ○ Custom Provider
│ ○ DeepSeek
│ ○ Fireworks
│ ○ Gemini CLI OAuth
│ ○ GitHub Copilot
│ ○ Google
│ ○ Hugging Face
│ ○ Kilo Gateway
│ ○ LiteLLM
│ ○ Microsoft Foundry
│ ○ MiniMax
│ ○ Mistral AI
│ ○ Moonshot AI (Kimi K2.5)
│ ○ Ollama
│ ○ OpenAI
│ ○ OpenAI Codex
│ ○ OpenCode
│ ○ OpenRouter
│ ○ Qianfan
│ ○ Qwen Cloud
│ ○ SGLang
│ ○ StepFun
│ ○ Synthetic
│ ○ Together AI
│ ○ Venice AI
│ ○ Vercel AI Gateway
│ ○ vLLM
│ ○ Volcano Engine
│ ○ xAI (Grok)
│ ○ Xiaomi
│ ○ Z.AI
│ ○ Skip for now

what should i choose

balmy escarpBOT Apr 10, 2026, 4:13 PM

#

Choose Ollama.

It is the only realistic option there with no API key.
Then pick:

Ollama
Local (not Cloud + Local)
Base URL: http://127.0.0.1:11434
Small model (recommended): llama3.2:1b

Important: no API key needed, but you still need Ollama installed and one model pulled.

If prompted for key/token anyway, use ollama-local as the marker.

jade plank Apr 10, 2026, 4:14 PM

#

here we go again with the issues.......

Setup mode
│ QuickStart
│
◇ QuickStart ─────────────────────────╮
│ │
│ Gateway port: 18789 │
│ Gateway bind: Loopback (127.0.0.1) │
│ Gateway auth: Token (default) │
│ Tailscale exposure: Off │
│ Direct to chat channels. │
│ │
├──────────────────────────────────────╯
│
◇ Model/auth provider
│ Ollama
│
◇ Ollama base URL
│ http://127.0.0.1:11434
│
◇ Ollama ─────────────────────────────────────────────────╮
│ │
│ Ollama could not be reached at http://127.0.0.1:11434. │
│ Download it at https://ollama.com/download │
│ │
│ Start Ollama and re-run setup. │
│ │
├──────────────────────────────────────────────────────────╯
openclaw@vm-openclaw-quick:~$

balmy escarpBOT Apr 10, 2026, 4:14 PM

#

You’re on a fresh Azure VM, so this specific error is expected: Ollama is not installed there yet.

Run these on the VM, one by one:

curl -fsSL https://ollama.com/install.sh | sh

sudo systemctl enable --now ollama

curl -sS http://127.0.0.1:11434/api/tags

#

ollama pull llama3.2:1b

openclaw onboard --install-daemon

Then choose:

Provider: Ollama
Base URL: http://127.0.0.1:11434
Model: llama3.2:1b

You’re not failing, this is just a missing runtime on the new VM.

rough starBOT Apr 10, 2026, 4:15 PM

#

jade plank Apr 10, 2026, 4:16 PM

#

@rough star mind your own business please. we're making progress with Krill

balmy escarpBOT Apr 10, 2026, 4:16 PM

#

Got you, let’s keep moving.

Run this next and paste output:

curl -fsSL https://ollama.com/install.sh | sh

Then we’ll do the service start command right after.

jade plank Apr 10, 2026, 4:18 PM

#

ok so we got to here, what's next

│ Gateway port: 18789 │
│ Gateway bind: Loopback (127.0.0.1) │
│ Gateway auth: Token (default) │
│ Tailscale exposure: Off │
│ Direct to chat channels. │
│ │
├──────────────────────────────────────╯
│
◇ Model/auth provider
│ Ollama
│
◇ Ollama base URL
│ http://127.0.0.1:11434
│
◇ Ollama mode
│ Local
│
◆ Default model
│ ● Keep current (default: ollama/gemma4)
│ ○ Enter model manually
│ ○ ollama/gemma4
│ ○ ollama/llama3.2:1b

balmy escarpBOT Apr 10, 2026, 4:18 PM

#

Nice, you’re in the right place.

Choose:

ollama/llama3.2:1b (not gemma4)

Then finish the wizard with defaults.

After onboarding exits, run these:

openclaw gateway status

openclaw channels status --probe

#

If Telegram is not configured yet on this VM, then:

openclaw config set channels.telegram.botToken "<YOUR_BOT_TOKEN>"

openclaw gateway restart

openclaw channels status --probe

Paste the channels status --probe output after that and we’ll do the final test.

jade plank Apr 10, 2026, 4:22 PM

#

ok, so next in the setup is the telegram channel, i gave it my bot token, now time for web search.. i don't want local ollam sign in.. i want searxng ◇

balmy escarpBOT Apr 10, 2026, 4:22 PM

#

Perfect, then choose SearXNG in the web-search step, not Ollama sign-in.

If it asks for base URL, enter your SearXNG URL (example):

http://127.0.0.1:8888

If you do not have a SearXNG server running yet, run this first on the VM:

docker run -d -p 8888:8080 --name searxng searxng/searxng

Then set it in OpenClaw:

#

openclaw config set plugins.entries.searxng.config.webSearch.baseUrl "http://127.0.0.1:8888"

openclaw config set tools.web.search.provider searxng

openclaw gateway restart

So yes, you can skip Ollama sign-in entirely and use SearXNG.

jade plank Apr 10, 2026, 4:23 PM

#

i don;t habve a searxng url

balmy escarpBOT Apr 10, 2026, 4:23 PM

#

No worries, then don’t use SearXNG right now.

Pick DuckDuckGo for web search.
It is key-free and needs no URL/setup.

So for now:

Web search provider: DuckDuckGo
Continue onboarding
You can switch to SearXNG later when you have an instance URL

If the wizard asks again and DDG isn’t shown, choose Skip for now and we’ll set DDG after setup.

jade plank Apr 10, 2026, 4:23 PM

#

i selected skip for now, can i go back?

balmy escarpBOT Apr 10, 2026, 4:23 PM

#

Yes, you can go back. 👍

Easiest way (after onboarding finishes):

openclaw configure --section web

Then choose DuckDuckGo.

After saving:

openclaw gateway restart

So you don’t need to restart the whole setup flow.

jade plank Apr 10, 2026, 4:24 PM

#

i can't go back.. time to set up skills.. I want to skip this too

balmy escarpBOT Apr 10, 2026, 4:24 PM

#

Yes, skip it.

At the skills step, choose:

Skip for now (or None)

That is totally fine for a minimal setup.

Finish onboarding first, then we’ll configure only what you need (web + telegram) afterward.

jade plank Apr 10, 2026, 4:26 PM

#

Onboarding complete. Use the dashboard link above to control OpenClaw.

Web UI: http://127.0.0.1:18789/
Gateway WS: ws://127.0.0.1:18789 │
│ Gateway: not detected (timeout)

is this now accessible from telegram?

balmy escarpBOT Apr 10, 2026, 4:26 PM

#

Not yet, that message says Gateway is still not up (not detected (timeout)).

Run these now, one by one:

openclaw gateway start

openclaw gateway status

openclaw channels status --probe

If gateway status shows RPC probe: ok and Telegram shows works, then yes, Telegram access is ready.

jade plank Apr 10, 2026, 4:31 PM

#

everything looks good in azure cli.. but on telegram, it again takes minutes to eventual fail again

openclaw@vm-openclaw-quick:~$ openclaw gateway status

🦞 OpenClaw 2026.4.9 (0512059) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-10.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 3749, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
openclaw@vm-openclaw-quick:~$ openclaw channels status --probe

🦞 OpenClaw 2026.4.9 (0512059) — Your .zshrc wishes it could do what I do.

│
◇
Gateway reachable.

Telegram default: enabled, configured, running, mode:polling, bot:@egymasbot, token:config, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
openclaw@vm-openclaw-quick:~$

balmy escarpBOT Apr 10, 2026, 4:31 PM

#

You’re right, infra is healthy now.
So this is model latency, not Telegram/gateway.

Let’s force a fast config on the VM:

openclaw config set models.providers.ollama.models[0].id llama3.2:1b

openclaw config set models.providers.ollama.models[0].name llama3.2:1b

openclaw config set agents.defaults.model ollama/llama3.2:1b

#

openclaw config set agents.defaults.thinkingDefault off

openclaw config set tools.profile minimal

openclaw gateway restart

openclaw infer model run --model ollama/llama3.2:1b --prompt "ok" --json

Then in Telegram:

#

/model ollama/llama3.2:1b

/thinking off

hi

This should remove the “wait minutes then fail” pattern.

jade plank Apr 10, 2026, 4:32 PM

#

on telegram:

The model did not produce a response before the LLM idle timeout. Please try again, or increase agents.defaults.llm.idleTimeoutSeconds in your config (set to 0 to disable).

balmy escarpBOT Apr 10, 2026, 4:32 PM

#

Perfect, this is finally a clear error and fix.

Set the idle timeout higher (or disable it):

openclaw config set agents.defaults.llm.idleTimeoutSeconds 0 --strict-json

openclaw gateway restart

Then test Telegram again with a short message (ok).

If you prefer not to disable it completely, use 180 instead of 0.

jade plank Apr 10, 2026, 4:37 PM

#

yeah, new config applied, gateway restarted.. some error on Telegram 🙂

The model did not produce a response before the LLM idle timeout. Please try again, or increase agents.defaults.llm.idleTimeoutSeconds in your config (set to 0 to disable).

how do people make this work man

balmy escarpBOT Apr 10, 2026, 4:37 PM

#

Yeah, this is frustrating, and you’re not crazy.
Most people avoid this by using cloud models first. Local CPU setups are much touchier.

Let’s force timeout off at both levels (default + agent), then verify:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 0 --strict-json

openclaw config set agents.list[0].llm.idleTimeoutSeconds 0 --strict-json

openclaw gateway restart

#

openclaw config get agents.defaults.llm.idleTimeoutSeconds

openclaw config get agents.list[0].llm.idleTimeoutSeconds

If both show 0 and Telegram still throws idle-timeout, paste those two outputs and we’ll check if your Telegram chat is bound to a different agent/profile.

jade plank Apr 10, 2026, 4:38 PM

#

what are some free cloud models without any sign in?

balmy escarpBOT Apr 10, 2026, 4:38 PM

#

Short answer: basically none for OpenClaw.

For cloud models, providers require some auth/sign-in (abuse/cost control).
The only no-sign-in path is local models (Ollama).

For up-to-date free/cheap provider options, ask in #models and check:

If you want zero sign-in right now, stick to local Ollama.

jade plank Apr 10, 2026, 4:39 PM

#

let's forget about telegram for a moment, can we test if openclaw is actually using the local models? can i test on the local gateway web ui or something

balmy escarpBOT Apr 10, 2026, 4:40 PM

#

Yes, great idea. Test locally first, no Telegram.

Run these on the VM:

openclaw config get agents.defaults.model

openclaw models status --probe

openclaw infer model run --model ollama/llama3.2:1b --prompt "Reply with exactly: LOCAL_OK" --json

Then confirm from logs it used Ollama:

#

tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | grep -Ei "provider=ollama|model=llama3.2:1b|runId="

And yes, UI test is possible too, but easier via SSH tunnel from your laptop:

ssh -L 18789:127.0.0.1:18789 openclaw@<VM_PUBLIC_IP>

Then open http://127.0.0.1:18789 in your local browser.

jade plank Apr 10, 2026, 4:43 PM

#

ok, i'm assuming the bottleneck is the compute power of the VM.. gettiung the infer results is proving impossible as well. so let's approach this differently. does openclaw need an llm model to work? can't it just use system tools

balmy escarpBOT Apr 10, 2026, 4:43 PM

#

Good question. Short answer:

For chat/agent behavior: yes, OpenClaw needs an LLM.
For raw plumbing/admin commands: no, those can work without an LLM.

So OpenClaw can still do things like channel setup, pairing, status checks, and direct CLI actions without a model, but it cannot “think/respond/use tools intelligently” in chat without one.

If your VM can’t handle local inference, the practical options are:

smaller/faster local model, or
cloud model for reasoning, local tools for execution.

jade plank Apr 10, 2026, 4:44 PM

#

ok, let's tell openclaw to check it's own setup and make a list of anything important that is missing

balmy escarpBOT Apr 10, 2026, 4:44 PM

#

Great idea. Let’s run a full self-check and auto-summarize missing pieces.

Run these on the VM, one by one:

openclaw status --all > /tmp/openclaw-status.txt

openclaw doctor > /tmp/openclaw-doctor.txt

openclaw models status --probe > /tmp/openclaw-models.txt

#

openclaw channels status --probe > /tmp/openclaw-channels.txt

grep -Ei "error|missing|failed|timeout|warning|not found|unusable|not detected" /tmp/openclaw-*.txt

That last command gives the “important missing stuff” list directly. Paste it and I’ll translate it into a clean checklist.

jade plank Apr 10, 2026, 4:44 PM

#

let me get back to the windows 10 vm cause this might be better with a gui

balmy escarpBOT Apr 10, 2026, 4:45 PM

#

Good call, that’s a sensible move. 👍
GUI will make this much less painful.

When you’re back on the Windows VM, run these first and paste output:

openclaw gateway status

openclaw channels status --probe

openclaw config get agents.defaults.model

#

openclaw config get agents.defaults.llm.idleTimeoutSeconds

Then we’ll continue from a clean baseline there.

jade plank Apr 10, 2026, 4:45 PM

#

what about azure open ai? can we do something with that?

balmy escarpBOT Apr 10, 2026, 4:46 PM

#

Yes, absolutely, Azure OpenAI can work.

If you want that path in onboarding, choose Microsoft Foundry (or Custom Provider if you prefer manual OpenAI-compatible setup).

You will still need:

Azure endpoint URL
Azure API key
Model/deployment name

So it is viable, but it is not a no-sign-in/no-key option.

If you want, I can give you the shortest exact field-by-field values to enter in that wizard path.

jade plank Apr 10, 2026, 4:48 PM

#

i want to test the openclaw gui in windows 10

balmy escarpBOT Apr 10, 2026, 4:49 PM

#

Nice, let’s do that.

If your gateway is on the Azure Linux VM, from Windows 10 PowerShell run:

ssh -L 18789:127.0.0.1:18789 openclaw@<VM_PUBLIC_IP>

Keep that terminal open, then in Windows browser open:

http://127.0.0.1:18789

If the gateway is running locally on Windows instead, just open:

#

http://127.0.0.1:18789

(Or run openclaw dashboard.)

jade plank Apr 10, 2026, 4:49 PM

#

the gateway should be running on the windows 10 vm

balmy escarpBOT Apr 10, 2026, 4:50 PM

#

Perfect, then this is easy.

On the Windows 10 VM itself:

openclaw gateway status

If it is not running:

openclaw gateway start

Then open in that VM’s browser:

#

http://127.0.0.1:18789

If the page asks for auth, use your gateway token/password from config.
(You can also run openclaw dashboard to print/open the correct URL.)

jade plank Apr 10, 2026, 4:59 PM

#

well, the gui is working. it's just taking extremely long to respond to even a hi. current ai model loaded in the web ui appears to be qwen3 coder:30b, but I can't seem to change it. can I pause it somehow to reload the model

balmy escarpBOT Apr 10, 2026, 4:59 PM

#

Yes, you can force it off and switch.

Run on the VM:

ollama stop qwen3-coder:latest

openclaw config set agents.defaults.model ollama/gemma4

openclaw gateway restart

Then in the Web UI chat, send:

#

/model ollama/gemma4

If the current chat is still stuck on qwen, start a new chat/session in the UI, then send hi.

(Your slowdown is likely from qwen 30b being too heavy for that machine.)

jade plank Apr 10, 2026, 5:01 PM

#

ok, so I stopped qwen3-coder:30b, now how do I load maybe a smaller mode? i want to smallest, easiest to run model. can I do it freom ai&agent model catalog?

balmy escarpBOT Apr 10, 2026, 5:01 PM

#

Yes, you can use the model catalog if the model is listed there.
If it is not listed, do this once via CLI (fastest path):

ollama pull llama3.2:1b

openclaw config set models.providers.ollama.models[0].id llama3.2:1b

openclaw config set models.providers.ollama.models[0].name llama3.2:1b

#

openclaw config set agents.defaults.model ollama/llama3.2:1b

openclaw config set agents.defaults.thinkingDefault off

openclaw config set tools.profile minimal

openclaw gateway restart

Then in UI/chat:

#

/model ollama/llama3.2:1b

That is about as small/easy as it gets for local Ollama.

jade plank Apr 10, 2026, 5:02 PM

#

is llama3.2:1b really the smallest model?

balmy escarpBOT Apr 10, 2026, 5:02 PM

#

Not necessarily.

The safest answer is: pick the smallest model you actually have installed.

Run:

OLLAMA_HOST=127.0.0.1:11434 ollama list | tail -n +2 | sort -hk3

Top row after sorting is your smallest installed model by size.
Use that exact name in OpenClaw:

openclaw config set agents.defaults.model ollama/<EXACT_MODEL_NAME>

#

If you paste that sorted list, I’ll point to the best one directly.

jade plank Apr 10, 2026, 5:06 PM

#

how can i list which ollama models i currently have

balmy escarpBOT Apr 10, 2026, 5:06 PM

#

Run:

ollama list

If you want to force the local endpoint explicitly:

OLLAMA_HOST=127.0.0.1:11434 ollama list

jade plank Apr 10, 2026, 5:08 PM

#

i want openclaw to use llama3.2:1b, and I want to select it from openclaw's web uit on 127.0.0.1:18789
Current models:
ollama/llama3.2:1b

balmy escarpBOT Apr 10, 2026, 5:09 PM

#

Perfect. Do both, so config + current session are aligned.

In Web UI (`127.0.0.1:18789`)

Go to AI & Agents
Open agent main
Set Default Model to ollama/llama3.2:1b
Save/Apply

In the current chat (Web UI chat box)

Send:

/model ollama/llama3.2:1b

Then send:

#

/model status

You should see Current/Active as ollama/llama3.2:1b.
If it still sticks to old model, start a new chat/session once after saving.

jade plank Apr 10, 2026, 5:09 PM

#

can't find agent "main"

balmy escarpBOT Apr 10, 2026, 5:09 PM

#

No worries, skip the UI agent picker then, let’s force it via CLI.

Run on the VM:

openclaw config set agents.defaults.model ollama/llama3.2:1b

openclaw gateway restart

Then in the Web chat:

/model ollama/llama3.2:1b

#

/model status

That works even if the UI doesn’t show an agent named main.

jade plank Apr 10, 2026, 5:10 PM

#

no, no, where can I find agent main

balmy escarpBOT Apr 10, 2026, 5:10 PM

#

Got it.

main is often the implicit default agent, so in UI it may not appear as a separate card.

Where to look:

AI & Agents → Defaults (this is effectively main if no custom agents were added)

If you want to verify from CLI:

openclaw config get agents.list

openclaw config get agents.defaults.model

#

If agents.list is empty or has no custom IDs, then “main” = defaults.

#llm request failed

Fix

Option A, add Ollama to the allowlist

Option B, remove the allowlist

Important

Remove the model restrictions

1. Remove the allowlist

2. Restart the gateway

3. Verify the allowlist is gone

If you want Ollama to be the default too

4. Set the default model to Ollama

5. Restart again

6. Verify

Then test from Telegram

Important note

Do this exact check sequence on the gateway host

Fix

If pull fails

Fastest unblock (right now)

Fix WSL Ollama version mismatch

1) Hard-pin default to Ollama only (no fallback noise)

2) Test model path directly from CLI

3) Check what Telegram session is using

4) Capture the real error line while reproducing

Do this exactly

One command only (temporary)

For current shell session

Persist it (future shells)

1) Force exact model id in config (and verify)

2) Force local Ollama auth marker

3) Retest

Recommended now (works fastest): switch to cloud temporarily

If you want to stay local-only right now

1) Create VM (from your local machine)

2) SSH into VM and install OpenClaw

3) (Optional) Access dashboard safely via SSH tunnel from your laptop

Run in Azure Cloud Shell

Then run these inside the VM shell

In Web UI (127.0.0.1:18789)

In the current chat (Web UI chat box)

In Web UI (`127.0.0.1:18789`)