Files
openclaw/src
yujiawei 9e9feb52f4 fix(llm-idle-timeout): honor models.providers.<id>.timeoutSeconds for cloud providers
The schema.help text for `models.providers.*.timeoutSeconds` documents the
key as the user-facing knob for "slow local or self-hosted model servers".
In practice the option is also the only configurable lever for the LLM
idle/first-token watchdog. However `resolveLlmIdleTimeoutMs` was still
running the explicit provider timeout through `clampImplicitTimeoutMs`,
clamping it back down to the implicit ~120s `DEFAULT_LLM_IDLE_TIMEOUT_MS`
ceiling for any non-cron, non-local provider.

Consequence (matches #77744 and #78361):
- User sets `models.providers.llamacpp.timeoutSeconds: 14400` (or 600 for
  a slow Gemini/Opus turn with a large tool payload).
- Hot reload accepts the value, runtime resolves
  `modelRequestTimeoutMs = 14_400_000`.
- Idle watchdog still trips at ~120s with
  "LLM idle timeout (120s): no response from model", aborting an
  otherwise-healthy upstream that is mid-prefill or buffering thinking
  tokens.

Fix: when the caller passes an explicit `modelRequestTimeoutMs`
(sourced from `models.providers.<id>.timeoutSeconds` /
`model.requestTimeoutMs`), treat it as a deliberate ceiling for cloud
providers too. The run-timeout / agent-timeout bounds still apply via
`timeoutBounds`, so a shorter explicit run timeout always wins. The
implicit default watchdog still kicks in when the user has not set a
provider timeout, preserving the network-silence-as-hang guard for
default configs.

Updated the two corresponding test cases that asserted the old
clamp-on-cloud behavior; all 71 tests in `llm-idle-timeout.test.ts`
and the wider 430-test `src/agents/pi-embedded-runner/run/` lane pass.
Schema help text refreshed to call out that the same knob raises the
idle watchdog ceiling.

Refs: #77744, #78361
2026-05-19 17:16:48 +01:00
..