Repository navigation
Auto-compact fails with Opus 4.5 extended thinking blocks #12311
Description
Bug Report: Auto-compact fails with Opus 4.5 extended thinking blocks
Description
When using Claude Code with the claude-opus-4-5-20251101 model, the automatic conversation compaction feature fails repeatedly with a 400 error. This causes the session to become unusable and all context is lost.
Environment
- Claude Code version: Latest (npm global install)
- Model: claude-opus-4-5-20251101
- OS: Windows 10/11
- Date: 2025-11-24
Error Message
400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.11.content.11: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response."},"request_id":"req_011CVTZiv4zz4a4AmyidNwVx"}
Steps to Reproduce
- Start a Claude Code session with Opus 4.5 model
- Have a long conversation that triggers auto-compaction
- When Claude Code attempts
PreCompact:auto, the API returns error 400 - The error repeats on every subsequent message
- Session becomes unusable
Debug Log Evidence
From the debug log (~/.claude/debug/*.txt):
2025-11-24T23:15:23.678Z [DEBUG] Skipping PreCompact:auto hook execution - workspace trust not accepted
2025-11-24T23:15:24.181Z [ERROR] Error streaming, falling back to non-streaming mode: 400 {"type":"error"...
2025-11-24T23:15:24.604Z [ERROR] Error in non-streaming fallback: 400 {"type":"error"...
Total failed compact attempts in session: 77
Root Cause Analysis
The Opus 4.5 model uses "extended thinking" which generates <thinking> blocks in responses. When Claude Code attempts to compact/summarize the conversation:
- It modifies or reorganizes messages containing thinking blocks
- The API rejects this because thinking blocks "cannot be modified" and "must remain as they were in the original response"
- Both streaming and non-streaming fallback fail with the same error
- The compaction never succeeds, making the session unrecoverable
Impact
- Severity: High
- Data Loss: Complete loss of conversation context
- User Experience: Session becomes completely unusable
- Workaround: Switch to Sonnet model (no extended thinking)
Expected Behavior
Claude Code should either:
- Preserve thinking blocks exactly as-is during compaction
- Handle the error gracefully and continue the session
- Warn users before using Opus 4.5 about this limitation
Suggested Fix
When compacting conversations with Opus 4.5:
- Extract and preserve
thinking/redacted_thinkingblocks unchanged - Only summarize the non-thinking content
- Or skip compaction for messages containing thinking blocks
Additional Context
The user was working on AutoCAD LISP development when this occurred. The session had grown large enough to trigger auto-compaction, at which point it entered an error loop and became unusable.
Reported via Claude Code session analysis
Activity
github-actions commentedon Nov 25, 2025
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
art-shen commentedon Nov 25, 2025
Breaks everything and neither manual nor automatic compaction works.
TheDropZone commentedon Nov 25, 2025
Definitely experiencing this as well with opus 4.5 and auto or manual compacts
kyleorin commentedon Nov 26, 2025
same here on macos
Noir-Lime commentedon Nov 26, 2025
Workaround is to
/modelset to Sonnet, then/compact, then set model back to opus.pentafive commentedon Dec 8, 2025
Confirming on WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2) with Claude Code 2.0.61 and Opus 4.5.
My variant shows a slightly different error - the API complained about missing thinking block at message start rather than modification:
Request ID: req_011CVtsi7huAUbEEm1GsSccY
Triggered when context hit 4% remaining and /context command was run.
1 remaining item
thinkingorredacted_thinkingblocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response." #13012 as a duplicate of this issuedicksontsai commentedon Dec 12, 2025
We've addressed this issue in 2.0.67. However, sessions created prior to 2.0.67 may still encounter this issue when resuming. We are working on a fix for the resume case.
Nostromos commentedon Dec 16, 2025
@dicksontsai Reaching out to confirm that this issue remains post 2.0.67 (i'm on 2.0.71)
nerdeveloper commentedon Dec 17, 2025
I am also experiencing this issue, using the latest version 2.0.70
pentafive commentedon Dec 17, 2025
Are they old sessions or new? I haven't been able to replicate it on 2.0.71 when it's a fresh session.
dicksontsai commentedon Dec 17, 2025
If you are still encountering this issue, please file
/feedback(the GitHub issue should have a feedback ID) when you encounter the session. This will help us out greatly, and it's how we've managed to reduce this particular "thinking blocks cannot be modified" error by 90+%. That said, I do still see a long tail of occurrences.Don't worry about de-duping issues. We'll handle that for you.
@Nostromos @nerdeveloper
github-actions commentedon Dec 24, 2025
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.