[Bug] Opus 4.8 (1M) returns empty stop_sequence responses causing tool call parsing failures
Bug Description
Title: Opus 4.8 (1M) intermittently returns empty stop_sequence responses
→ "tool call could not be parsed (retry also failed)" / tool calls return no result
Environment:
- Model: claude-opus-4-8[1m], effort xhigh
- Claude Code v2.1.177, WSL2 (Ubuntu), Windows host
Symptom:
After a SUCCESSFUL tool result, the next assistant turn frequently either
(a) fails with "The model's tool call could not be parsed (retry also failed)",
sometimes churning ~10 minutes, OR
(b) emits tool calls that return NO result at all (silently swallowed).
Evidence (from session .jsonl transcript analysis):
- stop_reason distribution this session: tool_use ×15, stop_sequence ×2
— ZERO max_tokens → NOT output truncation.
- Max output_tokens across the entire session = 6032
— an order of magnitude below the cap → payload size is NOT the cause.
- Every parse failure coincides exactly with an assistant message whose
stop_reason=stop_sequence AND output_tokens=[REDACTED] (empty shell response).
Observed the same tool_use (4353 tokens) emitted 3x identically without
ever parsing — the literal meaning of "retry also failed".
Ruled out: payload size, Chinese-character ratio, context length, effort level.
Workaround: switching to claude-opus-4-7[1m] (same account/config) eliminates
it completely.
Regression window: first observed 2026-06-02, STILL reproduces 2026-06-15 on
v2.1.177.
Environment Info
- Platform: linux
- Terminal: wsl-Ubuntu
- Version: 2.1.177
- Feedback ID: 4a28b0d8-6306-49c2-b077-075498b8f535
Errors
[]