openclaw - 💡(How to fix) Fix agents.defaults.timeoutSeconds not respected for local OpenAI-compatible providers [4 comments, 5 participants]

Description

agents.defaults.timeoutSeconds in openclaw.json is not respected when using local OpenAI-compatible providers (Ollama, mlx_vlm.server). Requests to local 31B models time out after ~30 seconds despite the config being set to 600.

Environment

• OpenClaw 2026.4.2
• macOS (Apple Silicon, 128GB)
• Model: Gemma 4 31B (Q8_0 via Ollama, 8-bit via mlx_vlm.server)
• Provider config: api: "openai-completions", baseUrl: "http://127.0.0.1:11434/v1"

Config

"agents": {
  "defaults": {
    "timeoutSeconds": 600,
    ...
  }
}

Observed behavior

• Direct curl to local server works fine (2-8 seconds warm, 19-33 seconds cold)
• OpenClaw consistently times out after ~30 seconds with: "Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config."
• The resolveAgentTimeoutSeconds() function in content-blocks-CWb2xgCb.js correctly reads the config value
• The timeout appears to originate from the WebSocket RPC layer or the AI SDK's internal fetch/stream timeout, not from the agent turn timeout

Investigation

Traced through the code:

• resolveAgentTimeoutMs in content-blocks-CWb2xgCb.js:750 correctly resolves config value
• resolveTurnTimeoutMs in pi-embedded-BYdcxQ5A.js:13343 correctly calls the above
• DEFAULT_AGENT_TIMEOUT_SECONDS is 172800 (48h) — not the bottleneck
• The actual abort happens before the configured timeout fires
• MLX server logs show socket.send() raised exception (OpenClaw disconnects) while the model is still processing
• A requestTimeout provider-level config key is rejected as "Unrecognized key"

Related

• #46049 (LLM request timeout ignores configured timeout settings)
• #43946 (Configurable LLM request timeout per provider/model)

Expected

The timeoutSeconds config should control ALL timeouts in the request chain, including the underlying HTTP/WebSocket transport to the LLM provider. For local models that need 60-120 seconds to prefill large system prompts, 30 seconds is unusable.

Workaround needed

Please either:

1. Respect agents.defaults.timeoutSeconds end-to-end, OR
2. Add a per-provider timeoutMs config key (currently rejected), OR
3. Document which internal timeout is the actual bottleneck so it can be patched