Opus 4.8: "thinking blocks cannot be modified" (400) on long tool-heavy chats; Opus 4.7 unaffected

Summary

On Opus 4.8, long tool-heavy chats eventually fail on every new message with a 400 error about thinking blocks. The same chat works fine when switched to Opus 4.7.

Error

API Error: 400 messages.<X>.content.<Y>: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.

Once it starts, every subsequent message fails — the conversation is stuck.

Environment

• Claude Code desktop app (current as of 2026-05-29)
• Model: Opus 4.8 (1M context), thinking level "High"
• macOS

Key findings

• Model-specific: happens only on Opus 4.8. Switching the same conversation to Opus 4.7 works reliably, repeatedly.
• Trigger: large multi-step assistant turns — several tool calls with interleaved thinking, including AskUserQuestion prompts mid-turn. Inspecting the transcript, a single assistant message id spans many blocks (tool_use / thinking / tool_use…) split across turns; the thinking blocks are not in leading position after reassembly.
• Not context size: occurred at ~50% of a 1M-token window; user reports much larger/heavier sessions without issue on other models.
• The individual saved thinking blocks look structurally valid (signatures present, no encoding anomalies) — the failure is about the latest assistant turn's thinking block being re-sent in a modified position/context.

Workarounds (both confirmed)

1. Model switch: switch to Sonnet, send any reply, switch back to Opus. This forces the client to drop the carried-over (cross-model-invalid) thinking blocks and clears the error.
2. Manual transcript edit: strip thinking/redacted_thinking blocks from the session .jsonl and re-link parent UUIDs. Fixes it, but new corruption recurs on the next heavy Opus 4.8 turn.

Impact

Long Opus 4.8 sessions become unusable until worked around. Staying on Opus 4.7 avoids it entirely.