Claude Fable 5 keeps thinking always on and replaces toggles with a five-level effort dial

Anthropic's Claude Fable 5 removes the switch developers previously used to turn model reasoning on or off. According to a tutorial published on dev.to, the new reasoning engine keeps an internal thinking phase active for every request, while depth is scaled through a single effort setting that accepts five levels: low, medium, high, xhigh and max.

The post frames the change against how large language models have historically behaved: with fixed compute parameters, a trivial greeting and a demanding math proof consumed roughly the same processing. Fable 5's hybrid approach keeps a reasoning pass in the loop at all times, but lets the caller decide how much of it to buy, trading latency and token spend against answer quality on a per-request basis.

How the effort setting works

Reasoning depth is set through an output_config block containing an effort field. Low effort produces brief thinking and fast responses suited to conversational traffic; high and max effort push the model into deeper reasoning for multi-step logic, code generation and hard math. According to the tutorial, this single value replaces the older token-budget mechanism, and there is no separate fast mode or enable flag. In the simple case, no thinking block is passed at all, because adaptive thinking runs automatically on each call.

Breaking changes for existing integrations

The migration path is not silent. The tutorial warns that passing thinking: {type: "enabled"}, thinking: {type: "disabled"}, or any budget_tokens value now returns an HTTP 400 error on Fable 5, because those parameters were removed — reportedly on this model and on Opus 4.7 and 4.8 as well. Older SDK versions that still serialize budget_tokens fail against the updated schema, so updating packages is a prerequisite.

There is also a capacity consideration: at higher effort levels, developers need to leave enough headroom in max_tokens for the final answer, since thinking consumes part of the output budget.

Streaming behavior

For real-time interfaces, Fable 5 delivers both thinking steps and final content over Server-Sent Events. Thinking arrives as thinking content blocks inside content_block_delta events where delta.type is "thinking_delta", with text read from delta.thinking; the answer itself arrives through the usual text_delta events.

The raw chain-of-thought is never exposed. By default the display option is "omitted", which streams empty thinking text. Opting in with thinking: {type: "adaptive", display: "summarized"} returns a readable summary that can be piped into a collapsible UI panel or discarded by the frontend.

Cost and production considerations

Thinking tokens are billed as output, which changes the economics of high-volume APIs: every request now carries at least some reasoning overhead. The tutorial recommends aggressive prompt caching to avoid re-running reasoning cycles on identical inputs, auditing cache hit ratios, and tracking thinking-token usage through telemetry to spot where consumption exceeds expectations.

The suggested workflow from the post: update SDK packages first, define latency thresholds per use case — low effort for greetings and simple flows, high or max for code and math — and filter thinking_delta packets in frontend handlers unless the reasoning steps are meant to be displayed.

Why it matters

The shift from a binary toggle to a graduated effort dial reframes how teams budget LLM compute. Instead of deciding whether a request should think at all, they decide how much thinking each request is worth — and because thinking cannot be disabled, even lightweight endpoints inherit reasoning costs, making prompt caching and effort routing first-class design concerns rather than afterthoughts.

It also signals an API direction: with budget_tokens removed from Fable 5 and, per the tutorial, from Opus 4.7 and 4.8, effort-based control appears to be the forward pattern for Anthropic's models, and pipelines built around explicit thinking toggles will need rework. One caveat: these details come from a single developer tutorial on dev.to rather than Anthropic's official documentation, so teams should verify specifics against the API reference before migrating.