Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When OpenClaw is configured with google/gemini-2.5-flash as the primary model and thinkingDefault: medium (the default thinking level for Gemini reported by the gateway boot log), agent turns hang for ~125 seconds before timing out and falling back to the fallback model. Google Cloud Console shows the corresponding streamGenerateContent API requests completing successfully with average latency well within the timeout, suggesting OpenClaw's stream handler is failing to correctly consume responses when an extended thinking budget produces a long pre-token thinking phase.

Steps to reproduce

1. Set agents.defaults.model.primary to google/gemini-2.5-flash.
2. Leave thinkingDefault unset (default resolves to medium per the gateway log) or explicitly set to medium / low / high.
3. Configure a Telegram channel and start a normal conversation with the bot.
4. Within a handful of moderately complex turns, OpenClaw will hang for ~125 seconds, time out, and fall over to the configured fallback (or fail outright if no fallback is configured).

Expected behavior

OpenClaw consumes the streaming response from Gemini 2.5 Flash and returns the answer within a reasonable time (Google reports p99 of ~49s for streamGenerateContent even under thinking-heavy loads, well within OpenClaw's apparent 125s timeout).

Actual behavior

OpenClaw consistently times out at approximately 125 seconds and emits a FailoverError: LLM request timed out even though, on Google's side, the same request period shows zero errors.

Multiple captured timeout durations (durationMs) from the same install:

125567
125592
126284
129212
133544

Sample log block from ~/.openclaw/logs/gateway.err.log (sanitized):

[agent/embedded] Profile google:default timed out. Trying next account...
[agent/embedded] embedded run failover decision: stage=assistant decision=fallback_model reason=timeout from=google/gemini-2.5-flash
[diagnostic] lane task error: lane=main durationMs=125567 error="FailoverError: LLM request timed out."
[model-fallback/decision] model fallback decision: decision=candidate_failed requested=google/gemini-2.5-flash candidate=google/gemini-2.5-flash reason=timeout next=anthropic/claude-sonnet-4-6 detail=LLM request timed out.

Google Cloud Console evidence (same time window)

Pulled from "Generative Language API" details page, filtered to the credential issuing the OpenClaw traffic:

Key observations:

• Zero errors on streamGenerateContent during the OpenClaw timeout window.
• No 429s anywhere — this isn't a rate-limit problem.
• p99 latency 49.3s — well inside OpenClaw's 125s timeout. Google is clearly delivering responses; OpenClaw is hanging client-side.

OpenClaw version

2026.5.7 (eeef486)

Operating system

macOS 26.5

Install method

npm global

Model

google/gemini-2.5-flash

Provider / routing chain

openclaw -> google-ai-studio (generativelanguage.googleapis.com/v1beta)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: Telegram channel users on this OpenClaw 2026.5.7 install Severity: High (blocks turn completion; ~2-minute silent hang before failure surfaces, so users wait the full timeout before knowing the bot won't respond) Frequency: Intermittent but reliable; 5+ distinct ~125s timeouts captured in gateway.err.log during normal multi-day usage (durationMs values 125567/125592/126284/129212/133544); reproduces within a handful of moderately complex queries when thinkingDefault resolves to medium; eliminated entirely with thinkingDefault: minimal or off Consequence: User-visible turn failures, forced fallback to higher-cost Anthropic model when fallback works, total failure when fallback is also unavailable; wasted thinking-budget tokens on requests that never produce user output

Additional information

Confirmed workaround

Reducing the thinking level eliminates the hang entirely:

• /think:off (per-session directive) — no hangs across multiple conversations.
• thinkingDefault: "minimal" (global default) — no hangs across an extended testing period.
• thinkingDefault: "medium" — reliably reproduces the hang within a few queries.

So the bug appears to require a non-minimal thinking budget on gemini-2.5-flash to manifest.

Hypothesis

The behavior matches the symptoms described in:

• #8724 — Gemini Flash stuck in thinking/planning loops without producing output
• #46049 — LLM request timeout settings not respected
• #52231 — zombie handle blocking heartbeat after embedded run timeout

Most likely cause: when Gemini 2.5 Flash is given a thinking_config with a non-minimal budget, it can spend tens of seconds emitting reasoning deltas before any user-facing tokens. OpenClaw's stream consumer may be misinterpreting the long pre-token phase as a stalled connection, or not correctly handling the thinking-delta wire format, leading to the 125s timeout despite Google having delivered a complete successful response.

Suggested next steps

• Add per-model generation timeout config (already requested in #8724) so slow-thinking models can extend their effective timeout.
• Investigate stream-handling behavior specifically for Gemini responses with non-minimal thinking_config budgets.
• Document safe thinkingDefault values per model family in the Google provider docs.
• Consider defaulting gemini-2.5-flash to thinkingDefault: minimal until the underlying stream handling is fixed, since medium is currently a footgun.

Additional context

Direct curl to the same model and key, outside OpenClaw, returns gemini-2.5-flash:generateContent responses in under 1 second. The API key and account are healthy; the issue is reproducible only through OpenClaw's embedded runtime when thinking is engaged.