# Claude Fable 5.1 Made Thinking History Append-Only for New API Accounts

**Summary:** Claude Fable 5.1 binds preserved thinking to the exact context that created it. New API accounts face the check first, so agent harnesses should use this grace period to test before future models extend the rule to everyone.

- Canonical: https://markhuang.ai/news/claude-fable-51-thinking-history-append-only
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-01
- Section: News
- Tags: Claude Fable 5.1, Claude API, AI Agents, API Compatibility, AI Security
- Source: [Anthropic](https://www.anthropic.com/claude-fable-and-mythos-5-1)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![A chain of glowing glass reasoning blocks held inside an amber lattice while a new block approaches the open end](https://cdn.markhuang.ai/news/claude-fable-51-thinking-history-append-only/hero.webp)

*Fable 5.1 treats preserved thinking as part of an immutable conversation prefix. New turns can join the chain, but changing what came before can break it.*

[Anthropic's Claude Fable 5.1 launch](https://www.anthropic.com/claude-fable-and-mythos-5-1) leads with benchmarks and pricing. Deeper in the page is an API change that could break an agent loop. For new API accounts created on or after August 31, 2026 at 00:00 UTC, the Messages API checks that earlier messages, tools, and the system prompt have not changed around a preserved thinking block. A mismatch returns a 400 error by default.

I think the security control makes sense, and the migration risk deserves equal attention. Agent harnesses often compact history, rebuild system prompts, or change tools during a session. These are ordinary product behaviors. With Fable 5.1, developers need to express them without rewriting the prefix that produced the model's earlier thinking.

The rule starts narrowly with new accounts using Fable 5.1 through the API and supported cloud platforms. Anthropic says existing accounts are not affected by this model. Future model releases will enforce preserved thinking for everyone. That grace period is time to test, before an old integration fails during the next model migration.

## The model launch also changed the conversation contract

Fable 5.1 has plenty of headline material. Anthropic reports 55.8% on Terminal-Bench 4.0, up from 42.0% for Fable 5, and says cache reads now cost $0.25 per million tokens. It also says the model is available across the Claude API, Amazon Web Services, Google Cloud, and Microsoft Azure under `claude-fable-5-1`.

But the anti-distillation change is the part I would put on an integration checklist. Anthropic's [preserved-thinking notice](https://support.claude.com/en/articles/16761192-preserved-thinking-changing-how-the-messages-api-handles-thinking-blocks-to-protect-against-distillation) says the API now verifies that a returned thinking block is paired with the same prior system prompt, tools, and messages that produced it. If the prefix differs, the developer has two choices: reject the request or opt into dropping the affected thinking blocks from what the model sees.

Dropping a block lets the request proceed with less context available to the model. The HTTP call may succeed even though the integration no longer behaves the same. Anthropic says the response reports which blocks were dropped, so that event belongs in logs and evaluation results.

```mermaid

flowchart LR
    A[Preserved thinking block] --> B{Earlier context unchanged?}
    B -->|Yes| C[Keep thinking and continue]
    B -->|No, strict mode| D[Return 400 error]
    B -->|No, drop mode| E[Remove affected thinking]
    E --> F[Continue with reduced context]
```

## Why bind the thinking block at all?

Anthropic describes the restriction as an anti-distillation measure. The concern is that someone can move an encrypted reasoning block into a modified conversation and induce a model to reveal the hidden reasoning in plain text. That would make it easier to collect reasoning traces at scale for training another model.

An August 2026 research paper, ["Stealing Reasoning Traces from Proprietary LLM APIs"](https://arxiv.org/abs/2608.09867), describes attacks that move encrypted reasoning blocks across sessions, users, or models. The authors report demonstrations involving Anthropic, OpenAI, and Google. After responsible disclosure, they proposed cryptographic and system-level mitigations. It is a new paper, so I would not treat it as a settled measurement of every production system. It does support the threat model behind binding a block to its original context.

The defense looks reasonable to me. A reasoning block created under one tool set should not be replayed under a different, potentially hostile set of instructions without a check. The practical question is whether the API can block that attack without making ordinary context management needlessly brittle.

## Ordinary harness behavior can now look like tampering

Anthropic's [developer documentation](https://platform.claude.com/docs/en/build-with-claude/preserved-thinking) gives the compatibility boundary in unusually practical terms. Direct API integrations should treat the message array as append-only. Trimming old turns, replacing them with a client-side summary, injecting and later removing a reminder, rebuilding a system prompt with the current time, or changing the tool list can invalidate later thinking blocks.

The platform offers supported alternatives. Server-side compaction can shorten the working context, while new message types can carry updated instructions and tool changes without rewriting earlier bytes. The resulting conversation looks more like an event log. New state gets appended instead of quietly revising the record that produced the current state.

> **Info:**
>
> If a harness calls the Messages API directly, I would assume it needs inspection whenever it compacts context, changes tools, injects reminders, rotates dynamic system text, or routes a conversation between models.

There is an awkward rollout detail here. Anthropic warns framework maintainers that users supplying newly created API keys may encounter enforcement before the maintainer does, because the maintainer's own account is likely older. That can produce the worst kind of compatibility bug: customer reports that the developer cannot reproduce with the same code and model.

## I would make the future rule fail loudly in CI

Older accounts do not need to wait for automatic enforcement. The documentation says a request can opt into the binding check with the `thinking-binding-controls-2026-08-01` beta header and a `prefix_mismatch_behavior` setting. I would run representative multi-turn sessions through that path and choose the error behavior in CI. A hard failure exposes the first mutated prefix.

The test set needs the transitions that agent demos tend to skip. Cross a compaction boundary, change a tool, refresh a dynamic system value, exercise a model fallback, and run long enough for reminders to repeat. Request bodies should be compared through the shared prefix. If production uses drop mode, the `input_transformations` field should be logged and counted because a successful HTTP response can still mean the model lost earlier thinking.

The test also needs to represent a fresh customer organization. The current rule covers new Claude Platform organizations and Amazon Bedrock accounts, plus new Google Cloud Vertex AI and Microsoft Azure Foundry projects created after the cutoff. Claude Code, Claude Cowork, Claude.ai, third-party products, and models other than Fable 5.1 are outside this specific enforcement scope.

## The security fix should be treated as an API migration

Early [public launch discussion](https://www.reddit.com/r/ClaudeAI/comments/1w4juj2/introducing_claude_fable_51_and_claude_mythos_51/) is mostly about benchmark gains, cheaper cache reads, and whether subscription users share the savings. Those are fair questions. For teams that own an agent loop, preserved thinking is more likely to turn the upgrade into an integration failure.

Anthropic has a concrete reason to stop reasoning blocks from moving freely between rewritten conversations. The new API also offers migration mechanisms instead of banning long conversations. Even so, the control changes what counts as a valid conversation. Developers should treat it as an API contract.

Fable 5.1 gives new accounts the rule and old accounts the warning. My response is straightforward: keep history append-only where possible, put dynamic state in the supported message types, and test the rejection path while enforcement is still optional for older accounts. A future model will make the rule universal.