Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: LLM HTTP request timeout hardcoded at ~60s — ignores agents.defaults.timeoutSeconds and per-job timeoutSeconds for local models (Ollama/exo) [1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#61487•Fetched 2026-04-08 02:58:04
View on GitHub
Comments
1
Participants
1
Timeline
5
Reactions
0
Author
kinghonkinghon
Participants
kinghonkinghon
Timeline (top)
cross-referenced ×2closed ×1commented ×1subscribed ×1

All isolated agent sessions using local LLM providers (Ollama, exo/OpenAI-compatible) time out at exactly ~61 seconds with:

Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

This happens regardless of:

  • agents.defaults.timeoutSeconds: 300 (global config)
  • payload.timeoutSeconds: 300 (per-cron-job)
  • lightContext: true (reduced system prompt)
  • Model being warm and responding in <1s to direct curl

The timeout is in the HTTP fetch from OpenClaw's LLM client to the provider endpoint, not in the job scheduler.

Error Message

status=error, dur=61s, errors=9, reason=timeout

Root Cause

All isolated agent sessions using local LLM providers (Ollama, exo/OpenAI-compatible) time out at exactly ~61 seconds with:

Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

This happens regardless of:

  • agents.defaults.timeoutSeconds: 300 (global config)
  • payload.timeoutSeconds: 300 (per-cron-job)
  • lightContext: true (reduced system prompt)
  • Model being warm and responding in <1s to direct curl

The timeout is in the HTTP fetch from OpenClaw's LLM client to the provider endpoint, not in the job scheduler.

Code Example

curl -s --max-time 10 http://localhost:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"gemma4:e4b","messages":[{"role":"user","content":"Say OK"}],"max_tokens":5}'
# Response in 0.5s

---

status=error, dur=61s, errors=9, reason=timeout
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Severity

serious bug renders local model agents unusable

Version

OpenClaw 2026.4.2 (d74a122) on macOS 26 Tahoe (arm64)

Summary

All isolated agent sessions using local LLM providers (Ollama, exo/OpenAI-compatible) time out at exactly ~61 seconds with:

Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

This happens regardless of:

  • agents.defaults.timeoutSeconds: 300 (global config)
  • payload.timeoutSeconds: 300 (per-cron-job)
  • lightContext: true (reduced system prompt)
  • Model being warm and responding in <1s to direct curl

The timeout is in the HTTP fetch from OpenClaw's LLM client to the provider endpoint, not in the job scheduler.

Steps to reproduce

  1. Configure Ollama provider with baseUrl: http://localhost:11434/v1
  2. Set agents.defaults.timeoutSeconds: 300
  3. Create an isolated cron job with model: ollama/gemma4:e4b and timeoutSeconds: 300
  4. Trigger the job
  5. Job dies at ~61s every time

Evidence

Direct curl to the same model succeeds in 0.5s (model is warm via OLLAMA_KEEP_ALIVE=-1):

curl -s --max-time 10 http://localhost:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"gemma4:e4b","messages":[{"role":"user","content":"Say OK"}],"max_tokens":5}'
# Response in 0.5s

But OpenClaw isolated sessions with the same model timeout at 61s:

status=error, dur=61s, errors=9, reason=timeout

Same issue with exo/mlx-community/Kimi-K2.5 (remote OpenAI-compatible endpoint). The model responds to direct curl in 5-15s but OpenClaw kills the connection at 61s.

The 61s timeout appears to be a hardcoded HTTP fetch timeout in the LLM client that is not connected to agents.defaults.timeoutSeconds.

What works vs what doesn't

ScenarioResult
Cron jobs with model=anthropic/claude-sonnet-4-6✅ Works (Anthropic responds in <5s)
Cron jobs with model=exo/mlx-community/Kimi-K2.5 (simple prompt, Kimi not busy)✅ Sometimes works
Cron jobs with model=exo/mlx-community/Kimi-K2.5 (complex prompt OR Kimi mid-request)❌ Always times out at 61s
Cron jobs with model=ollama/gemma4:e4b (any prompt, model warm)❌ Always times out at 61s
Direct curl to same endpoints✅ Always works

Expected behavior

The HTTP request to the LLM provider should respect agents.defaults.timeoutSeconds (or the per-job timeoutSeconds) as the maximum wait time for first token, not a hardcoded 60s.

Related issues

  • #59604 — same bug, filed 3 days ago
  • #46049 — LLM request timeout ignores configured timeout settings
  • #43946 — Ollama cold-start causes silent fallback due to request timeout

Environment

  • macOS 26.3 Tahoe (arm64, Mac mini M4 Pro)
  • Ollama 0.9.0 with gemma4:e4b (OLLAMA_KEEP_ALIVE=-1)
  • Exo cluster (2x Mac Studio M3 Ultra 512GB) serving Kimi-K2.5
  • OpenClaw 2026.4.2 (d74a122)
  • Node v25.4.0

extent analysis

TL;DR

The likely fix is to modify the LLM client in OpenClaw to respect the configured agents.defaults.timeoutSeconds instead of using a hardcoded 61-second timeout.

Guidance

  • Investigate the LLM client code in OpenClaw to identify where the hardcoded 61-second timeout is set and modify it to use the configured timeout value.
  • Verify that the agents.defaults.timeoutSeconds value is being correctly passed to the LLM client and used as the timeout value.
  • Test the modified LLM client with different timeout values to ensure it respects the configured timeout.
  • Consider adding logging or debugging statements to the LLM client to help diagnose any further issues with timeout handling.

Example

No code example is provided as the issue does not include specific code snippets or APIs to modify.

Notes

The fix may require modifying the OpenClaw codebase, which could involve updating dependencies or modifying internal implementation details. Additionally, the issue may be related to other reported issues (#59604, #46049, #43946), and resolving this issue may require coordinating with other developers or teams.

Recommendation

Apply a workaround by modifying the LLM client to respect the configured timeout value, as upgrading to a fixed version is not mentioned in the issue. This recommendation is based on the information provided in the issue and may need to be adjusted if additional details become available.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The HTTP request to the LLM provider should respect agents.defaults.timeoutSeconds (or the per-job timeoutSeconds) as the maximum wait time for first token, not a hardcoded 60s.

#parallel task#integration issue#index setup#retrieval issue#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING