#how to fix LLM request timed out for openclaw

1 messages · Page 1 of 1 (latest)

lean heath
#

My PC crashed after a screenshot failure and I restarted my system and openclaw keeps sitting "LLM request timed out". I use Ollama local for my LLM

vivid lichenBOT
#

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

indigo sluiceBOT
#

This almost always means OpenClaw can’t get a response from Ollama anymore (Ollama not running, not reachable from where the Gateway runs, or the baseUrl changed after the crash).

1) First: grab a quick snapshot (safe to paste here)

openclaw --version
openclaw status --all
openclaw models status

2) Verify Ollama is actually responding
On the same machine where the OpenClaw Gateway is running:

curl http://127.0.0.1:11434/api/tags
  • If that hangs/fails → restart Ollama (however you normally run it) and retry the curl.
  • If that works → the problem is usually OpenClaw pointing at the wrong URL (or running in a different environment like Docker/WSL where 127.0.0.1 isn’t your host).
#

3) Double-check you’re using the native Ollama API URL (no /v1)
If you set baseUrl, it should look like:

  • http://127.0.0.1:11434 âś…
  • not http://127.0.0.1:11434/v1 ❌ (this breaks tool calling and can behave weirdly)

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

4) Restart the Gateway after the crash

openclaw gateway restart

If you paste the output of openclaw status --all + openclaw models status (and whether the curl /api/tags works), I can tell you which of the above it is in one pass.

lean heath
#

ok I got it to work.
Why is that every time my openclaw calls a tool and if that command throws an error, it stops the response. I want it to keep going and handle errors.

indigo sluiceBOT
#

Two different things can happen, and they feel the same from the chat UI:

1) The tool call itself errors (OpenClaw-side) → run ends early

If the tool throws at the framework level (permission denied, approval denied, sandbox blocked, node offline, browser crashed, etc.), the agent loop will usually end the run and emit a tool-error style reply (or at least log it). It doesn’t automatically “continue the plan” because the model never got the expected output to base the next steps on.

If you’re not seeing the error text, turn on visibility and check logs:

openclaw logs --follow

(or /verbose on in chat, if you’re using the TUI/Control UI)

2) The command returns non‑zero (your command failed) → model should be able to continue, but many local models don’t recover well

For exec-style commands, a non-zero exit code is data the model can react to — but weaker/local models often “derail” after a tool failure and stop producing a coherent follow-up.

Practical workaround (for exec): make the tool call never “hard fail”, but still report the error
Wrap the command so the shell exits 0, and print the real exit code:

# 
bash -lc 'set +e; your_command_here; ec=$?; echo "__exit_code=$ec"; exit 0'

Now the tool call succeeds, and the agent can read __exit_code=… and decide what to do next.

3) The real fix: teach the agent how you want errors handled

Add a rule to your agent prompt (AGENTS.md / system prompt) like:

  • “If a tool fails or exit code != 0: explain what failed, try 1 alternative, then continue with the rest of the task (best-effort). Don’t go silent.”

Quick question so I can be precise:

Which tool is it failing on when it “stops the response” — exec (shell command), browser, or something else? If you paste the relevant log chunk around the failure, I can tell you whether it’s case (1) framework abort vs (2) command non-zero vs (local model) recovery.

lean heath
#

ok i fixed it.
How do I fix my agent from running a process and then stopping the chat because soemthing is running? Why cant it continue?

indigo sluiceBOT
#

Because a single OpenClaw run is basically single-threaded: while the agent is waiting on a tool result (especially exec), it can’t also “keep chatting” in the same session. Until the tool returns, there’s nothing new for the model to react to, so the chat looks like it “stopped”.

What you want is: start the long thing, detach, reply immediately, then check back later.

Fix (recommended): background the command + poll later

Have it run the command with background: true (or a small yieldMs) so exec returns immediately with a sessionId, then the agent can continue responding.

Example pattern:

  • start job: exec ... background:true (or yieldMs: 1000)
  • later: process poll sessionId=... to see output / exit code

Docs:

If it’s “blocking the chat” because you’re sending more messages mid-run

That’s the queue behavior: your new messages get queued until the current run ends. Options: