Anthropic reports a sharp fall in harvested reasoning after new defences

Anthropic said on 12 October that its defences had reduced its estimate of reasoning tokens harvested through its platform by 90–99%. The estimate concerns extracted reasoning, not a measured fall of the same size in attackers or attack attempts. The company combines detection, account enforcement and restrictions on how thinking can be reused.[1]

For developers, the immediate consequence concerns saved thinking. Replaying it after changing the earlier request context can produce an error instead of a continuation.[2]

Why detailed reasoning is worth protecting

In an internal experiment described by Anthropic, a student trained using full Opus 4.8 reasoning traces scored 80.4% on SWE-bench Verified; the summarised-trace version scored 71.8%. The difference was 8.6 percentage points. This measures one training experiment, but it helps explain why detailed traces have value beyond the ordinary answers a service sells.[1]

A teacher’s worked solution can expose intermediate choices: which possibility it pursued, what it rejected and how it recovered. For a student, that is a richer lesson than a final answer alone. This is the basic economic tension: a service can sell useful completed work while trying to prevent systematic extraction of the material that makes a rival easier to train.

Anthropic also says it resumed charging for requests blocked by its distillation safeguards on 24 September. It estimates a false-positive rate below 0.1% for those blocks. Both the extraction reduction and the error estimate are the company’s own measurements, rather than an independently reproduced audit.[1]

The practical change is an append-only conversation

Signatures bind thinking to a compatible model and preceding system instructions, tools and messages. Prefix checks default on for accounts created from 31 August 2026. The documentation identifies Fable 5.1, Opus 5.5 and Sonnet 5.5 among affected models.[2]

Here is a deliberately simplified integration example. An application sends a system instruction saying “Today is 14 October” and receives a thinking block. On the next call, it replaces that instruction with “Today is 15 October”, but includes the old thinking. The developer may regard this as a harmless clock update. The signed context is nevertheless different.

A cleaner design is to keep the earlier request intact and supply the new date as additional conversational information, where appropriate. That lets the model see that time has advanced without rewriting what came before. The same design principle applies to changing a tool catalogue: the software should deliberately manage the transition rather than silently mutating old context.

Under the documented default, a prefix mismatch returns HTTP 400. The optional drop-block policy instead removes the incompatible thinking, losing that preserved reasoning. A model-compatibility mismatch is handled differently: the API silently drops the incompatible thinking rather than raising the prefix-mismatch error. An integration should distinguish these cases when diagnosing a lost continuation.[2]

Who needs to change anything?

Developers assembling API records themselves are most directly affected. Claude Code, claude.ai and the Claude Agent SDK manage conversation state for their users. Follow the contract for the interface actually in use.[2]

For an integration owner, the useful diagnostic is specific: when an existing conversation fails after an upgrade, inspect whether the application changed earlier instructions, tools or messages before replaying preserved thinking. Starting the entire task again may hide the symptom. Correctly managing the conversation boundary addresses the cause described in the API contract.

Report an error or suggest a correction