Fable 5.2 preserved thinking now binds every API account

Anthropic now applies preserved thinking on Claude Fable 5.2 and Claude Mythos 5.2 to every API account. On the Claude API, a request that sends a thinking block back after the system prompt, tools, or earlier messages have changed, and leaves prefix_mismatch_behavior unset, returns a 400. Accounts created before August 31, 2026 were exempt on several earlier models. They are not exempt on these two.

That is a harness constraint. Stacks that compact history on the client, inject reminders, or change tools mid-session can fail on Fable 5.2 even when the same key was fine on Claude Fable 5.1.

What the prefix check actually covers

A thinking block stays valid only while everything sent before it is unchanged on later requests. The checked prefix has three parts: the top-level system prompt, the set of tools, and every message before the block. If that prefix differs from the request that produced the block, that block and every later thinking block already in the history fail the prefix check. With server-side compaction, the checked prefix starts at the most recent compaction block.

Parameters outside those three fields are not part of the check. The platform docs name effort, max_tokens, output_config, tool_choice, and metadata, and say cache_control markers are not checked either. Appending messages at the end is valid. So is server-side compaction or context editing, because the check compares what you sent, not the server’s edited copy.

Edits the docs mark invalid include changing, reordering, or deleting an earlier user, assistant, or system message, except when the signed block from on-demand compaction replaces the messages it summarizes. Re-rendering context in the first user message invalidates every thinking block. Clearing or shortening an earlier tool result, re-encoding an earlier image, or changing an earlier tool-use input invalidates later thinking blocks. So does adding, removing, renaming, or editing a tool.

Thinking blocks also record which block came before them. You can remove blocks from the start of the history, from the end, or all of them. A gap fails: removing one from the middle invalidates later blocks, and putting a removed block back invalidates blocks produced while it was gone. An unpinned MCP connector tool list that changes between requests is invalid for thinking blocks from Claude Fable 5.2 and Claude Mythos 5.2.

Every account, not only new ones

When prefix_mismatch_behavior is unset, the outcome depends on the model and when the account was created. The cutoff is 00:00 UTC on August 31, 2026. On Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5, and Claude Haiku 5.5, accounts created before that cutoff do not get the 400; failing blocks reach the model. Claude Fable 5.2 and Claude Mythos 5.2 show a 400 in both columns of the platform table. The help center states the same rule: on those two models, preserved thinking applies to all API accounts.

The help center says this covers Claude Platform organizations, Amazon Bedrock accounts, Google Cloud Vertex AI projects, and Microsoft Foundry projects. Anthropic describes the check as a defense against illicit distillation. The help center says altering earlier turns is a common, publicly documented technique used in illicit distillation, and that illicit distillation is what its Usage Policy and Terms of Service prohibit. Separately, it says editing the conversation before a thinking block could get Claude to decrypt and print its reasoning. Legitimate modifications are still supported, but not by rewriting the prefix.

A clean run on your own key is not proof that a shared library keeps the prefix intact. The docs warn that people who run your tool with their own keys can get a 400 even when you do not, on models where older accounts are exempt. On Fable 5.2 and Mythos 5.2 that exemption is gone. The platform docs say to keep one diagnostic example on Claude Fable 5.1, because on Claude Fable 5.2 and Claude Mythos 5.2 the third request in that example, which adds a system prompt, gets the 400 on every account.

The 400, and the drop_block stopgap

The error starts:

messages.1.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block".

If the request did not send the beta header, the message continues that the setting requires thinking-binding-controls-2026-08-01 in the anthropic-beta header. It usually ends by naming what changed, such as the system prompt or the tools list.

A tampered or undecryptable signature is a different failure. It always returns a 400, and prefix_mismatch_behavior does not apply.

To continue instead of failing, opt into the thinking-binding-controls-2026-08-01 beta and set thinking.block_binding.prefix_mismatch_behavior to drop_block. Models that run the prefix check accept block_binding with thinking type adaptive, and none of them accepts it with enabled. The API then drops each failing block and every thinking block after it. The request succeeds. Dropped blocks are not billed. The model answers that turn without the dropped reasoning, and the prompt cache restarts at the edit. The response lists each dropped block in input_transformations with reason prefix_binding_mismatch. When streaming, that array arrives on the message object in the message_start event.

Both pages treat drop_block as a stopgap. Without earlier reasoning, Claude re-creates it, so output tokens rise and responses can take longer. The help center says dropping blocks can significantly increase output tokens. The long-term fix is to find the edit and replace it. Do not resend the same body: it fails the same way every time.

Message Batches items that leave the field unset do not get the 400. Where the table would show an error, the API drops the failing blocks instead. An item that sets the field to error and sends a failing block resolves as errored. The token counting endpoint runs the same prefix check and can return the same 400.

Change context without rewriting earlier turns

The platform docs map common harness edits to replacements that leave earlier bytes unchanged:

• Rebuild the top-level system prompt with a mid-conversation system message.
• Render first-turn context once, resend it unchanged, and put what changes in the newest turn.
• Shorten a tool result or downscale an image before the first send. To clear old results later, trim context on the server.
• Use on-demand compaction, or compact on the client and keep no stale thinking, instead of summarizing old turns and replaying recent ones with their thinking blocks. The help center says compaction can keep the most recent turns word for word and can build the summary in the background while an agent keeps working.
• Add or remove tools with tool_addition and tool_removal blocks. The help center points to the mid-conversation tool-change beta for the same job.
• Put reminders in a turn-scoped system message rather than writing them into a user turn and rewriting them later.
• Send assistant turns back exactly as returned.
• Persist what you sent and received, and replay that, instead of rebuilding a saved session from templates.
• From the first request, send an image or document by Files API file_id or base64 if a URL’s bytes can change.
• On the Claude API, pin an MCP server’s tool list when that list is not stable.

Keeping the prefix stable also lets the API reuse cached prompts more often, which the help center says reduces cost and response time.

Account-bound blocks, and no custom-harness exemption

Thinking blocks from Claude Fable 5.2, Claude Mythos 5.2, Claude Sonnet 5.5, and Claude Haiku 5.5 are tied to the account that produced them. If another, unlinked account sends them, the API drops them without an error. The help center says the next response may be slower and use more tokens, similar to a compaction. Accounts in the same Claude Platform parent organization, AWS organization, or Google Cloud organization are linked automatically. The help center does not say Microsoft Foundry projects are linked the same way.

If you use Claude Code, Claude Cowork, or Claude.ai, the help center says there is nothing to change. Those products handle thinking blocks for you. It does not say custom harnesses, libraries, proxies, or gateways are exempt.

Before the next Fable 5.2 session, diff system, tools, and the messages two consecutive requests share. If anything before a thinking block moves, switch that edit to a supported path on the preserved-thinking page rather than retrying the failing body.

Sources

• Preserved thinking platform.claude.com
• Preserved thinking: changing how the Messages API handles thinking blocks support.claude.com