A model upgrade is not a drop-in for your agent loop
Most teams treat a Claude ".1" as a model-id swap. Fable 5.1 is where that habit breaks production agent loops.
Three changes that look small in the release notes and large in your code path:
- Forced tool choice is gone. tool_choice=any or a named tool now returns HTTP 400. Use auto or none, then enforce schema in your own layer.
- Thinking blocks are model-specific. Route backward to an older model and the reasoning payload can be dropped or rejected. Routers that blithely replay history across models need a test, not a hope.
- Editing earlier turns can invalidate thinking blocks. Append-only histories (or a supported compaction pattern) survive. Mutating prior messages does not.
Consequence: the upgrade cost is not the sticker price. It is a 30-minute audit of tool_choice, multi-model routing, and history mutation before you move traffic.
I wrote the audit checklist here (friend link):
https://levelup.gitconnected.com/claude-fable-5-1-every-breaking-change-in-your-agent-loop-9be40b5fe787?sk=89d27a4f27b2c93ddbb9e4e0f3b696fe
The 400 is the trap. Catch it, then retry inside the same transcript, and that retry is what poisons the thinking block. On a tool error I dump the turn and start clean. One golden trace per tool, run on both model ids before you move traffic. The last token can look fine while the middle call already drifted.
I would treat the model id as part of the contract, not a config knob. In our internal agent loops, the useful check is a small replay suite of real traces: tool choice, history compaction, and one failed run that must stay failed for the same reason. If that changes, the upgrade needs a canary instead of a straight swap.
This is a good point. Model upgrades can change the behavior of the whole agent loop, not just improve the model itself. The tool calling and history handling issues are especially easy to miss if you only test the final output.