Claude Fable 5.1 changes tool calls, thinking blocks and caching with no code change required

Behaviour shifts that need no code change

Anthropic shipped Claude Fable 5.1 on 1 September, and a practitioner post on dev.to by SharpHaw argues that the most useful part of the release sits below the benchmark tables: a list of behaviours that changed even though developers did not touch their code.

According to that write-up, the documented differences from Fable 5 include more variable parallel tool calling. In coding and computer-use loops, the model may issue a single tool call per turn even when several reads are implied, keeping answer quality but adding round trips. Long tool runs at higher effort emit fewer progress updates, so an interface can sit quiet for minutes. At low effort the model answers from memory more often and calls search and retrieval tools less. Prose comes out denser with less chat formatting, document summaries are more likely to reproduce passages without marking them as quotations, and small edits are more likely to arrive as full-file rewrites.

Breaking changes for Fable 5 callers

Two changes break existing integrations outright, per the post. Forced tool use is gone: setting tool_choice to "any" or a named tool now returns a 400 error. Thinking blocks are also bound to the conversation that produced them. For accounts created on or after 31 August 2026, replaying a thinking block after anything earlier in the request was edited, such as the system prompt, the tool list or a prior message, fails with a 400 unless the caller opts to drop the block. The notes, as reported in the post, say future models are expected to enforce this for everyone, which makes append-only conversation history the safe default.

Cache reads get much cheaper

Input and output pricing is unchanged, but cache reads dropped to a quarter of the previous rate. Anthropic frames this as roughly 25% cheaper for typical work and up to 45% cheaper for agentic loops that repeatedly re-read the same context.

A triage list: what to delegate and what to hold back

The author sorts work by one question: what does a wrong answer cost, and who catches it first. On the delegate side: the years-old bug (the launch materials quote a customer named Millennium tracing a one-in-a-million crash to a vendor library, and the notes claim the model now fixes root causes, checked by a failing test first and a human reading the diff); multi-file refactors that run for hours on a disposable branch; sourced research memos run at high effort with search on, a citation beside every claim and three random spot-checks; document reads focused on the clauses that bind and decide ownership; and single-user internal tools.

Held back: anything that sends, posts or pays on its own. The post quotes Anthropic's small-business packaging line, "you approve before anything sends, posts, or pays", and argues that line does not move just because the model got smarter. Also held: facts you would act on that came back at low effort, since a quick answer between meetings can be confidently out of date (the default effort is high in Claude Code but medium in Cowork and on claude.ai). And customer data stays out until retention terms are written down, because the zero-retention Enterprise Frontier Safeguards arrangement only arrives in phases from this autumn for enterprise customers, and the safeguard classifiers read everything the model reads, including files and connected tools.

Two harness fixes to make now

First, keep the message array append-only and use turn-scoped system messages, setting clear_at to next_user_message under the mid-conversation-system-clear-at-2026-08-21 beta, instead of injecting and deleting text. Anthropic positions this nudge as its mitigation for the one-call-per-turn behaviour; cleared copies cost no input tokens and do not invalidate the cache.

Second, opt into visible progress. Under the default thinking.display of "omitted", progress blocks come back empty; requesting "updates" via the thinking-display-updates-2026-08-18 beta turns each non-empty thinking block into a status line you can show the user.

The post closes with plan mechanics: on Max and premium Team seats, Fable models draw up to half the weekly usage limit and burn it faster, while Pro and standard seats run on credits from the first message. Anthropic says medium effort on 5.1 roughly matches Fable 5 at full effort, so the effort dial matters more than the model picker.

Fittingly, the post discloses it was itself drafted by Fable 5.1 inside the author's publishing pipeline: the review pass caught the model compressing "four to five years" into "four years" and writing a sentence its own style guide bans, both behaviours from the caution list, surfacing inside a post about that list.

Why it matters

Model upgrades now ship with behavioural drift that breaks systems at the prompt and conversation level, not the code level. Teams that treat prompts and message history as stable contracts get hard 400 errors or quiet regressions with no code diff to review. The triage pattern in the dev.to post, ranking tasks by blast radius and keeping autonomous actions behind human approval regardless of capability, is a workable governance template as releases outpace harness rewrites. And with cache reads at a quarter of the old price, long agentic loops just got materially cheaper, which will encourage exactly the unattended workloads the caution list is about.