Claude “Invalid Signature” in a Thinking Block: How to Debug It Safely

Cover: a conceptual illustration of preserving conversation history; it does not represent a signature-validation result.

If a Claude Messages request fails with the error “Invalid signature in thinking block,” start with the conversation history your client actually sent. Preserve each returned thinking or redacted-thinking block unchanged, then check whether an earlier message, tool result, tool definition, or model changed before that block. Do not edit the signature or strip every thinking block as a blanket fix. Anthropic documents both prefix-related failures and a separate tampered-or-undecryptable-signature failure; which behavior applies depends on the API and model. Tokenhot’s public Claude route pages show a Messages endpoint, but do not document this signature behavior, so the checks below are conditional guidance for a native Anthropic Messages payload—not a claim that a Tokenhot route produced or enforces the same error.

What the signature tells you—and what it does not

A thinking block can include a signature alongside its thinking content. Anthropic’s current preserved-thinking documentation says the signature is checked for model readability and, on the specifically named Claude Fable 5.1 and Opus 5.5 models, for whether the conversation prefix before that block stayed unchanged. That prefix includes the top-level system value, the tools list, and earlier messages. A different model may silently drop a block it cannot read; an edited prefix can be rejected or, under a documented opt-in behavior, cause blocks to be dropped. A tampered or undecryptable signature is a separate error. Anthropic’s preserved-thinking guide describes these cases and limits them to named API behavior and model conditions.

Treat the signature as opaque protocol data. It is not a field to calculate, decode, trim, regenerate, or substitute. If you choose to send earlier thinking back, preserve the complete assistant content array exactly as returned. That includes empty-looking or redacted blocks; Anthropic’s tool-and-thinking walkthrough specifically warns against rebuilding the assistant message or filtering out redacted-thinking blocks. Its round-trip example shows that the thinking text can be empty while a signature remains, and still says to echo the content unchanged.

Compare the actual requests before changing anything

Save the raw request body and response from a successful turn, then compare them with the failing continuation. Redact keys and private content before sharing logs. Focus on the history before the first affected thinking block:

1. Was an earlier message edited, reordered, or removed? A client that rebuilds the whole transcript from summaries may change a prior user or assistant message, even when the latest user turn looks unchanged.
2. Did the system prompt or tools array change? A date string, mode flag, plugin/MCP tool addition, renamed tool, or different schema can change the prefix for models that enforce the documented check.
3. Was an earlier tool result shortened or rewritten? A summary that changes old tool output or a tool-use input can invalidate later thinking blocks under the documented native behavior.
4. Did the client remove one thinking block but retain newer ones, or later reinsert a block it had removed? Keep an unbroken history of whatever signed blocks you continue to send. If you remove reasoning intentionally, do so consistently and leave removed blocks out; don’t splice older blocks back into a newer transcript.
5. Did the serving model change? Anthropic distinguishes a block from a model the current model can read from a signature or prefix mismatch. A model-compatibility drop is not proof of a corrupt signature. Tokenhot model-code labels must not be equated to Anthropic model names without a documented mapping.

Append-only history is the safer pattern: keep the prior system and tools fixed for that conversation, preserve existing messages and their content, and append the new user turn. Here is a shape-level illustration, not a runnable signed request: replace the note with the complete assistant content array your own successful response returned. Never send the explanatory placeholder literally.

{
  "model": "<the same documented route code for your conversation>",
  "system": "<unchanged system prompt, if any>",
  "tools": ["<unchanged tool definitions, if any>"],
  "messages": [
    {"role": "user", "content": "What is 18 times 7?"},
    {"role": "assistant", "content": "<exact original response content array, including all thinking and signature fields>"},
    {"role": "user", "content": "Now explain the calculation."}
  ]
}

An invalid replay can look superficially reasonable while changing a prior message. For example, if the original first prompt was “What is 18 times 7?”, don’t replace it with a cleaned-up paraphrase such as “Calculate 18 × 7” and then resend later signed thinking blocks. Under Anthropic’s documented prefix rule for the models it names, that edit changes the prefix. For the documented prefix-bound models, Anthropic allows removing thinking blocks from the start, end, or all of history; the invalid gap case is retaining original blocks A and C after deleting middle block B. This is not a blanket ban on trimming. These are examples of history edits to inspect, not proof that every model or gateway will return the same error.

Choose the recovery branch from the evidence

• The request names a changed conversation prefix. Fix the client’s history mutation first. Keep prior system, tools, and messages stable and append new turns. Don’t resend an identical failing body; it will not repair the prefix. If your client intentionally changes instructions or tools, start a new conversation/history at that boundary rather than silently rewriting old context while keeping signed blocks.
• The error says the signature is tampered with or cannot be decrypted, without naming a prefix mismatch. Don’t try to reconstruct the signature. Verify that persistence, serialization, database migrations, and logging did not truncate or transform the original content. Compare the stored assistant block with the raw response at byte/field level. If it differs, restore the original block from a trusted saved response or begin a fresh conversation without the damaged block. If the bytes match and the error remains, ask the relevant API provider to interpret a redacted request/response and request ID.
• The API reports a dropped block or the model changed. Determine whether the API intentionally omitted a block because of model readability or a configured mismatch policy. That may let a request continue without that earlier reasoning; it does not repair client-side transcript edits. Retain the original server response and any transformation metadata while diagnosing.
• The request uses a translated gateway protocol. Check the gateway’s documentation for that wire format. Anthropic’s native Messages payload conventions do not establish how an OpenAI-compatible or other translated route serializes, validates, or strips thinking blocks.

Anthropic currently documents a drop-block option for its named prefix-mismatch scenario, with a beta header and model/account conditions. It explicitly cautions that dropping hides the mismatch rather than fixing the changed prefix. Do not add that option to a Tokenhot request unless current Tokenhot route documentation or provider support confirms it is supported and applicable. Likewise, do not treat deletion of every thinking block as a universal fix: a redacted-signature failure, a protocol translation issue, or a client-side storage bug may need a different diagnosis.

What Tokenhot’s route pages establish

Tokenhot’s public entries currently identify POST https://api.tokenhot.ai/v1/messages and the listed model codes “claude-sonnet-5,” “claude-opus-4-6,” and “claude-opus-4-8.” Their visible examples show basic user-message requests and sample responses, not a signed-thinking replay or the detailed prefix-binding rules described above. The Opus 4.8 entry’s response sample even shows a different model string, so do not infer an alias mapping from the sample. See the Sonnet 5, Opus 4.6, and Opus 4.8 route pages for the current endpoint and labels; none of those excerpts confirms how Tokenhot handles invalid signatures.

For a Tokenhot request, first keep the failing request ID, timestamp, route model code, status/error body, and a redacted copy of the exact history that was sent. Confirm the request is using the native Messages format, then compare it with the saved response that supplied the signed block. If the payload is intact and the same error persists, ask Tokenhot support whether that exact route/model code accepts and preserves the block. This article has not made a live Tokenhot request and does not claim the failure was reproduced.

A short diagnostic checklist

• The exact assistant response content array is preserved, including thinking and redacted-thinking blocks and opaque signatures.
• The same system, tool definitions, and earlier message contents are sent for the same conversation; only new turns are appended.
• The client has not trimmed, summarized, reordered, or reinserted signed blocks midway through the transcript.
• The route/model’s documented behavior is checked without assuming its label maps to another provider’s version.
• The error text is classified as prefix mismatch, invalid/tampered signature, model readability/drop, or an unknown gateway response before selecting a recovery.
• Any support handoff redacts credentials and private content; no signature is edited or regenerated.

If you can’t determine whether a Tokenhot response came from native Anthropic validation or gateway translation, keep that cause open. The useful next step is a provider-specific answer tied to the route code and redacted raw request—not a universal edit to signed conversation data.

The paired invalid pattern below changes the earlier prompt while retaining a later signed assistant block. It is a JSON-shaped counterexample, not an actual request or observed error:

{
  "model": "<same route code>",
  "messages": [
    {"role": "user", "content": "Calculate 18 × 7"},
    {"role": "assistant", "content": "<thinking block copied from the earlier, different prompt>"}
  ]
}

The problem is the changed prefix plus a retained block. A fresh conversation can start with the revised prompt, but do not graft a later block from the old transcript onto it.