openclaw - 💡(How to fix) Fix [Bug]: Model fallback logs reason=unknown for OpenAI-compatible providers, silently escalates to primary model [1 comments, 1 participants]

When using OpenAI-compatible providers, sub-agent model requests that fail are logged with reason=unknown in fallback decisions. The actual upstream error is never surfaced, making debugging impossible. Gateway error log shows:

• The reason=unknown indicates the error classifier cannot parse the upstream error format
• The actual error (likely a non-standard HTTP error response from the proxy) is swallowed entirely

1. The upstream error response body/status should be logged (at least at debug level) so users can diagnose proxy issues Related but distinct from #59213 (which covers infinite 429 loops from session model reconciliation). This issue is about the error classification gap and upward-escalation fallback direction for OpenAI-compatible provider errors.

TL;DR

Modify the error logging and classification to include the raw HTTP status code and response body for upstream errors, and adjust the fallback chain to prefer models of similar tier.

Guidance

• Review the error classifier to handle non-standard HTTP error responses from the proxy and log the raw HTTP status code and response body at least at debug level.
• Update the fallback logic to prefer models of similar tier (e.g., Haiku→Sonnet→Opus) instead of escalating directly to the most expensive model.
• Verify that the modified logging and fallback behavior work as expected by reproducing the error scenario and checking the logs and fallback chain.
• Consider adding additional logging or monitoring to detect and diagnose proxy issues that may be causing the upstream errors.

Example

# Pseudo-code example of modified error logging
def log_error(upstream_response):
    error_message = f"Upstream error: {upstream_response.status_code} {upstream_response.text}"
    logger.debug(error_message)
    # Log the error with the raw HTTP status code and response body

Notes

The exact implementation details may vary depending on the specific programming language and framework used. The example provided is a pseudo-code illustration of the modified error logging.

Recommendation

Apply workaround: Modify the error logging and classification to include the raw HTTP status code and response body, and adjust the fallback chain to prefer models of similar tier. This will allow for better debugging and diagnosis of proxy issues and prevent unnecessary escalation to expensive models.