In this analysis
Preserved thinking is versioned conversation state whose validity can change after a model switch or an earlier edit.
Reasoning history became versioned state
The June 9, 2026 Fable 5 and Mythos 5 release preceded Opus 5’s July 24 release record. The September 1 release notes then introduced the next Fable generation. Its compatibility documentation restricts which models can read preserved thinking and notes that editing earlier turns invalidates those blocks. The architectural consequence is that a conversation contains state whose portability cannot be inferred from the readability of its surrounding messages.
Visible text and reusable state are different
An application can display a transcript while still being unable to replay all of its internal blocks with another model. Treating every stored element as ordinary portable text encourages a misleading migration strategy: change the model identifier and resend everything. The appropriate question is which parts of the history remain valid under the destination contract. This does not require exposing private reasoning to users. It requires the orchestration layer to recognize that stored conversation material can carry model-specific validity conditions separate from the visible task description.
Editing creates a dependency problem
Consider an illustrative analysis in which a user corrects the specification after an earlier reasoning step. The old reasoning may have depended on the incorrect specification even if the correction seems small. Reusing it as though nothing changed confuses continuity with consistency. A robust migration policy therefore treats the corrected conversation as a new dependency state. The exact reconstruction method must follow supported documentation; the general causal point is that changing a premise can invalidate derived state without making every visible message irrelevant.
A replay matrix reveals the boundary
A useful fixture compares continuation on the same supported model, continuation after a model switch, and continuation after an earlier user message is edited. Each case records the history representation and whether the API accepts it, alongside the supported user-facing result. An acceptance failure should be distinguished from a poor substantive answer. This is a proposed test matrix, not a measured compatibility result. It prevents a failed replay from being misclassified as a model-quality regression and makes the recovery policy reviewable before a real conversation depends on it.
Migration is more than selecting a name
The release illustrates why version upgrades can require a state migration even when the application uses the same conversational interface. A fallback path needs a supported way to continue the task, rather than an assumption that all hidden history transfers unchanged. Product naming alone cannot establish that path. The safe conclusion is limited but practical: identify nonportable state, preserve the visible task faithfully, and test continuation boundaries explicitly. Compatibility should be demonstrated at the stored-history level, not inferred from a successful fresh prompt.