Anthropic 全新的 Claude Fable 5 推理引擎會為每一次請求保持深度思考（Thinking）常駐開啟，並改為讓開發者上下調整推理的深度。過去，大型語言模型（LLM）在固定的運算參數下運作，無論查詢多麼複雜，都以一致的速度生成 Token。簡單的問候與高深的數學證明消耗相同的處理能量。透過 Fable 5，Anthropic 引入了一套混合推理框架：思考永遠處於啟用狀態，而您透過單一的 effort 設定來控制模型要投入多少心力。本教學說明 API 的運作方式、如何選擇合適的 effort 等級，以及如何在生產流水線中實作此架構。
[!WARNING] API 限制警告： Fable 5 的思考永遠開啟，因此您無法將它關閉。傳遞
thinking: {type: "enabled"}或thinking: {type: "disabled"}，或提供budget_tokens值，都會回傳 HTTP 400 錯誤 —— 這些參數已被移除。請改用output_config: {effort: "..."}來控制推理深度，並在較高的 effort 等級下，為最終答案在max_tokens中保留足夠空間。核心要點：
- 調整 Effort，而非開關： 將
output_config.effort設為low、medium、high、xhigh或max—— 沒有開／關的切換。- 思考自動進行： 省略
thinking或傳入{type: "adaptive"}；自適應思考會在每一次請求時執行。- 解析串流： 在即時伺服器串流中，處理帶有
thinking_deltadelta 的thinking內容區塊。- 管理計費： 快取系統提示詞（prompt caching）可減少重複的思考處理週期。
解釋 Claude 的混合推理引擎
Fable 5 的核心創新在於：它能在輸出最終答案之前先把問題想清楚。這代表模型會在回應用戶端請求之前，於內部先梳理出解決方案的邏輯草稿。關鍵在於，這個思考階段永遠開啟 —— 您無法將它關閉，也沒有另外一個可供切換的「速度模式」。
當您提交一個複雜的問題時，模型不會試圖立即預測下一個詞。相反地，它會生成內部的思考 Token，模擬逐步推理的過程。這種架構大幅提升了數學、程式設計與邏輯評估的準確度。
為了支援不同的企業需求，Anthropic 讓開發者透過單一的 effort 控制項，按需調整思考的深度。在 low effort 下，模型只做簡短思考並快速作答，把延遲與 Token 花費壓低；在 high 或 max effort 下，它會推理得更深入，投入處理艱難數學、多步驟邏輯與複雜程式碼所需的額外運算。速度與深度之間的取捨，完全透過這個 effort 等級來表達，而非啟用／停用的開關。
配置 Fable 5 API 參數
要在您的軟體中實作這些功能，您必須使用更新後的 Anthropic API 架構（schema）。此架構可確保您的用戶端應用程式指定正確的模型名稱與執行參數。
推理深度是透過 output_config 區塊來設定。在其中，effort 欄位接受 "low"、"medium"、"high"、"xhigh" 或 "max" 其中之一，而這個單一值取代了舊有的 Token 預算撥盤。在單純的情況下，您完全不需要傳入 thinking 區塊 —— 自適應思考會自動執行。下方的 JavaScript 整合範例示範了如何組織這個請求：
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};
請不要嘗試停用思考或傳入 budget_tokens 值：thinking: {type: "disabled"}、thinking: {type: "enabled"} 以及任何 budget_tokens 欄位，在 Fable 5 上都會回傳 HTTP 400，因為這些參數已在此模型（以及 Opus 4.7 和 4.8）上被移除。請為速度選擇較低的 effort 等級、為深度選擇較高的等級，並在提高 effort 時於 max_tokens 中為最終答案保留足夠的餘裕。有關無伺服器架構的細節，請閱讀我們關於 使用 Cloudflare Workers 構建無伺服器 API
的指南。
處理串流中的推理 Token
對於聊天介面之類的即時應用，串流回應至關重要。Fable 5 透過 SSE（Server-Sent Events）通道輸出思考步驟與最終內容。
在串流期間，思考會以 thinking 內容區塊的形式抵達，透過 content_block_delta 事件傳遞，而該事件的 delta.type 為 "thinking_delta"。請從 delta.thinking 讀取文字，並從一般的 text_delta delta 讀取最終答案。原始的思維鏈永遠不會被回傳 —— 若要取得可讀的摘要，您必須以 thinking: {type: "adaptive", display: "summarized"} 主動啟用；預設的 "omitted" 會串流出空白的思考文字。一個最精簡的處理程式如下所示：
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}
您可以將這些 thinking_delta 區塊導入可折疊的「Thinking…」面板，或是將它們捨棄、只呈現答案。有關 Anthropic 整合的詳細參考，請直接參閱 Anthropic 開發者文檔
。
請謹慎管理您的 Token 記帳。思考 Token 會計入您的輸出 API 計費。因此，請實施強力的提示詞快取，以避免在相同輸入上重複執行推理週期。在規劃生產部署時，透過邊緣遙測層追蹤這些指標，有助於您找出思考 Token 用量超出典型範圍的地方。
逐步 API 整合工作流程
要在應用中整合推理引擎，首先更新您的本地套件以符合 Fable 5 規範。較舊的 SDK 版本仍會送出 budget_tokens，而這現在會在 API 序列化期間觸發 HTTP 400 架構錯誤。
接下來，定義清晰的延遲門檻。對於簡單的對話流程或問候語，設定 low effort 等級以壓低延遲。將 high 或 max effort 保留給程式碼生成或數學之類的任務。
此外，使用 Wrangler 等工具，將您的 API 憑證安全地存放在無伺服器環境參數中。在處理串流輸出事件時，撰寫健全的前端處理程式來過濾掉 thinking_delta 封包 —— 除非您打算直接顯示模型的推理步驟，否則這是必要的。最後，稽核提示詞快取命中率，以確認快取有將 Token 消耗開銷降到最低。要瞭解邊緣 API 設計，請探索我們的 Cloudflare Workers AI 教學
。
Low Effort 對比 High Effort 一覽
選擇 effort 等級是延遲、成本與回答品質之間的權衡。下表比較了在評估請求規模時最關鍵的維度。延遲與吞吐量的數字僅供說明，並會隨提示詞長度、負載與地區而變化，但它們之間的關係是成立的。
| 維度 | Low effort | High effort |
|---|---|---|
| 首字輸出時間 | 亞秒級（僅供說明） | 隨模型思考越多而增長 |
| 單次請求成本 | 思考 Token 較少，因此花費較低 | 思考 Token 較多，按輸出速率計費 |
| 難題準確率 | 基準水平 | 在數學、多步驟邏輯與程式碼上顯著提高 |
| Token 可預測性 | 較緊湊且更易預估 | 可變，且在艱難提示詞上更大 |
| 最契合的負載 | 聊天、分類、檢索格式化 | 偵錯、證明、規劃、複雜內容生成 |
| 配置方式 | output_config.effort = "low" | output_config.effort = "high" 或 "max" |
核心要點是：思考 Token 是實際的輸出 Token。一個 low-effort 請求只做簡短思考，主要為它寫出的答案計費；一個 high 或 max effort 請求，則可能在回應的第一個字出現之前，就生成大量的思考 Token。思考永遠不會關閉 —— 您只是在選擇要為它投入多少。
何時使用各個 Effort 等級
一種務實的做法是，把每種任務類型對應到一個預設的 effort 等級，然後只在特定請求明顯需要更多餘裕時才進行覆寫。將 high 與 max effort 保留給那些一旦答錯、在下游修正代價高昂的問題。
| 任務類型 | 建議 effort |
|---|---|
| 問候、FAQ 與閒聊 | low |
| 意圖分類與路由分發 | low |
| 短文件摘要 | low |
| 結構化資料提取 | low 或 medium |
| 多檔案程式碼生成 | high |
| 財務或數學推理 | high 或 xhigh |
| 根因偵錯 | xhigh 或 max |
在以下情況選擇 low effort 等級：當回應較短且大致上是確定性的、當首字輸出時間主導使用者體驗（即時客服、自動完成、表單助手），或當您運行大批量、低利潤的負載，其中每一個額外的輸出 Token 都會在數百萬次呼叫中成倍累加。
在以下情況選擇 high 或 max effort 等級：當單一的錯誤答案會帶來實際成本 —— 損壞的遷移指令碼、計算錯誤的報價、不安全的程式碼路徑 —— 或當任務涉及模型必須一併掌握的多個相依步驟。在這些負載中，多花幾秒鐘的延遲，換來的是可靠性上有意義的躍升。
具體範例：延遲與成本的權衡
假設有一個客服助手每天處理 50,000 個請求。假設每個最終答案約為 250 個 Token、low effort 等級只增加少數幾個思考 Token，而 high effort 等級在典型的困難查詢上消耗約 1,500 個思考 Token。以下每一個 Token 價格都僅供說明 —— 請將它視為一項建模練習，而非實際報價 —— 並假設輸出費率為 每百萬 Token 15 美元。
將每個請求都以 low effort 運行，大約會產生 50,000 × 250 = 每天 1,250 萬個輸出 Token，以說明費率計算約為 每天 188 美元。改以 high effort 運行每個請求，則計費為 50,000 × (1,500 + 250) = 每天 8,750 萬個 Token，大約 每天 1,313 美元 —— 貴了七倍，其中大部分都花在推理那些根本不需要額外深度的查詢上。
現在改採選擇性路由。假設有一個低成本的 low-effort 分類器判定只有 15% 的流量真正複雜。將 7,500 個請求送往 high effort、42,500 個送往 low effort，每天會產生 1,310 萬 + 1,060 萬 ≈ 每天 2,370 萬個 Token，約 每天 356 美元 —— 相較於全部以 high effort 運行 節省了約 73%，同時仍在能發揮價值之處施以深度推理。
延遲的情況也如出一轍。在 low effort 下，第一個 Token 通常在遠不到一秒內就會出現。在 high effort 下，模型會在答案開始之前生成大得多的推理草稿，因此一份 1,500 個 Token 的內部草稿，以說明性的每秒 60 個 Token 計算，會使可見的回應延遲約 25 秒。將 thinking_delta 區塊串流到可折疊的「Thinking…」面板中，正是讓終端使用者能夠容忍這段等待的關鍵。
遷移和總擁有成本（TCO）
如果您正從固定運算的模型遷移過來，最大的轉變是：推理深度現在是一個您逐請求設定的撥盤，而不是您在每次呼叫都要支付的固定費率。帳單上最大的槓桿，不是任何單次呼叫的 effort 等級，而是決定哪些請求究竟值得使用 high effort 等級的 路由層。一個輕量級的 low-effort 分類呼叫（幾百個 Token），用來把關昂貴的 high-effort 呼叫，幾乎總是能收回成本。
有兩個習慣可以讓總擁有成本保持可預測。首先，為每一類任務設定能可靠解決它的最低 effort 等級，而非寬鬆的全域預設值；到處都套用 max effort 等級，是意外帳單最常見的來源。其次，快取穩定的系統提示詞，讓重複的上下文不會在每個推理週期都被重新計費。將逐請求路由與提示詞快取結合起來，就能把大部分支出集中到真正從中受益的少數請求上。
核心要點
- Fable 5（
claude-fable-5，100 萬 Token 上下文、最高 128K 輸出）讓思考永遠開啟；您調整的是它的深度，而不是開關它。 - 以
output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"}配置推理深度；budget_tokens以及thinking.type的 “enabled”／“disabled” 現在都會回傳 HTTP 400。 - 透過
thinking內容區塊（thinking_deltadelta）串流思考，以向終端使用者顯示模型的步驟；並以thinking: {type: "adaptive", display: "summarized"}主動啟用來取得可讀的摘要。 - 透過選擇可行的最低 effort 等級並快取常用的提示詞，來控制 API 計費成本。
- 將您的 API 中介軟體部署在無伺服器邊緣網路上，以降低傳輸延遲。
常見問題（FAQ）
什麼是 Claude Fable 5 推理？
Claude Fable 5 推理是一種永遠開啟的能力：模型會在輸出最終回應之前，生成內部的思考 Token 來解決複雜的邏輯問題。它不會試圖立即猜測下一個詞，而是模擬逐步思考的過程，以解決架構、數學與程式設計上的錯誤，而您可以透過 effort 設定來調整它思考的深度。
我要如何在 API 中配置推理 effort？
您可以透過在 API 請求負載內傳入 output_config: { effort: "low" | "medium" | "high" | "xhigh" | "max" } 來配置推理深度。較低的 effort 等級只做簡短思考、以較少的 Token 更快作答，較高的等級則推理得更深入。舊的 budget_tokens 參數已被移除，現在在 Fable 5 上會回傳 HTTP 400 錯誤。
推理 Token 的計費方式不同嗎？ 不，推理 Token 按模型的標準輸出 Token 費率計費。因為這些 Token 代表輸出的運算量，它們會直接計入您的 API 帳單，這使得提示詞快取與合理的 effort 等級對於控制軟體支出至關重要。
我要如何讓 Fable 5 回應得更快？
您無法停用推理 —— Fable 5 的思考永遠開啟，傳入 thinking: {type: "disabled"} 會回傳 HTTP 400 錯誤。要降低延遲，請以 output_config: { effort: "low" } 調低 effort 等級，這會縮短思考階段，並將基本對話任務的首字輸出時間降到最低。
我要如何即時從 SSE 串流中解析推理 Token？
在無伺服器 SSE 串流期間，思考會以 thinking 內容區塊的形式，透過 content_block_delta 事件抵達，而該事件的 delta.type 為 thinking_delta；請從 delta.thinking 讀取文字，與標準的 text_delta 輸出分開處理。以 thinking: {type: "adaptive", display: "summarized"} 主動啟用即可取得可讀的摘要，接著再依前端 UI 偏好來渲染或丟棄這些 Token。
評論