Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When the primary provider returns an upstream_error, OpenClaw ends the turn with LLM request failed instead of trying the configured fallback models.

Steps to reproduce

1. Configure OpenClaw 2026.6.8 with a primary model under agents.defaults.model.primary and fallback models under agents.defaults.model.fallbacks.
2. Run it through the gateway / embedded agent runtime.
3. Have the primary provider return an error payload with type: "upstream_error" and message Upstream request failed.
4. Observe that the turn ends with LLM request failed, only the primary provider/model appears in the trajectory, and no fallback candidate is attempted.

Expected behavior

If fallback models are configured, provider-side transient errors such as upstream_error / LLM request failed should be treated as fallbackable failures.

OpenClaw should continue to the next configured fallback model before ending the turn as failed. The trajectory should record a fallback step for the failed primary candidate. If all candidates fail, the final error should summarize all attempted models. Non-transient or intentional errors should keep their current behavior.

Actual behavior

The primary provider returned an error shaped like:

{
  "error": {
    "message": "Upstream request failed",
    "type": "upstream_error",
    "param": "",
    "code": null
  }
}

OpenClaw recorded the run as failed with stopReason: "error", terminalError: "non_deliverable_terminal_turn", and the user-facing error LLM request failed.

The turn ended immediately on the primary model. The trajectory/logs show only the primary provider/model, no model.fallback_step events, and no fallback provider/model.

OpenClaw version

2026.6.8 (Git SHA from trajectory metadata: 685aa7f)

Operating system

Gateway / embedded agent runtime; OS not shown in the provided trajectory metadata

Install method

gateway / embedded agent

Model

Primary model configured under agents.defaults.model.primary; fallbacks configured under agents.defaults.model.fallbacks

Provider / routing chain

OpenClaw gateway / embedded agent -> primary configured provider/model; fallback providers/models from agents.defaults.model.fallbacks

Additional provider/model setup details

Fallbacks are configured under agents.defaults.model.fallbacks.

Example redacted config shape:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "provider-a/model-a",
        "fallbacks": [
          "provider-b/model-b",
          "provider-c/model-c",
          "provider-d/model-d"
        ]
      }
    }
  }
}

No API keys, tokens, or provider credentials are included here.

Logs, screenshots, and evidence

Observed evidence from the trajectory/logs:

- Primary provider error payload had `error.type: "upstream_error"` and message `Upstream request failed`.
- Run ended with `stopReason: "error"`.
- Run ended with `terminalError: "non_deliverable_terminal_turn"`.
- User-facing error was `LLM request failed`.
- Only the primary provider/model appears in the trajectory/logs.
- No `model.fallback_step` events appear.
- No fallback provider/model appears.

This was observed with OpenClaw version `2026.6.8` and Git SHA `685aa7f` from trajectory metadata.

Impact and severity

Affected users/systems/channels: gateway / embedded agent users who configure fallback models under agents.defaults.model.fallbacks.

Severity: High for this failure mode because a configured fallback chain is skipped and the user receives a failed turn.

Frequency: Observed for the provider-side upstream_error / user-facing LLM request failed case described above.

Consequence: Transient upstream provider failures still end the turn immediately even when healthy fallback models are configured.

Additional information

Likely area: the embedded run result fallback classification appears to handle empty visible assistant replies, reasoning-only output, planning-only output, and incomplete/format-like terminal responses, but provider-side error payloads such as upstream_error appear to be returned as final error results instead of being classified as fallbackable.

Suggested acceptance criteria:

• With agents.defaults.model.fallbacks configured, a primary model response containing type: "upstream_error" triggers the next fallback candidate.
• The trajectory records a fallback step for the failed primary candidate.
• If all candidates fail, the final error summarizes all attempted models.
• Non-transient or intentional errors keep their current behavior.

Related but distinct issues shown by GitHub's duplicate detector:

• [Bug]: Fallbacks does not work. Connection errors (ECONNREFUSED, network offline) should trigger model fallback to cloud providers #65810 covers connection/network failures such as ECONNREFUSED and server offline.
• [Bug]: Global model fallbacks not inherited by session runner (fallbackConfigured: false) #71111 covers a case where global fallbacks were not inherited and fallbackConfigured was false.

This report is specifically about OpenClaw 2026.6.8 with fallbacks configured, where a provider-side upstream_error / LLM request failed is surfaced as a final error instead of triggering the configured fallback chain.