Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Summary
On us.anthropic.claude-opus-5-5, any chat containing a long multi-round agentic turn
becomes permanently unusable. Every subsequent message fails with the same Anthropic 400.
Short turns are unaffected — this only bites once a turn accumulates enough tool-call
round-trips.
The failing thinking block is always in the first assistant message, so it is
re-sent on every later request and the thread can never recover.
Error
messages.1.content.20: Invalid
signatureinthinkingblock. The block is bound to a
different conversation. Remove the block, or set
thinking.block_binding.prefix_mismatch_behaviorto “drop_block”. That setting requires
thethinking-binding-controls-2026-08-01value in theanthropic-betaheader.
This block was created as the firstthinkingblock after its prompt, but another one
now precedes it.
Surfaced in the client as [invalid_argument] Error.
Key evidence: the failing block index tracks the number of assistant segments
Two independently wedged chats:
- Composer
4dd14320— 9 consecutive assistant segments → fails atmessages.1.content.11 - Composer
47fa3d87— 15 consecutive assistant segments → fails atmessages.1.content.20
The index scales with the segment count, which indicates the entire multi-round tool-use
turn is being concatenated into a single messages[1] assistant message instead of
preserving per-round boundaries (assistant → user/tool_result → assistant → …).
Ruled out
- Not context pressure / compaction. Composer
47fa3d87used 87,271 of 1,000,000
tokens — 8.7% of the window. - Not a changed system prompt or tools list. The error’s final sentence specifically
identifies a thinking-block ordering violation, not a prefix change.
Mechanism
Inspecting the locally persisted payloads (cursorDiskKV → agentKv:blob:*), each stored
assistant segment holds one reasoning part in Vercel AI SDK shape:
{ "type": "reasoning", "text": "", "signature": "CAIS…",
"providerOptions": { "cursor": { "modelName": "us.anthropic.claude-opus-5" } } }
Note text is empty while the signature is retained — signature-only replay.
Each round-trip’s response contributed a block that, at generation time, was legitimately
“the first thinking block after its prompt.” Concatenating 9 or 15 of them into one
assistant message gives every block after the first a predecessor it never recorded, which
is precisely what the API rejects. Anthropic documents this exact pattern under
Preserved thinking:
“Drops some thinking blocks and keeps later ones, or removes them and later puts them back.”
This explains the length dependence: a short turn has at most one such block and nothing to
stack; a long turn violates the rule as soon as two replay together.
Why it is only surfacing now
Opus 5 does not run the prefix check, so the same malformed history was always accepted.
Opus 5.5 enforces it. Per Anthropic, enforcement is expanding — on by default for accounts
created on or after 2026-08-31, and “later models will enforce the prefix check for all
accounts” — so this will affect progressively more users on each model release.
Secondary observation, possibly contributing: in composer 47fa3d87 every replayed
reasoning part is stamped providerOptions.cursor.modelName = us.anthropic.claude-opus-5
while the composer’s modelConfig is us.anthropic.claude-opus-5-5, i.e. Opus 5-produced
thinking blocks replayed into an Opus 5.5 request.
Also possibly unrelated, but noting it: composer 4dd14320 uses model ID
anthropic.claude-opus-5 (regional) where every other chat uses us.anthropic.claude-opus-5
(cross-region inference profile).
Impact
The thread is unrecoverable by documented means:
- Restore Checkpoint reverts files only and “does not remove messages from the
conversation.” - Fork Chat copies the conversation through the fork point — and the bad block is in
turn 1, so every fork carries it.
Only workaround found: switch the thread to Opus 5 (which doesn’t enforce the check), or
abandon the chat.
Suggested fixes
- Preserve per-round message boundaries when replaying an agentic turn, so each
thinking block keeps its original position, instead of merging the whole turn into one
assistant message. - Immediate mitigation: send
anthropic-beta: thinking-binding-controls-2026-08-01
withthinking.block_binding.prefix_mismatch_behavior: "drop_block". Failing blocks are
then dropped and the request succeeds instead of hard-failing. Monitor
input_transformationsforreason: "prefix_binding_mismatch"to track the underlying
bug rather than masking it. - Self-heal: detect this specific 400 and retry once with thinking blocks stripped, so
a thread degrades instead of dying permanently.
Environment
- Cursor 3.21.18
- macOS 14.8.4 (23J319), arm64
- Model:
us.anthropic.claude-opus-5-5, Max Mode, 1M context
Request ID: cb12fe5a-c5ef-4228-a5a6-b38f9e729041
Steps to Reproduce
Steps to reproduce
Conditions required
- A model that enforces Anthropic’s thinking-block prefix check — reproduced on
us.anthropic.claude-opus-5-5. Does not reproduce onus.anthropic.claude-opus-5. - Agent mode, with a single user message that triggers a long multi-round agentic turn
(roughly 9+ sequential tool-call round-trips). - Does not require a large context — observed at 8.7% of a 1M window.
Steps
-
Open a new chat. Set the model to Opus 5.5 (observed with Max Mode and 1M context on).
-
Send one message that forces many sequential tool calls in a single turn. Anything
where each step depends on the previous result works; a deterministic version:Run
echo 1in the terminal. After you see the output, runecho 2. Keep going
one command at a time, waiting for each result before the next, up toecho 20.
Do not batch them.A real-world equivalent that triggered it: “clean up the repo, segment the email alerts
by place name, and update the email subject/branding to match” — a task that fans out
into many sequential file reads and edits. -
Let the turn run to completion without interrupting it.
-
Somewhere around the 9th–15th assistant segment, the turn fails with:
[invalid_argument] Error— underlying API error:
messages.1.content.<N>: Invalid signature in thinking block. The block is bound to a different conversation… This block was created as the first thinking block after its prompt, but another one now precedes it. -
Send any follow-up message in the same thread. It fails with the identical error. The
thread is now permanently unusable.
Expected: the agentic turn completes, and follow-up messages work.
Actual: the turn dies mid-flight and the thread is bricked, because the malformed
thinking blocks live in messages[1] and are replayed on every subsequent request.
Two signals that confirm the diagnosis
- The
<N>incontent.<N>scales with the number of assistant segments in the turn.
Observed: 9 segments →content.11; 15 segments →content.20. This is what points at
the whole turn being merged into a singlemessages[1]assistant message. - Switching the wedged thread to Opus 5 makes it work again, with no other change.
Opus 5 doesn’t run the prefix check, so it accepts the same history. Switching back to
Opus 5.5 re-breaks it immediately.
Note on scope: the two failures I captured were organic, long agentic turns
(9 and 15 segments). The echo 1…20 recipe above is a minimal deterministic version
derived from that pattern rather than one I have separately confirmed — the exact segment
threshold is unknown, so if it doesn’t trip at 20 rounds, a longer or more tool-heavy task
should. Turns with parallel tool calls appeared to accumulate blocks faster (one observed
segment carried 4 tool_use blocks).
Operating System
MacOS
Version Information
IDE:
Version: 3.21.18
VSCode Version: 1.128.0
Commit: c4730f7d93d787d9ab120af715999f0345ee5bc0
Date: 2026-09-22T02:04:34.641Z
Electron: 42.10.0
Chromium: 148.0.7778.280
OS: Darwin arm64 23.6.0 (macOS 14.8.4, build 23J319)
Release Track: stable
For AI issues: which model did you use?
Opus 5.5
Does this stop you from using Cursor
Yes - Cursor is unusable