A history serializer can remove the same kind of block in two places and get different validity outcomes. For a Fable 5.1 migration through CometAPI, that makes “we trim old reasoning” too vague an acceptance criterion.
Anthropic’s breaking-change documentation distinguishes removing an oldest-first leading run of thinking blocks from removing a thinking block in the middle. The former keeps later blocks valid; the latter invalidates every thinking block after the removal. This is not permission to delete whole early messages: the same documentation says editing, reordering, or removing an earlier turn can invalidate later thinking blocks.
Choose the route before testing the serializer
CometAPI’s September 4 access and migration article lists claude-fable-5-1 through both Anthropic-compatible /v1/messages and OpenAI-compatible /v1/chat/completions. It also calls for context-handling evaluation before migration.
For an application that needs native thinking-block replay, I would qualify the CometAPI /v1/messages path first. That is a test design choice, not a claim that the route preserves every native field. Confirm the actual request/response representation before proceeding. A passing test through /v1/chat/completions would not establish the same replay behavior on /v1/messages, or vice versa.
Three copies, one controlled difference
Use a synthetic, non-sensitive multi-turn history with several native thinking blocks. Keep a protected original for comparison; do not reconstruct blocks from visible reasoning text. Pin the model, route, system prompt, tools, earlier messages, and referenced document bytes.
| Case | Serializer change | What the source lets us expect |
|---|---|---|
| Baseline | Replay the history unchanged | Control for whether this route can replay the original blocks at all |
| Leading removal | Remove only an oldest-first leading run of thinking blocks | Later blocks remain valid under the documented provider rule |
| Middle removal | Remove one non-leading thinking block, retaining later ones | Every subsequent thinking block is invalidated under that rule |
Do not mix message deletion, model fallback, or prompt rewriting into these cases. Those would obscure whether block position caused the difference. This is a proposed acceptance test, not a report of measurements.
A successful request is not enough evidence
Anthropic says prefix checking is enforced for new accounts created on or after August 31, 2026. For older accounts, it records the mismatch but acts on it only when the documented control is set. Where enforcement applies, replaying an invalidated block returns a 400 with The block is bound to a different conversation.
That account distinction is upstream documentation—not something to infer from the creation date of a CometAPI account. Nor does the CometAPI article establish support for the provider’s beta controls or transformation reporting. Do not add those parameters merely to force an observable result.
For the CometAPI route, record sanitized case identifiers, serializer diffs, status codes, and any documented indication of block handling. Avoid routine logging of full histories or thinking payloads. If all three requests succeed, do not conclude that middle removal is safe: native blocks may not have survived translation, or enforcement may not apply. Resolve that ambiguity before enabling the trim policy.
My rollout boundary would be: retain the original history, verify native replay on the selected CometAPI route, and enable leading-only removal only after the controlled cases support the intended behavior. If preservation or enforcement remains unclear, hold the migration rather than silently broadening the serializer’s deletion rules. This establishes a narrow history-integrity check, not a general safety or compliance guarantee.