openclaw - 💡(How to fix) Fix Claude Opus can produce false-success empty terminal turns (stop=stop, content=[], usage=0) leading to 'Agent couldn't generate a response' [2 comments, 2 participants]

Summary

On OpenClaw 2026.4.23, Claude Opus 4.6 / 4.7 can intermittently fail with:

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

In the failing cases, the assistant turn is sometimes recorded as a false-success empty terminal turn instead of an error:

• stopReason = "stop"
• content = []
• usage.input = 0
• usage.output = 0
• usage.totalTokens = 0

This makes the run look like a normal completion even though no model output was produced.

Environment

• OpenClaw: 2026.4.23 (a979721)
• Runtime: embedded Pi runner
• Provider path: myclaw with anthropic-messages
• Affected models observed: claude-opus-4.6, claude-opus-4.7
• Comparison model: gpt-5.4 on openai-responses succeeded during the same period

Observed behavior

Between roughly 2026-04-26 07:50 and 09:15 Asia/Shanghai, Claude Opus 4.6 / 4.7 repeatedly failed in both Telegram and the web UI with the same user-facing error.

Important details:

1. The problem was not channel-specific. It reproduced in both Telegram and the web UI.
2. It was not limited to one corrupted old session. /new did not reliably recover it.
3. In at least some failing runs, the session transcript recorded an assistant turn with:
   • stopReason: "stop"
   • empty content
   • zero token usage
4. GPT-5.4 worked normally after switching away from Claude.

Concrete evidence

Example failing assistant turns from local session transcript (2026-04-26T00:04:50Z, 00:06:33Z, 00:07:42Z):

{
  "model": "claude-opus-4.6",
  "stop": "stop",
  "usage": {
    "input": 0,
    "output": 0,
    "cacheRead": 0,
    "cacheWrite": 0,
    "totalTokens": 0
  },
  "blocks": [],
  "textLen": 0,
  "raw": []
}

At the UI level this surfaced as:

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

Why this seems like an OpenClaw bug

The key issue is not just that a provider path may have failed.

The more serious problem is that OpenClaw appears to accept a zero-token, empty-content assistant turn with stopReason="stop" as a successful terminal result.

That should probably not be treated as a valid success state.

Even if the upstream provider / proxy path is flaky, a terminal turn with all of the following:

• no visible content
• no tool call
• no usage
• stopReason = "stop"

should likely be upgraded to an internal error, retry, or fallback condition instead of being treated as a normal completion.

Additional context

There was also compaction activity around some of the early failures in the old session, so compaction may have amplified the user-visible failure pattern. However, this does not fully explain the issue, because the problem also reappeared after /new.

So the most likely interpretation is:

• there may be instability in the Claude / Anthropic path,
• and OpenClaw does not robustly handle the resulting empty terminal turn.

Suggested fix

Treat this state as invalid / retryable for all providers, not only specific strict-agentic lanes:

• stopReason === "stop"
• assistant content empty
• no tool calls
• total token usage is zero

Possible handling:

1. convert to error, or
2. trigger one automatic retry, or
3. trigger fallback

Instead of surfacing it directly as a normal completed assistant turn.

Repro notes

This was observed multiple times with Claude Opus 4.6 / 4.7 during the same time window, while GPT-5.4 remained functional.

I can provide more local transcript / trajectory details if needed.