Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

google/gemini-3.1-pro-preview always hits LLM idle timeout: no response from model in agent runs, regardless of how high
models.providers.google.timeoutSeconds is set. The exact same model + prompt size returns successfully in 2-3 seconds via a plain curl to
generativelanguage.googleapis.com. Symptoms match #64710 but specifically for Gemini 3.1 Pro with thinking enabled.

Environment

• OpenClaw: 2026.4.29 (a448042)
• Node: 22.22.2
• OS: Linux (GCP, europe-west3)
• Provider: google via direct GEMINI_API_KEY env (no proxy, no Vertex)
• Model: gemini-3.1-pro-preview (inputTokenLimit: 1048576, supports generateContent/streaming)
• Channel: telegram
• Workload: agent main session, ~33K tokens total prompt (20K systemPrompt with 134 skills + 28 tools / 12K of tool defs + 5 messages history)

Actual

Suspected cause

provider-stream-shared ships retainThoughtSignature and resolveGoogleGemini3ThinkingLevel, but the iterator wrapper in selection.streamWithIdleTimeout
only resets the idle timer when the underlying iterator yields. Gemini 3 Pro emits thoughtSignature chunks during the thinking phase (we observed this in
direct API streaming tests), and on Marco's actual prompt the time-to-first-visible-token genuinely exceeds the wall-clock timeout even though the model
is producing thinking-frames continuously.

If the streaming layer treats thoughtSignature-only chunks as "no token activity" the idle timer is never reset, and the watchdog kills the stream that
would have completed.

Other paths checked and ruled out:

• Override pin verified (modelOverride=gemini-3.1-pro-preview, modelOverrideSource=user, providerOverride=google in sessions.json).
• thinkingLevel correctly resolved to high (HIGH for Gemini 3 Pro), not adaptive. So unbounded-thinking is NOT the root cause.
• Provider has fresh OAuth via Claude CLI for anthropic fallback — but failover never triggers because the run is "in flight" until the watchdog fires.
• agents.defaults.timeoutSeconds is unset → falls through to DEFAULT_LLM_IDLE_TIMEOUT_MS = 120s which is implicit-clamped. Only
  models.providers.google.timeoutSeconds * 1000 reaches params.model.requestTimeoutMs and bypasses the clamp.

Workarounds

• /model gemini-flash (google/gemini-flash-latest) — works fine in same setup, 1-2s responses.
• /model sonnet (anthropic/claude-sonnet-4-6 via Claude-CLI OAuth) — works fine.
• /model deepseek-pro (ollama/deepseek-v4-pro:cloud) — works fine.

Suggested fix direction

streamWithIdleTimeout should reset the idle timer on any chunk arrival, including thoughtSignature / thinking part frames, not just on user-visible text.
Alternatively, add a compat.thinkingFormat value for Google Gemini 3 Pro so the existing thinking-format-aware paths can mark thought frames as activity.

Related

• [Bug]: Agent timeout when calling Ollama - qwen2.5:7b works via direct API but OpenClaw agent times out #64710 — same pattern (direct API works, agent times out) reported for Ollama. Suggests a shared root cause in the idle-timeout wrapper.
• Feature request: per-model request timeout so fallback chain triggers on hangs #64854 — feature request that introduced models.providers..timeoutSeconds. Knob works but doesn't help because activity detection is the actual bug.

Steps to reproduce

1. Configure provider explicitly so the per-provider timeout escapes the 120s DEFAULT_LLM_IDLE_TIMEOUT_MS clamp:

{
models: {
providers: {
google: {
baseUrl: "https://generativelanguage.googleapis.com",
api: "google-generative-ai",
auth: "api-key",
timeoutSeconds: 600,
models: [{ id: "gemini-3.1-pro-preview", contextWindow: 1048576, maxTokens: 65536, input: ["text"], reasoning: true, cost: { input: 0, output: 0,
cacheRead: 0, cacheWrite: 0 } }]
}
}
},
agents: {
defaults: {
thinkingDefault: "high", // maps to Gemini 3 Pro HIGH (bounded thinking)
model: { primary: "ollama/deepseek-v4-pro:cloud", fallbacks: ["ollama/glm-5.1:cloud", "anthropic/claude-sonnet-4-6"], timeoutMs: 600000 }
}
}
}

2. Pin the active session to Gemini 3.1 Pro: /model gemini (or set agent:main:main.modelOverride = "gemini-3.1-pro-preview" in sessions.json).
3. From a real agent session with multi-turn history + non-trivial tool catalogue, send any user message that requires the model to reason and call tools
   (e.g. an email-triage instruction).

Expected behavior

Stream completes within seconds. The same model + a comparably-sized prompt (~17K tokens) responds in <3s via plain curl with
thinkingConfig.thinkingLevel: HIGH.

Actual behavior

• [trace:embedded-run] emits prep stages → context.compiled → prompt.submitted
• No further events for the full configured timeout
• Final model.completed with promptError: "LLM idle timeout (600s): no response from model", idleTimedOut: true
• model-fallback/decision records requested=google/gemini-3.1-pro-preview candidate=google/gemini-3.1-pro-preview reason=timeout next=none
• No outbound TCP connection to generativelanguage.googleapis.com is ever observed for this run via ss -tnp on the gateway PID
• File-log shows prompt.submitted then nothing model-related until the idleTimeoutMs fires

The duration stays exactly at the configured timeout (verified at 120s default, 600s after models.providers.google.timeoutSeconds: 600), confirming the
watchdog is doing its job — but no token ever arrives.

Direct-API control test (same key, same machine)

Plain curl with the same prompt size (≈17K tokens, including thinkingConfig.thinkingLevel: HIGH):

status=200 time=2.65s
prompt=17209 thinking=46 resp=… total=17255

Plain curl to gemini-flash-latest with the same prompt: status=200 time=1.28s, resp="OK.".

So the model is healthy from this network and key. Issue is in the agent path.

OpenClaw version

2026.4.29 (a448042)

Operating system

Linux (GCP, europe-west3)

Install method

No response

Model

gemini-3.1-pro-preview (inputTokenLimit: 1048576, supports generateContent/streaming)

Provider / routing chain

openclaw -> gemini

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response