Environment

• OpenClaw 2026.4.15 (041266a)
• Runtime: bare-metal on Linux, gateway + scheduled cron jobs

Symptom

Scheduled cron jobs configured with model google/gemini-2.5-flash (alias flash) for tool-calling workloads began failing at a 20–50% per-job rate starting approximately 2026-04-15.

User-facing error surfaced to the delivery channel:

⚠️ Agent couldn't generate a response. Please try again.

Gateway log signature

[agent/embedded] embedded run agent end: isError=true
  model=gemini-2.5-flash provider=google
  error=LLM request failed: provider rejected the request schema or tool payload.
  rawError=400 status code (no body)
[agent/embedded] incomplete turn detected: ... stopReason=undefined
  payloads=0 — surfacing error to user

Scope

9 distinct cron jobs affected across multiple agents. The busiest (running every 15 min during weekday business hours) reached 37 consecutive errors before manual remediation. All failures have identical signature — the provider returns HTTP 400 with no response body on tool-heavy payloads, pure-text cron payloads on Flash are unaffected.

Native failover does not apply

Per PR #68238 in 2026.4.15, Google 400s are explicitly excluded from the retryable-error set ("only treat INTERNAL status payloads as retryable timeouts when they also carry a 500 code"). This means agents.defaults.model.fallbacks does not fire for this failure class — the cron dies rather than failing over.

Reproduction

Any cron job with payload.model = google/gemini-2.5-flash that uses multiple tool schemas in a single turn. The failure rate scales with payload complexity, not request volume.

Remediation applied locally

Switched affected cron jobs to openai/gpt-4.1-mini via openclaw cron edit <id> --model openai/gpt-4.1-mini. All runs since the change have succeeded.

Questions to maintainers

1. Is this a known Google API-side tool-schema-validator tightening, or is OpenClaw's tool payload serialization the variable? The symptom cut-in coincides with the 2026.4.15 release window but also with broader Google API updates.
2. Would you accept a docs PR adding "avoid Gemini Flash for tool-heavy cron workloads" guidance to docs/cli/cron.md and/or docs/concepts/models.md?
3. cron.failureDestination is documented but was not visible from the incident-investigation path. Would you consider a release-note-level callout that native per-job status=error rows have a native notification mechanism, since the default behavior is "the error text gets delivered as the cron output" which silently masks failures?

Additional context

The failure was invisible for 6 business days in our deployment because the error text itself was delivered as the cron's output (deliveryStatus=delivered), so our health-check tooling (which only watches undelivered runs) did not flag it. Setting cron.failureDestination addressed the visibility half — suggest this become a recommended default for any production OpenClaw deployment.