Reading Anthropic's Distillation Attack Countermeasure Report: How Claude API Conversation History Handling Changes with Preserved Thinking
This page has been translated by machine translation. View original
Hi there! I'm Yuji Nishimura from the Operations Division!
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" — where other companies collect large volumes of Claude's outputs to train their own models — and how effective those defenses have been.
While it may look like it leans toward national security topics, some of the defensive measures have been incorporated into the Claude API specification. Depending on how you construct conversation history, you may now receive 400 errors, and you will be charged even for blocked requests. This article summarizes the claims made in the original, then walks through what people who write their own API integrations should check, cross-referencing with the preserved thinking documentation. We will not go into the individual cases of named companies or policy discussions around export controls.
Results Reported by Anthropic: ~90–99% Reduction in Collectable Data
The results cited in the original are as follows. These are all figures from Anthropic's own announcement and have not been independently verified by third parties.
| Item | Description in the original |
|---|---|
| Overall effect | Approximately 90–99% reduction in the data distillers can collect (initial estimates) |
| Reasoning token extraction | After introducing classifiers, reasoning tokens extracted on the platform decreased by 10–100x or more. Some days the amount was too small to measure |
| Account suspensions | Tens of thousands of accounts involved in distillation were suspended. Many were stopped within 2 hours of a campaign starting |
| Classifier false positive rate | Under 0.1% |
| Lost revenue | Paid traffic worth trillions of tokens was turned away |
The original also notes that these results may not last. Distillation is an ongoing back-and-forth between attack and defense, and they have not yet seen sophisticated, persistent attackers challenge these defenses (see the "How well our new methods work" section).
Why Reasoning Transcripts Are Being Targeted
According to the original, what distillers want most is not the final answer but the reasoning transcripts — Claude's step-by-step reasoning leading up to an answer. As an example illustrating the value of the reasoning itself, the following comparison is given: a model trained on Claude Opus 4.8's reasoning as-is scored 80.4% on SWE-bench Verified, while a model trained on summarized reasoning scored 71.8% (see the "Simple defenses are not enough" section).
The first countermeasure was to show only a summary of the reasoning. Attackers then switched to extraction methods that made Claude output its past reasoning "verbatim, exactly character for character." The original includes examples of one lab trying 12,000 requests with different extraction techniques each, and a network operating over 20,000 accounts simultaneously.
(A conceptual diagram created by the author based on descriptions in the original)
Three Defenses That Protect Reasoning
The original breaks the new defenses into three categories (see the "Our new methods" section).
1. Controlling Where Reasoning Goes (Preserved Thinking)
This is a mechanism introduced in Claude Fable 5.1 and Claude Opus 5.5. The original explains three key points:
- For new API accounts created after August 31, 2026, Claude's past context cannot be rewritten
- Reasoning produced by a new model is made unreadable by older models with weaker defenses
- Reasoning from Claude Sonnet 5.5 can only be used by the organization that sent the request
The impact on API users is covered in the next section.
2. Detecting and Blocking Extraction Attempts
A two-stage classifier based on constitutional classifiers research detects and blocks requests aimed at extracting reasoning. According to the original, this classifier has been validated by both internal and external red teams. Its robustness is described as roughly on par with the safeguards that prevent assistance with bioweapons-related matters. It applies to Claude Sonnet 5.5, Claude Opus 5 and 5.5, and Claude Fable 5 and 5.1, with plans to apply it to equivalent future models. Specific workarounds such as having Claude translate reasoning or write it wrapped in tags have also been individually blocked.
3. Making Repeated Attempts Not Worth It
Accounts that repeatedly attempt extraction face strict usage limits and are ultimately suspended. Additionally, starting September 24, 2026, charging resumed for requests blocked before Claude responds.
What to Check on the API Integration Side
The following is the author's summary based on reading both the original article and the preserved thinking documentation.
It Depends on Whether You're Building Requests Yourself
According to the "Who needs to change anything" section of the documentation, no changes are needed if requests are being constructed by Claude Code, claude.ai, Claude Managed Agents, or the Claude Agent SDK. Implementations that simply keep system and tools fixed throughout a conversation and only append to messages also require no changes.
What needs checking is any implementation that calls the Messages API directly and manipulates the history mid-conversation.
What Counts as a "Rewrite"
The API side checks the signature of each returned thinking block to verify two things:
- Whether the
system,tools, andmessages(what the documentation calls the "prefix") before that block are the same as when the block was generated - Whether the current model can read that block
If the prefix has changed, thinking blocks from that block onward become invalid. The prefix check applies to requests for Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5, and Claude Haiku 5.5, but not to Claude Mythos 5.1 or models earlier than Fable 5.1. The documentation gives the following examples of operations that count as rewrites:
- Rebuilding the
systemprompt to reflect dates, modes, or newly connected MCP servers - Removing or truncating old tool results
- Summarizing or deleting old turns on the client side and keeping only newer turns with thinking attached
- Adding, removing, or editing entries in
tools - Removing or rewriting reminders added to user turns after the fact
- Passing through a serializer that omits empty
thinkingblocks (in Fable 5.1, Opus 5.5, Sonnet 5.5, and Haiku 5.5, thethinkingfield is empty by default and reasoning is stored in thesignature, so omitting it causes the reasoning to be lost along with the block)
On the other hand, changes to effort, max_tokens, tool_choice, and metadata, as well as adding or removing cache_control (changing the prompt cache position), are not subject to the check.
In custom agents, it is common to include logic that prunes old tool results to save context. This is the first thing the author would want to check.
(A conceptual diagram created by the author based on descriptions in the documentation. Please 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 on or after August 31, 2026 at 00:00 UTC. For accounts created before that date, it only applies to requests that explicitly specify thinking.block_binding.prefix_mismatch_behavior. Using this field requires the beta header thinking-binding-controls-2026-08-01; specifying it without the header will result in a 400 error.
If you develop on an older account and run production on a newer account, you may see 400 errors only in production. If you operate separate accounts per customer, the creation date of each account is worth checking.
When the Check Fails: Stop with a 400 or Drop the Block and Continue
The behavior when the check fails can be configured with prefix_mismatch_behavior:
"error"(default when the check is enabled): Returns a 400invalid_request_errorindicating the first block that failed"drop_block": Drops the failed block and all subsequent thinking blocks and continues processing
However, in the Message Batches API, even for accounts where the check is enabled by default, if the field is not specified no error is raised and failed blocks are simply dropped. Specify "error" explicitly if you want an error.
Choosing "drop_block" avoids errors, but output tokens increase because the model has to redo its reasoning. The documentation includes Anthropic's measurements of the increase in output tokens (described as estimates with wide error margins):
- Dropped once per session: 2.5% (low effort) to 20.1% (max effort)
- Dropped every turn from the second turn onward: 4.6% (low effort) to 67.1% (max effort)
The documentation itself characterizes "drop_block" as a stopgap, not a fundamental fix.
When the same beta header is included, dropped blocks and their reasons appear as thinking_dropped in the response's input_transformations. The reason will be one of prefix_binding_mismatch, model_binding_mismatch, or organization_binding_mismatch.
For older accounts where only the header is included without specifying the field, blocks are passed to the model without being dropped, and prefix mismatches are recorded as thinking_mismatch_allowed. This can serve as a way to observe where rewrites are occurring without interrupting production traffic.
Model Switching and Cross-Account Usage
Each model can only read certain thinking blocks, and blocks it cannot read are silently dropped without raising an error. For example, according to the documentation, older models like Claude Opus 5 cannot read Claude Fable 5.1's blocks. This is one example of the mechanism described earlier as "making it unreadable by older models." 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 mid-conversation, the reasoning up to that point will not carry over, and no error will be raised.
In the documentation, Claude Haiku 5.5 is covered in addition to Claude Sonnet 5.5 as mentioned in the original, and thinking blocks can only be used by the account that generated them or accounts linked to it. For designs that pass conversation history between different accounts, plan with the assumption that reasoning will not carry over.
Avoiding Requests That Are Charged Even When Blocked
As noted above, blocked requests are still charged, and while the false positive rate is under 0.1% as shown in the table, it is not zero. The author's view is that even for legitimate use cases, it is wise to avoid prompts that cause the model to output its own reasoning verbatim in full. Note that neither the original nor the documentation describes what response is returned when a request is blocked.
Limitations and Caveats
- The original does not provide details on how figures such as 90–99% and 10–100x were measured
- The original is a blog post, not a standalone paper. The classifier evaluation data and red team conditions have not been published
- The preserved thinking specification includes beta headers and date-stamped feature names and may change in the future. Please check the latest version of the documentation before implementing
- This article is not based on reproducing 400 errors or
input_transformationsin a live environment, but is a summary based on the documentation
Summary
Anthropic's article identifies reasoning transcripts as the primary target of distillation. It then reports that three defenses — controlling where reasoning goes, detecting extraction attempts, and discouraging repeated attempts — have been put in place and have significantly reduced leakage.
The key point for API integrations is to keep system and tools fixed throughout a conversation and only append to messages. For custom agents that prune old tool results or rebuild system, using a target model on an account created after August 31, 2026 will result in 400 errors by default. Even on older accounts, including the beta header and monitoring thinking_mismatch_allowed in input_transformations will make migration easier. Also note that switching models mid-conversation or using reasoning across accounts will cause reasoning to be silently dropped without an error. If you are using Claude Code, the Claude Agent SDK, or Managed Agents, no action is required.
I hope this is helpful to someone.
Reference links:
