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
Thanks for sharing the numbers, that makes it much easier to follow.
Thanks for writing this up. Bookmarking it for later.
Nice progress. What is the next thing you are focusing on?
Good point. Did you test that with users before committing to it?
This is the right framing — the cost is the audit, not the model id.
One habit that caught similar "looks fine in the last token" failures for us: keep a tiny golden-trace suite (one happy path, one forced tool error, one multi-model handoff) and run it on both ids before any traffic move. Treat a silent behavioral change in the middle of the loop the same as a breaking HTTP status.
Also +1 on dumping the turn after a tool 400 instead of retrying inside the same transcript. We learned that the hard way once.
Do you version the audit checklist alongside the agent code, or keep it as a runbook outside the repo?
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.