Description

When a heartbeat session's configured model fails to initialize (cloud provider timeout, rate limit, transient error), the gateway logs:

[assistant turn failed before producing content]

This phrasing implies the assistant's code failed, but in these cases no assistant code has run. The model layer failed before the turn began. The result is:

1. Misleading diagnostics — logs suggest a code bug when it's actually provider-side
2. Silent failures for autonomous functions — heartbeats produce no output, no state update, and no retry path
3. No differentiation — gateway cannot distinguish "provider down" from "assistant crashed"

Steps to reproduce

1. Configure heartbeat with a cloud model (e.g., kimi-k2.6:cloud via Ollama proxy)
2. Trigger heartbeat during provider instability
3. Observe [assistant turn failed before producing content] in logs
4. Note: zero assistant code executed, zero state change, next heartbeat retries blindly

Routing context

The failure path is: heartbeat → Ollama localhost proxy → cloud provider. The provider hiccups, Ollama returns an error, and the gateway sees that as "assistant turn failed." This could be an OC issue, or an Ollama issue — the logging makes it hard to tell.

Expected behavior

Suggested fix

In gateway heartbeat handling, distinguish between:

• model.init() failure → provider error
• assistant.run() failure → code error
• Empty output → valid but suspicious

For heartbeat specifically: if model init fails and a fallback model is configured (e.g., local Ollama), retry once with fallback before giving up.

Environment

• OpenClaw v2026.4.1+ (observed on v2026.5.7)
• macOS, Apple Silicon, Ollama + cloud hybrid setup
• Heartbeat is autonomous infrastructure — silent failures mean memory hygiene, process health, and spend checks simply don't run

Impact

Medium — not a crash, but degrades reliability of autonomous functions and makes provider issues harder to diagnose.