Reading Anthropic's Report on Countering Distillation Attacks: How Preserved Thinking Changes the Handling of Conversation History in the Claude API

Hello! I'm Yuji Nishimura from the Operations Department!

On October 12, 2026, Anthropic published an article titled Strengthening our defenses against distillation attacks. It summarizes what defenses were put in place against "distillation attacks," in which other companies collect large volumes of Claude's outputs and use them to train their own models, and how effective those defenses have been.

It may look like a national-security topic, but some of the defenses are built into the Claude API specification. Depending on how you assemble the conversation history, a 400 error may now be returned, and blocked requests are also billed. In this article, I summarize the claims in the original post and, by checking them against the preserved thinking documentation, look at what people who write their own API integrations should verify. I will not go into the individual cases of the named companies or policy debates such as export controls.

Effect reported by Anthropic: roughly 90–99% reduction in data that can be collected

The results listed in the original post are as follows. All of them are Anthropic's own announcements, not figures verified by a third party.

The original also states that these gains are not guaranteed to last. Distillation is an ongoing back-and-forth between attack and defense, and the caveat is that they have not yet seen a sophisticated, persistent attacker take on these defenses (section "How well our new methods work").

Why reasoning transcripts are targeted

According to the original, what distillers want most is not the final answer but the reasoning transcripts leading up to Claude's answer. As an example showing the value of the reasoning itself, it gives the following comparison: a model trained on the unaltered reasoning of Claude Opus 4.8 scored 80.4% on SWE-bench Verified, while a model trained on summarized reasoning scored 71.8% (section "Simple defenses are not enough").

The first countermeasure was to summarize the reasoning before showing it. The attackers then switched to extraction that made Claude output its past reasoning "verbatim, exactly character for character." The original describes a case in which one lab tried a different extraction technique in each of 12,000 requests, and a network that operated more than 20,000 accounts simultaneously.

(This is a conceptual diagram created by the author based on the original's description.)

Three defenses that protect reasoning

The original divides the new defenses into three (section "Our new methods").

1. Controlling where reasoning goes (preserved thinking)

This is a mechanism introduced with Claude Fable 5.1 and Claude Opus 5.5. The original explains it in the following three points:

• For new API accounts created on or after August 31, 2026, Claude's past context cannot be rewritten
• Reasoning produced by newer models cannot be read by older models with weaker defenses
• Claude Sonnet 5.5's reasoning can only be used by the organization that sent the request

The impact on API users is covered in the next chapter.

2. Detecting and blocking extraction attempts

A two-stage classifier based on research on constitutional classifiers detects and blocks requests aimed at extracting reasoning. According to the original, this classifier has been tested by internal and external red teams. Its robustness is said to be roughly on par with the safeguards that prevent assistance related to biological weapons. It covers Claude Sonnet 5.5, Claude Opus 5 and 5.5, and Claude Fable 5 and 5.1, and will also be applied to comparable future models. The post says workarounds such as having the model translate its reasoning or write it enclosed in tags were also individually closed off.

3. Making repeated attempts not worth the cost

Accounts that repeat extraction are subject to strict usage limits and are ultimately banned. In addition, from September 24, 2026, billing resumed for requests that are blocked before Claude responds.

What to check on the API integration side

From here on is the author's own summary after reading the original and the preserved thinking documentation.

It depends on whether you assemble requests yourself

According to the "Who needs to change anything" section of the documentation, if Claude Code, claude.ai, Claude Managed Agents, or the Claude Agent SDK assembles the requests, you don't need to change anything. Implementations that keep system and tools fixed throughout the conversation and only append to messages likewise need no changes.

What needs checking is an implementation that calls the Messages API directly and modifies the history midway through a conversation.

What counts as "rewriting"

For each returned thinking block, the API looks at the signature and checks the following two points:

• Whether the system, tools, and messages before that block (called the "prefix" in the documentation) are the same as when the block was generated
• Whether the current model can read that block

If the prefix has changed, the thinking blocks from that block onward become invalid. The prefix check applies to requests to Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5, and Claude Haiku 5.5; it is not performed for Claude Mythos 5.1 or models older than Fable 5.1. The documentation gives the following kinds of processing as examples of rewriting:

• Rebuilding the system prompt to match the date, mode, or an MCP server connected later
• Deleting or shortening old tool results
• Summarizing or deleting old turns on the client side and leaving only the new turns with thinking attached
• Adding, removing, or editing entries in tools
• Later deleting or rewriting reminders attached to user turns
• Passing through a serializer that omits empty thinking blocks (in Fable 5.1, Opus 5.5, Sonnet 5.5, and Haiku 5.5, the thinking field is empty by default and the reasoning is contained in signature, so omitting it loses the reasoning along with it)

On the other hand, changes to effort, max_tokens, tool_choice, and metadata, and adding or removing cache_control (changing prompt cache positions), for example, are not subject to the check.

Homemade agents often include processing that thins out old tool results to save context. This is the part the author would check first.

(This is a conceptual diagram created by the author based on the documentation. Refer to the documentation for the actual request format.)

Default behavior differs by account creation date

The prefix check is enabled by default for accounts created at or after 00:00 UTC on August 31, 2026. For accounts created before that, it applies only to requests that specify thinking.block_binding.prefix_mismatch_behavior. Using this field requires the beta header thinking-binding-controls-2026-08-01, and specifying it without the header results in a 400 error.

If you develop on an old account and run production on a new account, the 400 error will appear only in production. If you operate with separate accounts per customer, you will also want to check each account's creation date.

When the check fails: stop with a 400, or drop the block and continue

You can choose the behavior on check failure with prefix_mismatch_behavior.

• "error" (the default when the check is enabled): returns a 400 invalid_request_error indicating the first block that failed
• "drop_block": drops the failed block and the thinking blocks after it and continues processing

However, in the Message Batches API, even on accounts where the check is enabled by default, no error occurs unless the field is specified, and the failed blocks are dropped. If you want an error, specify "error" explicitly.

With "drop_block" no error is raised, but output tokens increase because the model has to redo its reasoning. The increase in output tokens, per Anthropic's measurements listed in the documentation (described as estimates with wide margins of error), is as follows:

• When dropped once per session: 2.5% (low effort) to 20.1% (max effort)
• When dropped every turn from the second turn onward: 4.6% (low effort) to 67.1% (max effort)

The documentation itself positions "drop_block" as a stopgap rather than a fundamental fix.

If you attach the same beta header, dropped blocks and the reason are included in the response's input_transformations as thinking_dropped. The reason is one of prefix_binding_mismatch, model_binding_mismatch, or organization_binding_mismatch.

If you attach only the header without specifying the field on an old account, blocks are not dropped but passed to the model, and the prefix mismatch is recorded as thinking_mismatch_allowed. This can be used as a way to observe where rewriting occurs without stopping production traffic.

Switching models and using across accounts

The thinking blocks each model can read are fixed, and blocks it cannot read are silently dropped rather than causing an error. For example, according to the documentation, earlier models such as Claude Opus 5 cannot read Claude Fable 5.1's blocks. This is one instance of the mechanism described in the previous chapter of "preventing older models from reading it." Note that Opus 5.5 also cannot read Fable 5.1's blocks. If you have routing that switches from Fable 5.1 to Opus midway through a conversation, the reasoning up to that point is not carried over, and no error appears.

In the documentation, in addition to the Sonnet 5.5 cited in the original, Claude Haiku 5.5 is also covered, and thinking blocks can only be used by the account that generated them or an account linked to it. In a design that carries conversation history over to a different account, design on the assumption that the reasoning will not be carried over.

Avoiding requests that are billed even when blocked

As mentioned above, blocked requests are also billed, and as the table shows, the false positive rate is below 0.1% but not zero. The author thinks it is safest to avoid prompts that make the model output its own reasoning in full verbatim, even for legitimate purposes. Note that neither the original nor the documentation says what kind of response is returned when a request is blocked.

Limitations and caveats

• The original does not give details of the measurement methods behind effect figures such as 90–99% and 10–100 times
• The original is a blog post, not a standalone paper. The classifier's evaluation data and the red team's conditions have not been published
• The preserved thinking specification includes a beta header and date-stamped feature names, and may change in the future. Check the latest version of the documentation before implementing
• This article is a summary based on the documentation's descriptions, not a reproduction of the 400 errors or input_transformations on a real environment

Summary

Anthropic's article positions reasoning transcripts as the primary target of distillation. It then reports that three defenses, namely controlling where reasoning goes, detecting extraction, and deterring repeated attempts, greatly reduced leakage.

The key points for the API integration side are to keep system and tools fixed during the conversation and to only append to messages. For homemade agents that thin out old tool results or rebuild system, using a covered model on an account created on or after August 31, 2026 returns a 400 error by default. Even on older accounts, attaching the beta header and watching for thinking_mismatch_allowed in input_transformations will make migration easier. Also, if you switch models midway or cross accounts, the reasoning is dropped without an error. If you use Claude via Claude Code, the Claude Agent SDK, or Managed Agents, no action is needed.

I hope this is helpful to someone.

Reference links:

• Strengthening our defenses against distillation attacks
• Preserved thinking (Claude Docs)
• Next-generation constitutional classifiers