Claude Fable 5 Hybrid Reasoning: Thinking vs. Speed Modes

Anthropic’s new Claude Fable 5 reasoning engine keeps deep thinking switched on for every request and lets developers dial reasoning depth up or down instead. Historically, Large Language Models (LLMs) operated on fixed compute parameters, generating tokens at a uniform speed regardless of query complexity. Simple greetings consumed the same processing energy as advanced maths proofs. With Fable 5, Anthropic introduces a hybrid reasoning framework where thinking is always active and you control how hard the model works through a single effort setting. This tutorial outlines how the API works, how to choose an effort level, and how to implement this architecture in production pipelines.

[!WARNING] API Constraint Warning: Thinking is always on for Fable 5, so you cannot switch it off. Passing thinking: {type: "enabled"} or thinking: {type: "disabled"}, or supplying a budget_tokens value, returns an HTTP 400 error — those parameters were removed. Control reasoning depth with output_config: {effort: "..."} instead, and leave enough of your max_tokens for the final answer at higher effort levels.

Key Takeaways:

• Dial Effort, Not Toggles: Set output_config.effort to low, medium, high, xhigh or max — there is no on/off switch.
• Thinking Is Automatic: Omit thinking or pass {type: "adaptive"}; adaptive thinking runs on every request.
• Parse Streams: Handle thinking content blocks with thinking_delta deltas in real-time server streams.
• Manage Billing: Caching system prompts reduces redundant thinking processing cycles.

Explaining Claude’s Hybrid Reasoning Engine

The core innovation of Fable 5 is its ability to think through a problem before outputting the final answer. This means the model works through a logical draft of the solution internally before responding to client requests. Crucially, this thinking phase is always on — you cannot turn it off, and there is no separate “speed mode” you switch into.

When you submit a complex question, the model does not attempt to predict the next word immediately. Instead, it generates internal thinking tokens, simulating a step-by-step reasoning process. This architecture drastically improves accuracy for maths, coding, and logical evaluation.

To support different enterprise requirements, Anthropic lets developers scale the depth of that thinking on-demand through a single effort control. At low effort the model thinks briefly and answers fast, keeping latency and token spend down. At high or max effort it reasons much more deeply, spending the extra compute needed for hard maths, multi-step logic, and complex code. The speed-versus-depth trade-off is expressed entirely through this effort level rather than an enable/disable toggle.

Configuring Fable 5 API Parameters

To implement these capabilities in your software, you must use the updated Anthropic API schema. This schema ensures your client applications specify the correct model name and execution parameters.

Reasoning depth is set through an output_config block. Within it, the effort field accepts one of "low", "medium", "high", "xhigh" or "max", and that single value replaces the old token-budget dial. You do not pass a thinking block at all in the simple case — adaptive thinking runs automatically. The JavaScript integration below demonstrates how to structure this request:

 1import Anthropic from "@anthropic-ai/sdk";
 2
 3export default {
 4  async fetch(request, env) {
 5    const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
 6
 7    try {
 8      const response = await anthropic.messages.create({
 9        model: "claude-fable-5",
10        max_tokens: 8192,
11        // Thinking is always on for Fable 5; dial reasoning depth with effort:
12        output_config: { effort: "high" }, // "low" | "medium" | "high" | "xhigh" | "max"
13        messages: [
14          {
15            role: "user",
16            content: "Generate an optimised database migration script for 10 million records."
17          }
18        ]
19      });
20
21      return Response.json(response);
22    } catch (err) {
23      return Response.json({ error: err.message }, { status: 500 });
24    }
25  }
26};

Do not try to disable thinking or pass a budget_tokens value: thinking: {type: "disabled"}, thinking: {type: "enabled"} and any budget_tokens field all return an HTTP 400 on Fable 5, because those parameters were removed on this model (and on Opus 4.7 and 4.8). Choose a lower effort level for speed and a higher one for depth, and leave enough headroom in max_tokens for the final answer when you push effort up. For details on serverless architectures, read our guide on building a serverless API with Cloudflare Workers .

Handling Reasoning Tokens in Streams

For real-time applications like chat interfaces, streaming responses is essential. Fable 5 outputs both thinking steps and final content via SSE (Server-Sent Events) channels.

During a stream, thinking arrives as thinking content blocks, delivered through content_block_delta events whose delta.type is "thinking_delta". Read the text from delta.thinking, and read the final answer from the usual text_delta deltas. The raw chain-of-thought is never returned — to receive a readable summary you must opt in with thinking: {type: "adaptive", display: "summarized"}; the default "omitted" streams empty thinking text. A minimal handler looks like this:

 1const stream = await anthropic.messages.stream({
 2  model: "claude-fable-5",
 3  max_tokens: 8192,
 4  output_config: { effort: "high" },
 5  thinking: { type: "adaptive", display: "summarized" },
 6  messages: [{ role: "user", content: prompt }]
 7});
 8
 9for await (const event of stream) {
10  if (event.type === "content_block_delta") {
11    if (event.delta.type === "thinking_delta") {
12      process.stdout.write(event.delta.thinking); // summarised reasoning
13    } else if (event.delta.type === "text_delta") {
14      process.stdout.write(event.delta.text);      // final answer
15    }
16  }
17}

You can pipe those thinking_delta chunks into a collapsible “Thinking…” panel, or drop them and render only the answer. For a detailed reference on Anthropic integrations, refer directly to the Anthropic Developer Documentation .

Manage your token accounting carefully. Thinking tokens count toward your output API billing. Therefore, implement aggressive prompt caching to avoid re-running reasoning cycles on identical inputs. When planning a production deployment, tracking these metrics via an edge telemetry layer helps you identify where thinking-token usage exceeds typical parameters.

Step-by-Step API Integration Workflow

To implement the reasoning engine inside your applications, start by updating your local packages to align with Fable 5 specifications. Older SDK versions still send budget_tokens, which now triggers HTTP 400 schema errors during API serialisation.

Next, define clear latency thresholds. For simple conversational flows or greetings, set a low effort level to keep latency down. Reserve high or max effort for tasks like code generation or maths.

Additionally, store your API credentials securely inside your serverless environment parameters using tools like Wrangler. When handling stream output events, write robust frontend handlers to filter out thinking_delta packets. This is necessary unless you intend to display the model’s reasoning steps directly. Finally, audit prompt cache hit ratios to confirm caching minimises token consumption overhead. To learn about edge API designs, explore our Cloudflare Workers AI tutorial .

Low Effort vs. High Effort at a Glance

Choosing an effort level is a trade-off between latency, cost and answer quality. The table below compares the dimensions that matter most when you are sizing a request. The latency and throughput figures are illustrative and will vary with prompt length, load and region, but the relationships between them hold.

The essential point is that thinking tokens are real output tokens. A low-effort request thinks briefly and bills mostly for the answer it writes; a high- or max-effort request can generate a large volume of thinking tokens before the first word of the response even appears. Thinking is never off — you are only choosing how much of it to spend.

When to Use Each Effort Level

A practical approach is to map each task type to a default effort level, then override only when a specific request clearly needs more headroom. Reserve high and max effort for problems where a wrong answer is expensive to catch downstream.

Choose a low effort level when the response is short and largely deterministic, when time-to-first-token drives the user experience (live chat, autocomplete, form assistants), or when you are running a high-volume, low-margin workload where every extra output token multiplies across millions of calls.

Choose a high or max effort level when a single wrong answer carries real cost — a broken migration script, a miscalculated quote, an insecure code path — or when the task involves several dependent steps the model must hold together. These are the workloads where a few seconds of extra latency buys a meaningful jump in reliability.

Worked Example: Latency and Cost Trade-offs

Consider a support assistant handling 50,000 requests per day. Assume each final answer is about 250 tokens, that a low effort level adds only a handful of thinking tokens, and that a high effort level consumes roughly 1,500 thinking tokens on a typical hard query. Every token price below is illustrative — treat it as a modelling exercise rather than a quote — and assume an output rate of $15 per million tokens.

Running every request at low effort produces roughly 50,000 × 250 = 12.5M output tokens per day, or about $188 per day at the illustrative rate. Running every request at high effort instead bills 50,000 × (1,500 + 250) = 87.5M tokens per day, roughly $1,313 per day — seven times more, most of it spent reasoning through queries that never needed the extra depth.

Now route selectively. Suppose a cheap low-effort classifier decides that only 15% of traffic is genuinely complex. Sending 7,500 requests to high effort and 42,500 to low effort gives 13.1M + 10.6M ≈ 23.7M tokens per day, about $356 per day — a ~73% saving against running everything at high effort, while still applying deep reasoning where it earns its keep.

The latency picture mirrors this. At low effort the first token typically appears in well under a second. At high effort the model generates a much larger reasoning draft before the answer begins, so a 1,500-token internal draft at an illustrative 60 tokens per second delays the visible response by roughly 25 seconds. Streaming the thinking_delta blocks into a collapsible “Thinking…” panel is what keeps that wait tolerable for the end user.

Migration and Total Cost of Ownership

If you are moving from a fixed-compute model, the biggest shift is that reasoning depth is now a dial you set per request rather than a flat rate you pay on every call. The largest lever on your bill is not the effort level of any single call but the routing layer that decides which requests deserve a high effort level at all. A lightweight low-effort classification call — a few hundred tokens — that gates the expensive high-effort call almost always pays for itself.

Two habits keep total cost of ownership predictable. First, set the lowest effort level that reliably solves each task class rather than a generous global default; a max effort level applied everywhere is the most common source of surprise invoices. Second, cache stable system prompts so repeated context is not re-billed on every reasoning cycle. Together, per-request routing and prompt caching push the majority of spend onto the minority of requests that genuinely benefit from it.

Key Takeaways

• Fable 5 (claude-fable-5, 1M-token context, 128K max output) keeps thinking always on; you scale its depth rather than toggling it.
• Configure reasoning depth with output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"}; budget_tokens and thinking.type “enabled”/“disabled” now return HTTP 400.
• Stream thinking via thinking content blocks (thinking_delta deltas) to display the model’s steps to end users, opting in with thinking: {type: "adaptive", display: "summarized"} for a readable summary.
• Control API billing costs by choosing the lowest workable effort level and caching frequently used prompts.
• Deploy your API middleware on serverless edge networks to reduce transit latency.

Frequently Asked Questions

What is claude fable 5 reasoning? Claude Fable 5 reasoning is an always-on capability where the model generates internal thinking tokens to solve complex logical problems before outputting the final response. Rather than attempting to guess the next word immediately, the network simulates a step-by-step thinking process to resolve architectural, mathematical, and coding errors, and you scale how deeply it thinks with the effort setting.

How do I configure the reasoning effort in the API? You configure reasoning depth by passing output_config: { effort: "low" | "medium" | "high" | "xhigh" | "max" } inside the API request payload. A lower effort level thinks briefly and answers faster for fewer tokens, while a higher level reasons more deeply. The old budget_tokens parameter has been removed and now returns an HTTP 400 error on Fable 5.

Are reasoning tokens billed differently? No, reasoning tokens are billed at the standard output token rate of the model. Because these tokens represent output compute, they count directly towards your API billing, making prompt caching and a sensible effort level essential to control software expenses.

How do I make Fable 5 respond faster? You cannot disable reasoning — thinking is always on for Fable 5, and passing thinking: {type: "disabled"} returns an HTTP 400 error. To reduce latency, lower the effort level with output_config: { effort: "low" }, which shortens the thinking phase and minimises time-to-first-token for basic conversational tasks.

How do I parse reasoning tokens from a SSE stream in real-time? During serverless SSE streaming, thinking arrives as thinking content blocks through content_block_delta events whose delta.type is thinking_delta; read the text from delta.thinking, separate from the standard text_delta output. Opt in with thinking: {type: "adaptive", display: "summarized"} to receive a readable summary, then render or discard those tokens based on frontend UI preferences.