Claude Invalid Signature in Thinking Block: What to Check

When Claude reports an invalid signature in a thinking block, inspect the structured conversation you sent back. Preserve the original thinking block and its signature rather than reconstructing it from displayed text. If the error explicitly mentions a different conversation, also inspect changes to the preceding system prompt, tools and messages.

These are different failure modes. A signature string can be present and unchanged while a conversation-bound block is no longer valid for an edited prefix. This guide follows the current thinking troubleshooting documentation, checked September 14, 2026. It is a protocol diagnostic, not a claim that all models enforce identical binding rules.

Read the error before changing the history

Keep the full error type and message, request ID, model identifier and client version. Determine whether the first request failed or whether the failure began only after a tool call, a session restore or a history edit. That boundary helps locate the code path that lost or changed state.

Do not paste private conversation histories or opaque signatures into a public issue. A redacted description of block types and the transformation is usually a better starting point. Retain an unmodified local diagnostic copy if needed to compare your own request paths.

Preserve the complete assistant content

A native thinking block contains a thinking value and an opaque signature. A redacted_thinking block uses data and must not be treated as ordinary visible prose. Empty visible thinking text alone does not establish that the block is corrupt.

The official thinking tool-workflow guide explains how these blocks participate in continued tool turns. Preserve their original values and order together with the rest of the assistant response. Do not summarize a thinking block, replace the signature, or rebuild the message from the UI’s text-only transcript.

The following Python fragment illustrates preservation after a response has already been obtained. It is not a complete request or a live API test. Adapt the serialization step to your installed SDK, keeping the full returned content instead of just text fields.

assistant_content = [block.model_dump(exclude_none=True) for block in response.content]
messages.append({"role": "assistant", "content": assistant_content})
# Append the real tool_result message next, following the native tool protocol.

Do not insert a made-up signature into sample requests. A string that looks plausible is not evidence of a valid provider-issued block. If the original content is lost, diagnose why it was lost instead of attempting to manufacture the missing state.

Streaming requires more than text deltas

A streaming integration must assemble the supported content-block events. The Messages API reference documents signature_delta, which arrives before the corresponding content_block_stop. A collector that saves only text_delta or visible thinking text will not preserve the same structured response as a full SDK response object.

Check whether an early disconnect, cancellation or UI redraw caused the client to mark a partially assembled block as complete. Keep the block index and event order when debugging. Do not forward an unfinished block merely because the screen contains a readable partial answer.

Using the official SDK’s supported stream handling can reduce custom assembly work, but it does not protect history that your own application subsequently flattens or filters. Compare the in-memory response with the next serialized request. The transformation between those two objects is often the most useful place to inspect.

Conversation binding is a separate check

The current documentation describes conversation-bound signatures for Claude Fable 5.1, enforced for accounts created on or after August 31, 2026, and requests that set the documented binding control. This is a model-specific rule. For an error that specifically identifies a different conversation, changes before the thinking block can matter even when the block itself is untouched. Examples include changing the system instructions, changing tools, or rewriting earlier messages.

Use append-only history when following that workflow, or the documented server-side compaction and context-editing mechanisms. Do not apply a blanket local history rewrite and assume that preserved signatures will make it valid. Model-specific recovery controls also exist in the official documentation, but they are not generic settings to paste into every Claude request.

This article deliberately does not recommend enabling a special recovery beta as the first step. First verify that the selected model and exact error match its documented scope. A recovery option that drops a block can alter retained state, so it should be evaluated as a deliberate application choice.

Do not assume every cross-model change is invalid

The current troubleshooting page explains that blocks unreadable by another model may be dropped rather than necessarily causing the conversation-binding error. Therefore, “switching models always breaks thinking signatures” is too broad. The same caution applies to claims that all cross-provider routes are inherently incompatible.

Record the source model, target route and exact error, then consult the relevant compatibility documentation. If your client converts between native Claude messages and another API format, verify that it preserves the required metadata instead of guessing a universal field mapping.

Tool-result pairing is another independent validation layer. If the message names an unmatched tool ID, follow the missing tool_result guide rather than changing signatures. Gemini has its own thought-signature fields; they are not interchangeable with Claude’s native signature field.

Frequently asked questions

Can I fix the signature by editing its value?

No. Treat it as opaque provider-issued state. Restore the original complete block if available, and investigate any transformation that changed or discarded it.

Why does the second request fail when the first worked?

The continuation may have lost structured thinking data or altered a conversation-bound prefix. Compare the full first response with the actual follow-up request instead of only the visible transcript.

Does a new session prove the bug is fixed?

No. A new session can isolate damaged history, but an adapter that strips required fields may break again on the next tool round. Verify the preservation path before closing the issue.