Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug] LLM Request Timeout 在所有 Agent 中重复出现，本地模型和在线模型均受影响 [4 comments, 5 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#62278•Fetched 2026-04-08 03:06:48
View on GitHub
Comments
4
Participants
5
Timeline
4
Reactions
1
Author
pspigpspig
Participants
dhqdbbdhqdbbhakutakushakutakuskinaxngkinaxngpspigpspigZephyr69Zephyr69
Timeline (top)
commented ×4

Code Example

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

---

# 任务：读取大量文件 → 分析 → 写入 Neo4j
# 耗时约 70~90 秒
RAW_BUFFERClick to expand / collapse

LLM Request Timeout 在所有 Agent 中重复出现，本地模型和在线模型均受影响

现象描述

在使用 OpenClaw (v2026.4.2) 执行 耗时超过 60 秒的任务（例如：读取大量文件 → 处理 → 写入 Neo4j）时，所有 Agent（包括 main、usopp、codex 等）都会在 约 60 秒后超时，返回：

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

关键特征

  1. ❌ 不是本地模型问题：同样的模型，在 openai-codex 中运行无问题
  2. ❌ 不是在线模型问题：切换到 Moonshot/Kimi 也会超时
  3. ❌ 不是网络问题：curl 直连本地 LLM (localhost:8000) 瞬间返回
  4. ❌ 配置无效：设置 agents.defaults.timeoutSeconds: 300 无效
  5. ✅ 本地 LLM 服务健康：curl http://localhost:8000/v1/models 返回正常
  6. ✅ Gateway 运行正常：无异常日志，其他工具（如搜索）正常

复现步骤

环境

  • OpenClaw: v2026.4.2 (npm 全局安装)
  • Node.js: v24.14.1
  • 本地 LLM: Qwen3-Coder-Next-4bit (ollama/llama-server)
  • 本地 LLM 端口: http://127.0.0.1:8000/v1

复现任务

# 任务：读取大量文件 → 分析 → 写入 Neo4j
# 耗时约 70~90 秒

执行方式

  • 通过飞书群聊/私聊触发 Agent 执行任务
  • 所有 Agent（main、usopp、codex 等）均复现

预期结果

  • Agent 成功完成任务并返回结果

实际结果

  • Task 执行约 60 秒后超时，返回 "Request timed out"

已尝试的解决办法（全部无效）

尝试方案是否有效原因
设置 agents.defaults.timeoutSeconds: 300❌OpenClaw 忽略该配置
设置 agents.defaults.llm.idleTimeoutSeconds: 300❌无效
设置 gateway.timeoutSeconds: 300❌timeoutSeconds 不是合法配置项
设置 gateway.http.timeoutMs: 300000❌http.timeoutMs 不是合法配置项
设置 provider timeoutMs: 300000❌timeoutMs 不是合法配置项
Gateway 重启多次❌无效
OpenClaw 升级/降级❌所有版本均复现

对比测试（关键线索）

环境模型任务结果
OpenClawQwen3-Coder-Next-4bit (本地)元数据导入 Neo4j❌ 超时 60 秒
OpenClawKimi K2.5 (在线)元数据导入 Neo4j❌ 超时 60 秒
openai-codexQwen3-Coder-Next-4bit (本地)同上任务✅ 正常完成 (耗时 70+ 秒)
curlQwen3-Coder-Next-4bit (本地)/v1/chat/completions✅ 瞬间响应

关键线索

  • ❌ OpenClaw 所有 Agent 都有问题
  • ✅ openai-codex 没问题
  • ✅ curl 直连本地模型没问题
  • 🎯 结论：OpenClaw 的 HTTP client 或 Agent runner 有硬编码的 60 秒超时

相关 GitHub Issues

  1. Issue #46049: LLM request timeout ignores configured timeout settings

    • 用户设置 timeoutSeconds: 86400 无效
    • "internal HTTP request timeout used for model providers does not respect user-configured timeout values"

  2. Issue #17613: Embedded agent times out connecting to local OpenAI-compatible LLM

    • curl 直接调用成功，但 OpenClaw embedded agent 卡 90+ 秒后超时

  3. Issue #61487: LLM HTTP request timeout hardcoded at ~60s

    • "hardcoded 60-second timeout for LLM requests**

建议修复方向

  1. 检查 OpenClaw 内部 HTTP client 的默认超时设置

    • 是否有硬编码的 60 秒超时？
    • 是否应该继承 agents.defaults.timeoutSeconds？
    • 是否应该继承 gateway.timeoutSeconds？

  2. 暴露可配置的 HTTP timeout

    • 在 models.providers 里添加 timeoutMs 字段
    • 在 gateway 里添加 http.timeoutSeconds 字段

  3. 增强超时日志

    • 当前日志只说 "Request timed out"
    • 应该明确说明 "hardcoded 60s timeout triggered" 或 "configured timeout not respected**

联系方式

  • 邮箱: [email protected]
  • GitHub: pspig88
  • 飞书 ID: ou_b088efed73f07ba1f3da285d05742124

报告生成时间: 2026-04-07 OpenClaw 版本: v2026.4.2

extent analysis

TL;DR

  • The most likely fix is to modify the OpenClaw internal HTTP client to respect the user-configured timeout settings, rather than using a hardcoded 60-second timeout.

Guidance

  • Check the OpenClaw internal HTTP client for a hardcoded 60-second timeout and consider making it configurable.
  • Review the agents.defaults.timeoutSeconds and gateway.timeoutSeconds settings to ensure they are being respected by the OpenClaw internal HTTP client.
  • Consider adding a timeoutMs field to the models.providers configuration and a http.timeoutSeconds field to the gateway configuration to make the timeout configurable.
  • Enhance the timeout logging to provide more informative error messages, such as "hardcoded 60s timeout triggered" or "configured timeout not respected".

Example

No code snippet is provided as the issue does not contain sufficient information to generate a specific code example.

Notes

  • The issue seems to be related to a hardcoded timeout in the OpenClaw internal HTTP client, which is not respecting the user-configured timeout settings.
  • The problem is not specific to a particular model or environment, as it is reproducible with different models and configurations.
  • The issue may require modifications to the OpenClaw internal HTTP client or the addition of new configuration options to make the timeout configurable.

Recommendation

  • Apply a workaround by modifying the OpenClaw internal HTTP client to respect the user-configured timeout settings, as the hardcoded 60-second timeout is causing the issue.
  • This recommendation is based on the analysis of the issue and the fact that the hardcoded timeout is not respecting the user-configured settings.

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…
#generation error#database connection#vector store#embedding generation#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