Claude Thinking Block Binding: Why Agent History Becomes an Append-Only Ledger

If your Claude integration rewrites its own conversation history, the API may return a 400 error beginning with messages.1.content.0: Invalid \signature` in `thinking` block` — indicating that the thinking block has been bound to a different conversation. The leading path varies with the failing block, so when debugging, keep your eyes on the description that follows the path.

This wording comes from Anthropic's preserved thinking documentation. Anthropic explained the origin of this rule in a research article on distillation defense: preserved thinking is "a measure to prevent newly created API accounts from editing Claude's prior context." It is one of a three-layer defense system designed to stop other labs from training their own models on Claude's reasoning process. Anthropic offers a combined conclusion in the article:

Early evidence suggests these methods reduced the amount of data distillers collect by roughly 90% to 99%.

Anthropic calls it "early evidence" and doesn't explain how it was measured. The cost on your side is easier to pin down: the same article acknowledges that preserved thinking "requires some developers to update their integrations."

Three layers of defense, one of which sits on your request path

The three layers Anthropic lists are:

• Preserved thinking: shipped alongside Claude Fable 5.1 and Claude Opus 5.5. On Claude Sonnet 5.5, the reasoning record is only visible to the organization that made the request.
• Two-stage classifiers: running on Claude Sonnet 5.5, Opus 5 and 5.5, and Fable 5 and 5.1, which Anthropic says have a false-positive rate below 0.1%.
• Enforcement: accounts that persistently attempt to extract reasoning are subject to stricter limits and even bans. Anthropic has resumed charging for requests that are intercepted by safety mechanisms before Claude responds, provided those safety mechanisms have a false-positive rate below 0.1% in areas like distillation.

Some media outlets described this tradeoff as "defensible," while noting that it shifts friction onto paying customers. The classifiers and billing rules mainly come into play when you're unlucky; preserved thinking affects every multi-turn integration, because it changes the definition of a "valid request."

What the API checks on every thinking block

For every thinking or redacted_thinking block you send back, the documentation describes two checks. First, the model must be able to read the block, otherwise the API silently drops it without an error. Second: "nothing before the thinking block has changed."

"Before" here refers to the top-level system prompt, the tools array, and every message preceding the block. If any one of these differs from the state when the block was generated, that block and all thinking blocks after it are invalidated.

Enforcement depends on account creation time: accounts created after this point have the check enabled by default and receive a 400 error; on older accounts the check still runs, but it's only truly enforced for requests that set a specific parameter, otherwise the failing block is passed through to the model. The prefix check covers multiple models.

Appending messages is always valid. Modifications to effort, max_tokens, tool_choice, metadata, and cache_control markers are also valid, and server-side compaction doesn't trigger problems either, because the check "compares what you send, not the server-edited copy."

What are thinking blocks and signatures

In Anthropic's extended thinking mechanism, the model outputs a reasoning process before giving its final answer. When thinking is enabled, the API response includes a content block of type thinking, whose structure is roughly {"type": "thinking", "thinking": "...", "signature": "..."}. The signature is an encrypted verification value bound to the full context that generated the block, produced by Anthropic's servers to prove that this reasoning was actually generated by the corresponding model under that specific prefix. When the client sends history back in subsequent turns, it must carry these blocks verbatim, and the server re-verifies whether the signature matches the current request's system, tools, and preceding messages. redacted_thinking is a variant returned when reasoning content is redacted by safety policy; its structure is similar but the thinking field is replaced with unreadable ciphertext, and the signature still carries binding information. Precisely because of this, even a single-character change in the prefix causes signature verification to fail, and the API rejects the entire request with a 400 error.

These habits now break the agent loop

Most agent frameworks modify history somewhere. The documentation lists the patterns that fail, along with alternatives:

1. Re-rendering the system prompt. Injecting the current date or reloading an updated CLAUDE.md/AGENTS.md into system changes the prefix. Instead, load instruction files once at the start, and append later versions as mid-conversation system messages, or place them in the next user turn if you don't trust the file contents.
2. Editing tools mid-session. Declare the full toolset at the start, mark tools added afterward with defer_loading: true, and enable or withdraw them via tool_addition and tool_removal blocks.
3. Disabling tool use by removing tools. Use tool_choice: {"type": "none"} instead.
4. Trimming turns from the middle. This invalidates every thinking block after the cut point. Use server-side context editing to prune old tool results instead.
5. Writing your own keep-tail summaries. Retained turns carry thinking generated against a history that has since been replaced. Let the API generate summaries via on-demand compaction, or strip thinking from retained turns.
6. Serializers that skip "empty" blocks. The documentation warns that the thinking field defaults to empty, and that reasoning content is carried by the signature. Dropping this block means dropping the reasoning.

There are two more subtle issues: gateways that move role: "system" messages into the top-level system field invalidate every thinking block in the conversation; and images or documents referenced via URL break subsequent thinking when their content changes. When referencing anything across turns, use the Files API and file_id.

defer_loading and tool_addition / tool_removal

The alternative Anthropic provides for dynamically changing toolsets involves several tool fields. A tool marked with defer_loading: true doesn't immediately stuff its full definition into the context when declared; instead, the definition is deferred until the tool is actually called, keeping the prefix stable. The tool_addition block is used to formally activate a previously deferred tool mid-conversation, while tool_removal does the opposite, withdrawing a tool. These two blocks are themselves designed as appendable increments, so they don't change the prefix that earlier thinking blocks depend on. By contrast, directly adding or removing elements of the tools array makes the prefix inconsistent with the one present when the thinking blocks were generated, triggering signature errors like messages.1.content.0. In effect, this design turns "variable toolsets" from an array-editing problem into an explicit event problem within the message stream.

Find those changes before they become 400 errors

You don't need a new account to test. The documentation FAQ states that older accounts can send the thinking-binding-controls-2026-08-01 beta header without setting prefix_mismatch_behavior. Failing blocks still reach the model, and the response lists them in input_transformations with thinking_mismatch_allowed:

import logging
import anthropic

client = anthropic.Anthropic()

resp = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    system=system_prompt,
    tools=tools,
    messages=history,
    betas=["thinking-binding-controls-2026-08-01"],
)

for t in resp.input_transformations or []:
    reason = getattr(t, "reason", None)
    logging.warning("%s %s %s", t.type, t.path, reason)

Each record carries a path, such as messages.1.content.0. The first record points to the earliest block your framework invalidated.

If you can't fix the modification right away, the temporary workaround is drop_block:

thinking={
    "type": "adaptive",
    "block_binding": {
        "prefix_mismatch_behavior": "drop_block",
    },
}

This way the request succeeds, the API discards every failing block and all blocks after it, and lists them with reason: "prefix_binding_mismatch". The documentation warns this can "significantly increase the number of generated output tokens," ranging from 2.5% to 67.1% in one multi-turn coding benchmark, depending on effort and how often blocks are dropped. The model also answers without prior reasoning, so you should plan to remove the modification triggering this behavior.

input_transformations and the beta header

thinking-binding-controls-2026-08-01 is an Anthropic beta header that, once enabled, adjusts the triggering behavior of thinking block prefix validation. Its companion parameter prefix_mismatch_behavior determines how validation failures are handled: the default (for new accounts) returns a 400 directly, while setting it to drop_block lets the request through but discards the invalidated blocks. Older accounts that don't set this parameter pass the failing blocks through to the model as-is and list them one by one in the response's input_transformations array, each containing type, path, and reason fields. The path uses JSON-pointer style, e.g. messages.1.content.0 means the first content block of the second message, letting you locate exactly where your framework first corrupts history. This observability lets you reproduce and debug prefix mismatches without a new account.

What you can change in the near term

The following recommendations all come from the documentation:

• Persist exactly what you send and receive: the rendered system prompt and tool definitions, and every assistant turn returned. Replay these on resume, rather than re-rendering from inputs that may have changed.
• If you run a proxy or gateway, pass through the anthropic-beta values and thinking.block_binding, return input_transformations to the caller, and don't silently strip thinking and retry on a 400.
• If you use multiple accounts, note that Sonnet 5.5 and Haiku 5.5 thinking blocks cannot be reused from another unrelated account.

My take: Anthropic is paying for its distillation defense with your engineering time. The upside is that an append-only, replayable message record is also the easiest kind of agent run log to debug.

Files API and file_id

The article mentions that images or documents referenced via URL break subsequent thinking blocks when their content changes, and the solution is to use the Files API. The Files API lets you first upload a file to Anthropic's side and get a stable file_id, then reference it in messages via file_id instead of directly embedding a URL or file content. Since the file_id itself doesn't change when the underlying source file changes, the prefix stays consistent during signature verification, and the thinking blocks remain valid. If you use a URL instead, the server re-fetches the content by URL on every request, and once the source file changes, the prefix changes, invalidating all prior thinking blocks that carry signatures. For agent scenarios that need to reference the same image or document across multiple turns, the Files API is essentially the only reliable approach.

One-line Summary

Anthropic's preserved thinking requires thinking block prefixes to be immutable, and common agent framework history rewrites now cause 400 errors.

Paragraph Summary

To prevent model distillation, Anthropic introduced the preserved thinking mechanism: the content preceding a returned thinking block (system prompt, tools array, prior messages) must exactly match the state at generation time, or signature verification fails with a 400 error. This check is enforced by default for new accounts, while older accounts trigger it via a beta header or a specific parameter. Six common agent framework practices — re-rendering the system prompt, editing the toolset mid-session, trimming middle turns, and more — now break requests. Developers can use the thinking-binding-controls-2026-08-01 beta header and input_transformations output to pinpoint problems early, or use drop_block as a temporary workaround, at the cost of significantly more output tokens. The fundamental fix is to persist and replay exactly what was sent and received.