Anthropic’s documentation has a section for libraries, proxies and gateways. It says a gateway’s own rewrites count as edits, and that its callers can neither see nor fix them. With Fable 5.2 preserved thinking, three ordinary things a gateway does can trip the check: rewriting messages, switching models, spreading conversations across accounts.

On replay, the API checks each thinking block against the exact history before it, the model reading it and the account sending it, and with this release the first check applies to every account on the Claude API. My answer is a gateway that appends and never rewrites, and that chooses the model and the account once per conversation. What follows reads the documentation of 2026-11-09, the release day; I have not run the model behind a gateway.

What does Fable 5.2 preserved thinking check?

A thinking block that Fable 5.2 returns is valid only when it comes back after the same top-level system prompt, tools and earlier messages, to a model that can read it, from the account that produced it. Anthropic’s Preserved thinking page describes three bindings that fail differently.

A block is bound to What breaks it What the API does
The prefix: system, tools and every message before the block Any edit to them between two requests Returns a 400, unless the request asks for drop_block
The model A later turn sent to anything other than Fable 5.2 or Mythos 5.2 Drops the block; the request succeeds
The account A replay from an account not linked to the first Drops the block; the request succeeds

Each drop appears in input_transformations, a response field sent only with the thinking-binding-controls-2026-08-01 beta header, under the reason prefix_binding_mismatch, model_binding_mismatch or organization_binding_mismatch. Without the header, the model and account drops are silent.

What changed on the Claude API is who gets the error. According to What’s new in Claude Fable 5.2, Fable 5.1 returned it by default only on accounts created on or after 2026-08-31, and Fable 5.2 returns it whatever the account’s age. A gateway on an older account that edited histories on Fable 5.1 without one complaint can fail after the move. The message says “The block is bound to a different conversation”, and the migration guide adds that a retry does not clear it.

Amazon Bedrock is described differently: the AWS page gives a default 400 with no account-age condition and already lists Fable 5.1 among the models that run the check. By that page, the news on Bedrock is the other two rows of the table.

I would not wait for this to loosen. Anthropic’s announcement presents preserved thinking as a guard against people who edit the model’s earlier context to extract its reasoning.

The check only bites when assistant turns that contain thinking are sent back. A first turn has nothing to replay, so single-shot classification is untouched.

What does a gateway do that counts as an edit?

The API compares what the gateway sent upstream last time with what it sends now. A gateway that renders the date or a prompt variable into system or the first user message sends a different prefix as soon as the value moves; LiteLLM’s page on prefix stability lists a changed variable or a new prompt version as breaking by design. A policy reminder added to a user turn and later removed or reworded is an edit. Moving a mid-conversation role: "system" message into the top-level system field invalidates every thinking block in the conversation.

Adding, removing, renaming or editing an entry in tools is an edit too, on every model that runs the check. Per-tenant tool filtering is safe only while its result stays constant, and a gateway that writes an MCP server’s tools into tools edits the prefix whenever the server’s list changes. The Fable 5.2 difference is narrower: with the Claude API’s own MCP connector, the migration guide says an unpinned tool list that changes between requests is an edit for Fable 5.2’s blocks where it was not for Fable 5.1’s. Pin it. To turn tools off for one request, send tool_choice: {"type": "none"}.

Then there is the housekeeping nobody thinks of as editing: summarising older turns on the client while keeping recent ones with their thinking, rebuilding a saved session from templates, a serializer that drops block types it does not know or reorders blocks.

One serializer fault is worse, because nothing fails. On these models a thinking block’s text is empty by default and its signature carries the reasoning. On that default, a serializer that skips empty blocks removes them all; the request succeeds and the model loses its earlier reasoning on every turn.

Appending is safe. So is changing effort, max_tokens, tool_choice, metadata or cache_control markers.

LiteLLM documents its Presidio masking as stable: each message is masked on its own, with deterministic replacements. The design I published applies Bedrock Guardrails to every text-generation call, and nothing in the pages I read says whether Guardrails masking changes what the prefix check compares. I would assume neither answer and test it.

I would make every transformation the gateway applies a function of the message alone, with nothing read from the clock or from configuration at request time. Failing that, apply it once and let the stored history hold the result. A reworded policy line then stops reaching conversations already open, a loss for whoever wanted it live everywhere at once. It reaches the next conversation, or arrives as an appended message.

What happens when the gateway switches models?

Only Fable 5.2 and Mythos 5.2 read Fable 5.2’s thinking blocks. Any other model, Fable 5.1 included, answers a later turn without that reasoning. The API drops the blocks without an error; the migration guide warns that the next turn can cost more and take longer. A refusal fallback is such a switch: the permitted targets, Claude Opus 4.8 and Claude Opus 5, do not read the blocks.

The API never edits your messages, so the dropped blocks are read again if the conversation returns to Fable 5.2. They are lost for good only if the gateway strips them. Do not strip them.

My own gateway guide says products ask for a capability, never a model, and that a model change is a table change. With Fable 5.2 the product notices the table change, on the first turn after it.

For Fable 5.2 I would resolve the capability to a model once, when the conversation starts, and keep that choice with the conversation. A fallback in the middle stays possible, as an exception the gateway logs with its reason, because somebody will ask why that turn got slower. Pinning costs twice. Conversations in flight stay on the old model until they end, so a roll-out takes longer. And a gateway that kept no state per conversation now has to keep some.

And across accounts?

Fable 5.2’s blocks work only in the account that produced them or an account linked to it; the page does not define “linked”. On Amazon Bedrock the AWS page names the unit: the same AWS account, or an account in the same customer group.

Nothing in my published work spreads one conversation across accounts. Gateways that do, for failover or because each product has its own account, have to send every conversation back through the account that produced it. Failing over mid-conversation loses the reasoning as quietly as a model switch.

How do you find the edits before production does?

Forward the caller’s anthropic-beta values and thinking.block_binding unchanged, and return input_transformations; on the Converse API, AWS says to pass both through additionalModelRequestFields. Its page does not say where a Converse response carries input_transformations, so check that yours surfaces it. Anthropic warns that an options schema which rejects unknown keys stops callers from choosing drop_block. The contract I published lists input and output schemas; if the gateway validates them strictly, I would name the field in the contract. Then, in staging:

  1. Send the beta header with prefix_mismatch_behavior: "error" and run three turns with one tool call through the gateway. Every turn succeeds and input_transformations comes back empty.
  2. Capture what the gateway sends upstream for turn one, then the same span inside the request for turn three. They are identical apart from cache_control markers.
  3. Force a fallback to another model in the middle. Expect model_binding_mismatch entries; record that turn’s output tokens.
  4. Replay a stored conversation through a second account. Expect organization_binding_mismatch entries.
  5. Put a fake email address in turn one with Guardrails masking on and run three turns under drop_block. If a prefix_binding_mismatch entry appears, mask before the message is stored.

In production I would part from Anthropic’s default. Its guidance is to keep "error" when a mismatch can only mean a bug in your own code, and it documents a narrower way out than drop_block on all traffic: after a 400, retry once with drop_block and store that choice with the session. In a gateway I would make that narrow route the default for callers that send no block_binding; a caller’s own value wins. A gateway sits in front of code it does not own, and a stored history containing an edit keeps failing after the bug is fixed.

Anthropic’s advice to alert on every prefix_binding_mismatch entry applies as written, and I would put an end date on the default. The price is more output tokens, a prompt cache that restarts at the first dropped block and, Anthropic warns, answers that may change where later turns build on earlier reasoning. Mute the alert and nobody hears about the mismatch. Whatever the gateway does for a caller after a 400, it should log.

In practice

On the ENSO platform, I designed a central AI gateway as the single access path to Amazon Bedrock, with EU-only inference profiles enforced organisation-wide via SCP, Guardrails PII filtering, and model routing that isolates products from the model lifecycle. The gateway is one part of a shared, multi-tenant platform that powers four product capabilities; the full architecture is in the ENSO case study, and gateways of this kind are part of the enterprise LLM platform service.

The capability table still isolates products from the model lifecycle between conversations. Within one it no longer does: a Fable 5.2 conversation stays on its model or loses reasoning. The guide’s fallback is another EU profile or another model; the model case is a switch of this kind, and I would log it as lost reasoning. What moving to another EU profile of the same model does to the blocks, I have not seen documented.

Trade-offs and limits

This article reads documentation dated 2026-11-09. I have not run Fable 5.2 behind a gateway and have measured none of the costs named here. The pages will change, and enforcement and account binding are described per platform, so read yours.

Pinning buys nothing for a gateway whose traffic is mostly single-turn, and drop_block can hide a bug for as long as nobody reads the alert. Append-only suits a thin gateway, but it rules out changing a prompt for everyone at once. The golden set that gates a model swap is made of single questions, so no case contains a mid-conversation switch and I would not count on it to catch reasoning lost on one.

Common questions

Does Fable 5.2 return a 400 for an edited history on every account?

On the Claude API, yes, when the request replays a Fable 5.2 thinking block and leaves prefix_mismatch_behavior unset. The account’s age no longer matters, where Fable 5.1 returned the error by default only on accounts created on or after 2026-08-31. For Amazon Bedrock, the AWS page gives a default 400 with no account-age condition.

Can an AI gateway switch from Fable 5.2 to another model in the middle of a conversation?

It can, and the request succeeds. Only Fable 5.2 and Mythos 5.2 read Fable 5.2’s thinking blocks, so any other model answers the later turns without that reasoning. The API drops the blocks without an error and does not bill them.

What does drop_block do, and should I leave it on?

With the beta header, prefix_mismatch_behavior: "drop_block" makes the API drop the failing block and every later thinking block, answer anyway, and list each drop in input_transformations. Anthropic calls it a stopgap and advises alerting on every prefix_binding_mismatch entry. In a gateway I would set it per session, after a first 400.

Sources

All read on 2026-11-09.