openclaw - 💡(How to fix) Fix [Bug]: Cron job fails with FallbackSummaryError: All models failed — LLM request times out [1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Version

2026.4.5 (also failed on 2026.4.2)

Problem

Daily cron job that sends a simple agent turn message fails every time with:

FallbackSummaryError: All models failed (2): minimax-portal/MiniMax-M2.7: LLM request timed out. (timeout) | minimax-portal/MiniMax-M2.7-highspeed: LLM request timed out. (timeout)

Setup

• MacBook Air (macOS)
• Gateway running as LaunchAgent
• Cron configured with sessionTarget: "current" and wakeMode: "now"
• Model: minimax-portal/MiniMax-M2.7

Cron job config

{
  "name": "Daily 7AM Positive Message",
  "enabled": true,
  "schedule": {
    "kind": "cron",
    "expr": "0 7 * * *",
    "tz": "America/Los_Angeles"
  },
  "sessionTarget": "current",
  "payload": {
    "kind": "agentTurn",
    "message": "Good morning! 🌟 [affirmation text]"
  },
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "to": "<user_id>"
  },
  "wakeMode": "now"
}

Steps to reproduce

1. Set up a cron job with sessionTarget: "current" and payload.kind: "agentTurn"
2. Configure it to fire at a specific time (e.g., 0 7 * * *)
3. Set delivery.mode: "announce" with a Telegram target
4. Add a simple text message to the payload
5. Wait for the scheduled time
6. Observe the job fires but fails with timeout error

Expected behavior

Message should be sent via Telegram at 7 AM Pacific daily.

Actual behavior

Job fires at 7 AM but fails with timeout error. Manual sends work fine.

OpenClaw version

2026.4.5 (also failed on 2026.4.2)

Operating system

macOS BigSur 11.7.11

Install method

npm install -g openclaw

Model

MiniMax-M2.7

Provider / routing chain

Gateway (local, 127.0.0.1:XXXXX) → minimax-portal/MiniMax-M2.7 → MiniMax API → timeout

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Relevant logs:

LLM request timed out. (timeout) | minimax-portal/MiniMax-M2.7-highspeed: LLM request timed out. (timeout)

Full error:

Cron job "Daily 7AM Positive Message" failed: FallbackSummaryError: All models failed (2): minimax-portal/MiniMax-M2.7: LLM request timed out. (timeout) | minimax-portal/MiniMax-M2.7-highspeed: LLM request timed out. (timeout)

Gateway status at time of failure:

Gateway: bind=loopback (127.0.0.1), port=XXXXX
RPC probe: ok
Service: running (pid <gateway_pid>)
Listening: 127.0.0.1:XXXXX

Cron job state (job fires but times out):

{
  "name": "Daily 7AM Positive Message",
  "enabled": true,
  "schedule": { "kind": "cron", "expr": "0 7 * * *", "tz": "America/Los_Angeles" },
  "sessionTarget": "current",
  "payload": { "kind": "agentTurn", "message": "Good morning! 🌟 [affirmation]" },
  "delivery": { "mode": "announce", "channel": "telegram", "to": "XXXXX" },
  "wakeMode": "now"
}

Impact and severity

Affected users/systems/channels: Single user (me) on one macOS system. Telegram channel affected.

Severity: Annoying — does not block core functionality. Gateway and manual sends work fine.

Frequency: Always. Every scheduled cron firing fails with timeout. No successful automated sends observed.

Consequence:

• Missed scheduled messages (daily affirmation at 7 AM) • Manual workaround required (I send manually when I notice) • No data loss or security impact • Extra monitoring burden

NOT_ENOUGH_INFO:

• Whether other OpenClaw users experience this with their cron jobs • Whether other models (non-MiniMax) have same issue • Whether this is specific to agentTurn payload type or affects all cron job types

Additional information

Additional context:

• First observed: Approximately 2-3 days ago when cron was first set up • Last known good: Unknown — cron may never have worked reliably with this config • First known bad: 2026.4.2 (cron job created, immediately started failing) • Still fails on: 2026.4.5 after update

Key observation: Manual sessions work fine. Only cron-triggered agentTurn sessions fail. Gateway RPC remains healthy. This suggests the issue is specific to how cron triggers and initializes sessions, not the model or gateway itself.

Workaround in use: Manual sends when cron fails. Message gets delivered, just not automatically.

NOT_ENOUGH_INFO:

• Whether this affects other payload types (e.g., agentRequest, script) • Whether other model providers are affected • Whether this is reproducible on Linux/Windows or macOS-specific