Preserved Thinking Splits the Claude API by Account Creation Date
Anthropic's new anti-distillation check fires for API accounts made on or after August 31, 2026, and for nobody else. If you maintain an agent harness, your users hit it before you do.
There is a timestamp in Anthropic's documentation that now decides whether your code runs: August 31, 2026, 00:00:00 UTC. API accounts created at or after that instant get a new validation check on Claude Fable 5.1. Accounts created a minute earlier do not. Same model, same weights, same request body, two outcomes.
The check is called preserved thinking, and the thing it validates is a field most developers have never looked at directly: the signature attached to every thinking block Claude returns. Send a thinking block back with anything before it altered, and a new account gets a 400. An old account gets a normal response.
I have spent enough time inside agent loops to know exactly what that means, and it is not "read the migration guide." It means a whole category of bug that is structurally invisible from the maintainer's own machine.
The failure mode is asymmetric, and the docs say so out loud
Anthropic's preserved thinking documentation contains a callout that deserves more attention than it is getting:
If you maintain a tool or framework that people run with their own API key, your users on new accounts hit the check before you do: your own key is likely on an older account.
Sit with that. If you ship an open-source agent harness, an MCP client, a CLI wrapper, or anything else that people run under their own credentials, your test key was almost certainly provisioned months ago. Your CI is green. Your local runs are fine. Every one of your users who signed up this week gets a 400 on turn two, and the stack trace points at your code.
This is the first time I can recall a model provider making API behavior a function of when the caller signed up rather than what they pay or which tier they sit on. Pricing tiers you can read off an account page. Feature flags you can query. A provisioning timestamp is a variable nobody has instrumented, because until this week it did not do anything.
What the check actually verifies
Claude produces reasoning steps before its final answer, and on the API those come back as thinking blocks. In a multi-turn conversation you send them back along with the system prompt, tools, and earlier messages so the model has full context. That round trip is where the check now lives.
Three conditions get checked on every request:
The model is the same or newer. A block is readable by the model that produced it and by later models, never by earlier ones. A conversation that gets routed down to an older model fails this check and the API drops those blocks for that request. If you run a fallback router, this will fire and it is not a bug in your code.
Nothing before the block has changed. The top-level system prompt, the entries in tools, and every message preceding the block. Byte-for-byte. With server-side compaction the checked prefix starts at the most recent compaction block.
The chain of earlier thinking blocks is unbroken. Each thinking block records the one before it, across turns. You can strip thinking blocks off the front of the history. Pull one out of the middle and every block after it is invalid.
The five patterns the docs name as breaking are the five patterns almost every hand-rolled agent loop uses:
- Trimming or dropping older turns
- Summarizing older turns on the client and keeping recent ones
- Injecting a reminder into an earlier turn and removing it next request
- Rebuilding the system prompt each request with current time, token budget, or mode flags
- Adding or removing entries in
toolsmid-session
If your harness does context compaction on the client, you do all five before lunch.
Why Anthropic did it
The stated reason is distillation. From the help center article: thinking blocks are encrypted, but by editing the conversation before a thinking block, a user could get Claude to decrypt and print its reasoning. Anthropic links the technique to a published paper and describes the campaigns as industrial scale, run across thousands of fake accounts.
That framing explains the account-age rule. New accounts are where the abuse concentrates, so enforcement starts there. Anthropic calls it a phased approach and says existing accounts are not affected on Fable 5.1, which buys harness authors time. The sentence after that is the one to plan against: preserved thinking "will apply to all users for future models." The deadline is a model release, and you do not get to schedule it.
There is a second reason in the docs that has nothing to do with safety. Keeping everything before each thinking block unchanged also keeps the prompt prefix stable, which means more cache hits. On a launch where cache reads dropped 75% to $0.25 per million tokens, a stable prefix is now the main lever on agentic cost. The check and the discount push in the same direction.
Put this into practice
The lowest-friction first step takes about two minutes and tells you whether you have a problem at all.
1. Find out if your account is enforced. Send a request that edits history, with no beta header. A 400 that names the thinking-binding-controls-2026-08-01 header means your account is enforced by default. Silence means you are on an old account and cannot see what your users see.
2. Test anyway, regardless of account age. Setting prefix_mismatch_behavior opts any request into enforcement. That is the whole trick for maintainers:
curl https://api.anthropic.com/v1/messages \
-H "content-type: application/json" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: thinking-binding-controls-2026-08-01" \
-d '{
"model": "claude-fable-5-1",
"max_tokens": 16000,
"thinking": {
"type": "adaptive",
"block_binding": { "prefix_mismatch_behavior": "drop_block" }
},
...
}'
With "drop_block" the request succeeds and the response carries a top-level input_transformations array listing what got removed. Run a normal multi-turn session through your integration and log that array on every turn. Empty on every turn means your history is intact. A reason of "prefix_binding_mismatch" names the exact path that broke, so you can diff system, tools, and messages up to that turn and find the culprit.
3. Fail loudly in CI. Same setup with "error" instead. Now a history edit is a red build rather than a support ticket six weeks from now.
4. Migrate the patterns, do not just suppress them. Anthropic shipped replacements for each one, and they are better designs than the edits they replace:
- Rebuilding
systemeach request becomes a mid-conversationrole: "system"message appended at the point where the new instruction becomes true. It carries system-prompt authority and needs no beta header on Fable 5.1. - The per-turn nudge you inject and then delete becomes a turn-scoped system message with
clear_at: "next_user_message". Leave the old copies in place; a cleared one renders nothing and costs no input tokens, but it stays in the array so the thinking after it stays valid. - Editing
toolsbecomestool_additionandtool_removalblocks against a full tool set declared at session start, withdefer_loading: trueon anything not yet available.
5. Store and replay assistant turns verbatim. Keep the content array from each response and send it back unchanged, every block type in the order received, including thinking blocks whose thinking field is empty. Do not reserialize through an intermediate type that drops unknown block types or blank fields. That single habit prevents most of this.
Honest limitations
This does not touch most people. Claude Code, Claude Cowork, claude.ai, Claude Managed Agents, the Claude Agent SDK, and third-party products that wrap Claude all keep the prefix intact for you. Models other than Fable 5.1 are unaffected today. If you have never written a messages array by hand, you can stop reading.
drop_block is an escape hatch, not a fix. The request goes through, but the model answers without seeing the reasoning it produced earlier, and the dropped block takes every thinking block after it. You have traded an error for a silent quality change. Log the transformations or you will never know it happened.
The efficacy claim is unfalsifiable from the outside. Anthropic says this makes distillation campaigns harder to execute. There is no published number attached, no before-and-after on detected campaigns, nothing an independent party could check. It is a plausible mechanism and an unmeasured one, and it is worth saying so plainly on a launch where almost everything else came with a footnote and a standard error.
The phased rollout is a real concession, and it is also the part that creates the trap. If enforcement had landed for everyone at once, harness maintainers would have found out in an hour. Splitting by account age means the people best positioned to fix the problem are the least likely to encounter it.
What this actually changes
Account creation date is now a deployment variable. It sits next to region, tier, and model name on the list of things that determine what an identical request does, and it is the only one on that list you cannot change after the fact.
That is a small thing on its own. It is less small alongside the rest of this launch, where Mythos 5.1 runs the same weights as Fable 5.1 with different safeguards depending on whether you have been vetted into a program, and where Enterprise Frontier Safeguards decides where your logs live based on who your organization is. The control surface keeps moving off the model and onto the account.
So the question I would put to anyone shipping an agent harness this week: what else in your stack behaves differently depending on when the credential was provisioned, and how would you find out? Run the drop_block test against your own integration today. It costs one request, and it is the only way to see the failure your users are already seeing.
Sources: Introducing Claude Fable 5.1 and Claude Mythos 5.1, Preserved thinking documentation, Anthropic Help Center: Preserved thinking.