OpenClaw says the LLM request timed out

A timed-out model request is one of the first errors people meet after switching OpenClaw to a local model, and the docs’ troubleshooting pages give it a short list of causes. Most are about the local backend: a large model loading cold, a context window the hardware cannot carry, a host that answers curl but not the Gateway. Two are about hosted providers, a rate limit dressed as a 429 and an upstream block dressed as a 403. Here is each one with its fix, in the order the docs suggest trying them.

The local causes

• A cold model: large local models can need a long first load. Scope a longer timeout to the Ollama provider, the docs’ example being 300 seconds, and keep the model loaded between turns with a keep-alive parameter on the model entry; the same setting also extends the connect timeout when the host is slow to accept connections.
• A context window too large: many models advertise contexts the hardware cannot run comfortably. Cap both OpenClaw’s token budget and the request context on the model entry for predictable first-token latency.
• A host that works with curl but not OpenClaw: verify from the machine and runtime that runs the Gateway, because a base URL that says localhost points nowhere from a Docker container, the URL may carry the OpenAI-compatible suffix that changes behaviour, the remote host may need firewall or binding changes, and the model may be on the laptop’s daemon rather than the remote one.

Large local models can need a long first load.

The backend that passes probes and still fails

The provider troubleshooting page has a case for a local OpenAI-compatible backend that answers direct tiny requests and still fails agent runs: the transport is probably right and the backend is failing on the larger agent-runtime prompt shape, Gemma on some llama-server builds being the docs’ example. An incomplete-turn message with no payloads means the backend completed the request but returned no visible text; OpenClaw retries such a turn once. If failures shrink after disabling tools but do not disappear, tool schemas were part of the pressure and the rest is the backend’s capacity or a bug.

The hosted causes

• A 429 saying extra usage is required for long context: the selected Anthropic model has a native million-token window, or an old config still carries the legacy long-context flag, and the credential is not eligible. Switch to a standard window, use an eligible credential or an API key, and configure fallback models so runs continue.
• A generic 403 saying the request was blocked: not always an OpenClaw problem; it can come from a CDN, a WAF, a bot-management rule or a reverse proxy in front of an OpenAI-compatible endpoint, so check status, the Gateway status and the logs before changing config.
• The wrong URL: the OpenAI-compatible suffix on an Ollama host breaks tool calling and can make a model print tool JSON as text; the native URL, without the suffix, is the fix.

OpenClaw with Ollama has the full local-model page, and OpenClaw not responding is the ladder when the symptom is silence rather than a timeout.

How to look

Every one of these starts with the same three commands the docs repeat: follow the logs, check the models status, and read the model config. OpenClaw logs explains where the file is and how to tail it.

On Diali

On Diali the models are hosted and the timeouts are ours to tune, so the local half of this list does not apply; the hosted half is handled by fallback routing before a reply is lost. Hosted OpenClaw on Diali is the assistant.

• Cold model: a longer provider timeout and a keep-alive.
• Too much context: cap the budget and the request context.
• A 429 or 403 is the provider, not the Gateway.