openclaw - 💡(How to fix) Fix Feature Request: Detect and handle empty responses after think-block stripping [1 participants]

Error Message

When a model (e.g. Gemini) returns a response consisting entirely of unclosed <think> blocks or other stripped internal reasoning content, the final user-visible message is empty after OpenClaw's think-block stripping. Currently, the gateway treats this as a successful completion — no timeout, no error, tokens were generated, HTTP 200 from the provider. 4. No error is raised, no fallback is triggered — the message simply disappears

Option B: Send a visible warning/error to the user (e.g. "Model returned an empty response after processing. Please try again or switch models.") Ideally this would be configurable (retry vs. warn vs. both).

If all retries exhausted: deliver an error message to the user instead of silence

Problem

The user sees no response at all, with no indication that something went wrong.

How to Reproduce

Configure a model that occasionally produces only <think> content without a visible reply (observed with Gemini models)
Send a message that triggers this behavior
The gateway processes the response, strips the <think> block, and delivers an empty string
No error is raised, no fallback is triggered — the message simply disappears

Expected Behavior

The gateway should detect when a completion result is empty (or whitespace-only) after post-processing (think-block stripping, tag removal, etc.) and take corrective action:

Option A: Automatically retry with the next model in the fallback chain (e.g. Opus → Sonnet → GPT-4.1 → Gemini)
Option B: Send a visible warning/error to the user (e.g. "Model returned an empty response after processing. Please try again or switch models.")
Option C: Both — retry once, and if the retry also fails, notify the user

Ideally this would be configurable (retry vs. warn vs. both).

Cost and Safety Risk

In a manual conversation, this is merely annoying — the user notices the missing reply and resends. However, in automated scenarios this becomes a real financial risk:

Heartbeat/Cron jobs that receive an empty response could trigger retry loops
Models with large context windows (e.g. Gemini with 1M tokens) make each failed attempt expensive
Overnight/unattended operation means this can burn through significant budget before anyone notices
A single empty-reply loop on a large-context model could easily generate hundreds of dollars in wasted API costs

Suggested Implementation

Detection should happen at the gateway level, after all post-processing (think-block stripping, tag cleanup) but before delivery to the channel:

Check if the final message content is empty or whitespace-only
If empty: increment a retry counter, attempt fallback model (if configured)
If all retries exhausted: deliver an error message to the user instead of silence
Log the event for observability (model, token count, reason for empty result)

Environment

OpenClaw v2026.3.31 (originally observed), likely still present in v2026.4.1
Observed with Gemini models producing only <think> blocks
Gateway with fallback chain configured

extent analysis

TL;DR

Implement a check at the gateway level to detect empty responses after post-processing and trigger a retry or error message to prevent silent failures.

Guidance

Check the final message content for emptiness or whitespace-only after think-block stripping and tag removal to identify potential issues.
Consider implementing a retry mechanism with a fallback model chain to handle empty responses, such as retrying with the next model in the chain (e.g., Opus → Sonnet → GPT-4.1 → Gemini).
Log events for observability to track instances of empty results, including the model, token count, and reason for the empty result.
Evaluate the cost and safety risk of empty responses in automated scenarios, such as heartbeat/cron jobs, to determine the best course of action.

Example

def process_response(response):
    # Strip think-blocks and remove tags
    processed_response = strip_think_blocks(response)
    processed_response = remove_tags(processed_response)
    
    # Check if the final message content is empty or whitespace-only
    if not processed_response.strip():
        # Increment retry counter and attempt fallback model
        retry_counter += 1
        if retry_counter < max_retries:
            return attempt_fallback_model()
        else:
            # Deliver an error message to the user
            return "Model returned an empty response after processing. Please try again or switch models."
    else:
        return processed_response

Notes

The suggested implementation should be configurable to allow for different retry and error handling strategies, such as retrying with the next model in the chain or sending a visible warning/error to the user.

Recommendation

Apply a workaround by implementing a check for empty responses at the gateway level and triggering a retry or error message as needed, due to the potential financial risk and user experience impact of silent failures.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

openclaw - 💡(How to fix) Fix Feature Request: Detect and handle empty responses after think-block stripping [1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Problem

How to Reproduce

Expected Behavior

Cost and Safety Risk

Suggested Implementation

Environment

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

TRENDING

openclaw - 💡(How to fix) Fix Feature Request: Detect and handle empty responses after think-block stripping [1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Problem

How to Reproduce

Expected Behavior

Cost and Safety Risk

Suggested Implementation

Environment

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

RELATED_DISCOVERY

TRENDING