openclaw - 💡(How to fix) Fix [Bug]: models.providers.<id>.timeoutSeconds not applied to LLM idle watchdog — hardcoded 120s timeout kills slow local models [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Summary

The models.providers.<id>.timeoutSeconds config key is documented as extending the LLM idle watchdog for slow local/self-hosted providers, but it has no effect at runtime. The idle watchdog is hardcoded to 120 seconds regardless of any config value, causing every request to a slow local model (Ollama, llama.cpp, etc.) to fail with a timeout before the first token arrives.

Environment

• OpenClaw version: 2026.5.18
• Deployment: Docker (ghcr.io/openclaw/openclaw:latest)
• Local model: Ollama with llama3.2 (CPU-only, no GPU)

Config (relevant excerpt)

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 1200
    }
  },
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://host.docker.internal:11434",
        "timeoutSeconds": 1200,
        "api": "ollama"
      }
    }
  }
}

Observed behavior

Every agent turn times out after exactly 120 seconds with these log lines:

[fetch-timeout] fetch timeout after 120000ms (elapsed 120000ms) operation=fetchWithSsrFGuard url=http://host.docker.internal:11434/api/chat [agent/embedded] Profile ollama:default idle timeout (model silent). Trying next account... [agent/embedded] [llm-idle-timeout] ollama/llama3.2-agente produced no reply before the idle watchdog; retrying same model

Root cause (traced through compiled dist/)

By inspecting /app/dist/stream-Cqv5P1VW.js inside the Docker container:

// stream-Cqv5P1VW.js
function resolveOllamaRequestTimeoutMs(model, options) {
    const raw = options?.requestTimeoutMs ?? options?.timeoutMs ?? model.requestTimeoutMs;
    return typeof raw === "number" && Number.isFinite(raw) && raw > 0 
        ? Math.floor(raw) 
        : void 0;
}

// called as:
timeoutMs: resolveOllamaRequestTimeoutMs(model, options),

The agent runner passes options.timeoutMs = 120000 (the hardcoded idle watchdog default) when calling the Ollama stream function. Because options.timeoutMs has higher priority than model.requestTimeoutMs in the ?? chain, any value set via models.providers.ollama.timeoutSeconds in the config is completely ignored.

Additionally, /app/dist/extensions/ollama/runtime-api.js and all files under /app/dist/extensions/ollama/ contain zero references to timeoutSeconds, timeoutMs, or any timeout configuration — the Ollama plugin never reads the provider-level timeout from config.

Attempted workarounds

• agents.defaults.timeoutSeconds: 1200 → ignored (same 120s timeout)
• models.providers.ollama.timeoutSeconds: 1200 → ignored
• agents.defaults.llm.idleTimeoutSeconds: 1200 → schema validation error: agents.defaults: Invalid input (field not present in schema for 2026.5.18)
• OPENCLAW_TIMEOUT_MS: 6000000 env var → not consumed by the runtime

Additional notes

The issue makes OpenClaw unusable with any CPU-only local model that takes more than ~60–90 seconds to produce its first token (cold start + inference on modest hardware). The workaround of setting OLLAMA_KEEP_ALIVE=-1 on the Ollama systemd service reduces cold-start time but does not solve the underlying problem for longer prompts or slower hardware.

Steps to reproduce

Steps to Reproduce

1. Install OpenClaw via Docker using the official image ghcr.io/openclaw/openclaw:latest (tested on 2026.5.18)

2. Configure a local Ollama provider in openclaw.json with an extended timeout:

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 1200
    }
  },
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://host.docker.internal:11434",
        "timeoutSeconds": 1200,
        "api": "ollama",
        "models": [
          {
            "id": "llama3.2",
            "name": "llama3.2",
            "contextWindow": 9000,
            "maxTokens": 8192
          }
        ]
      }
    }
  }
}

1. Set agents.defaults.model.primary to ollama/llama3.2

2. Run Ollama locally with any model that takes more than ~90 seconds to produce its first token on CPU-only hardware (no GPU). Examples: llama3.2, gemma, mistral on a machine without a dedicated GPU.

3. Start the OpenClaw gateway: docker compose up

4. Send any message to the agent via a configured channel (e.g. Telegram) or via the Control UI at http://localhost:18789

Observed result

The request fails after exactly 120 seconds regardless of the configured timeoutSeconds values, with the following lines in the gateway log:

[fetch-timeout] fetch timeout after 120000ms (elapsed 120000ms) operation=fetchWithSsrFGuard url=http://host.docker.internal:11434/api/chat [agent/embedded] Profile ollama:default idle timeout (model silent). Trying next account... [agent/embedded] [llm-idle-timeout] ollama/llama3.2 produced no reply before the idle watchdog; retrying same model

Expected behavior

Setting models.providers.ollama.timeoutSeconds: 1200 (or agents.defaults.timeoutSeconds: 1200) should extend the idle watchdog to 1200 seconds, as documented.

Actual behavior

The request fails after exactly 120 seconds regardless of the configured timeoutSeconds values, with the following lines in the gateway log:

[fetch-timeout] fetch timeout after 120000ms (elapsed 120000ms) operation=fetchWithSsrFGuard url=http://host.docker.internal:11434/api/chat [agent/embedded] Profile ollama:default idle timeout (model silent). Trying next account... [agent/embedded] [llm-idle-timeout] ollama/llama3.2 produced no reply before the idle watchdog; retrying same model

OpenClaw version

2026.5.18

Operating system

Ubuntu 26.04

Install method

docker

Model

llama3.2

Provider / routing chain

OpenClaw Gateway (Docker, port 18789) → fetchWithSsrFGuard (internal HTTP client, stream-Cqv5P1VW.js) → Ollama HTTP API (http://host.docker.internal:11434/api/chat) → llama3.2 (CPU-only inference, no GPU) No external proxies or model routers involved. Provider config: api="ollama", direct connection from container to host via Docker host-gateway extra_hosts mapping.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response