Claude Fable 5 用於 Agent：工具呼叫遭拒、成本與 GLM 5.2 比較

在我們的評測中，Claude Fable 5 執行 coding agent 時，44 個回合有 11 個在工具呼叫途中遭拒，連修正設定預設值這類普通任務也會觸發。模型生成工具參數到一半時，會回傳 stop_reason: "refusal"。截斷後的參數仍能解析成有效 JSON；如果 Agent 迴圈未檢查停止原因便直接執行工具呼叫，就會把只寫了一半的檔案存進磁碟。將 Fable 5 用於 Agent 時，首先要處理的是這個行為，而非價格。

TL;DR

• Claude Fable 5 在普通的 Agent 任務中也會於工具呼叫途中回傳 stop_reason: "refusal"，例如修正設定預設值、預訂會議室。截斷後的 write_file 參數仍可解析，因此未檢查停止原因的迴圈會執行只寫了一半的檔案。
• Fable 5 的 thinking 採 adaptive 模式，無法關閉：enabled 與 disabled 都會遭到拒絕；只能透過 output_config.effort 控制。
• Fable 5 的成本溢價取決於工作負載形態：四回合 coding 任務的成本為 $0.045，glm-5.2 則為 $0.003，相差 15 倍；但在快取已預熱的批次工作中，成本只有 sonnet-5 的 5 倍。
• Fable 5 要求保留資料 30 天。

以下數據皆於 2026-07-05 透過 Synthorai 閘道測得。我們使用小型情境測試工具，涵蓋五種 Agent 工作負載形態：使用工具的 coding 迴圈、RAG 問答、工具密集的協調流程、批次分類，以及 15 回合對話。測試模型包括 claude-fable-5、claude-opus-4-8、claude-sonnet-5 與 glm-5.2；需要觀察變異的任務各執行三次。這些任務刻意設計得很簡單，通過率只用來確認基本行為，不是能力基準測試。成本採用閘道計費的 usage.cost。

執行工具呼叫前先檢查 stop_reason

文件沒有警告這種失敗，而且它會破壞狀態。Agent 讀取 app.py，決定寫入修正內容，並開始產生 write_file 呼叫。生成檔案內容到一半時，串流停止：

{
  "stop_reason": "refusal",
  "content": [{
    "type": "tool_use",
    "name": "write_file",
    "input": {
      "path": "app.py",
      "content": "DEFAULTS = {\n    \"timeout_s\": 30,\n    "
    }
  }]
}

這個 input 物件是完整且可解析的 JSON，沒有任何欄位表示「輸出提前中止」。如果你的迴圈規則是「收到工具呼叫就執行」，app.py 就會被只有 38 個字元的片段覆寫。內容停在 dictionary 中間，無法再解析成 Python；下一回合也會遭拒，最後整個迴圈結束，工作區則已損毀。

從數據可確認三件事：

• 普通工作也會觸發。 遭拒的任務包括修正設定查詢中的 KeyError、實作 slugify 函式、預訂會議室，以及建立發票草稿。沒有任何雙重用途或敏感內容。
• 這個行為可以重現，不是隨機事件。 某個 coding 任務連續三次都遭拒，串流與非串流模式皆然；其他任務則從未遭拒。綜合各種條件，Fable 5 在簡單 coding 情境中的通過率為 58-75%，claude-opus-4-8、claude-sonnet-5 與 glm-5.2 則都是 100%。所有失敗皆源自拒絕，而非程式碼錯誤。
• 對話中一旦出現拒絕，該次執行就結束了。 後續回合仍回傳 stop_reason: "refusal"，且輸出為空。在相同 context 中重試也無法恢復。

觸發因素並不是任務內容，數據很明確。每次都遭拒的任務，只是在九行程式碼中修正設定 dictionary 的 KeyError，不涉及憑證或漏洞利用。相較之下，批次情境可分類涉及加密貨幣挖礦、外洩 Stripe 金鑰及網路釣魚頁面的客服單，沒有任何一次遭拒；RAG 情境也能根據包含 AES-256-GCM 密鑰與資安事件應變程序的文件正常回答。所有拒絕都發生在兩種會多回合執行工具的情境；另外三種單次情境即使包含更敏感的內容，也從未遭拒。問題出在 Agent 迴圈的形態，而不是文字內容，因此清理輸入無法避免。

只要在工具執行步驟前加上一段檢查即可：

if response.stop_reason == "refusal":
    # do NOT execute tool calls from this turn: arguments may be truncated
    raise AgentInterrupted("model refused; restart episode or escalate")

Anthropic 文件說明了運作方式：若輸出任何內容前就觸發拒絕，系統會回傳空的 content 陣列且不計費；若在串流途中拒絕，已串流的輸出仍會計費，官方建議丟棄不完整內容。回應另有 stop_details 物件，其中包含分類，例如 cyber、bio 或 null，可用來區分類別器封鎖與一般拒絕。文件未明確說明的是它與工具使用的交互作用：拒絕可能發生在參數生成途中，而不完整參數看起來與完整參數完全相同。

官方也提供復原機制。在 Claude API 上，可使用 beta 版 fallbacks 參數（betas: ["server-side-fallback-2026-06-01"]、fallbacks: [{"model": "claude-opus-4-8"}]），在同一次呼叫中改由備援模型重新執行遭拒的請求。若拒絕發生在輸出前，該次拒絕不計費。Amazon Bedrock、Vertex AI 與 Microsoft Foundry 不支援此功能，其 SDK 改提供客戶端 fallback middleware。無論採用哪種方式，都必須先加上前述防護：只要該回合的停止原因是拒絕，就絕不能執行其中的工具呼叫。

五種 Agent 形態的成本

下表是每個完成單位（任務、查詢、項目或對話）的成本中位數，使用相同 prompt，並於同一天測量：

比起任何單一數字，更需要留意表中的兩個結論：

• 最便宜的模型會隨工作負載形態改變。 glm-5.2 在迴圈與長對話中成本最低，但 claude-sonnet-5 是這組模型中最便宜的批次分類器，甚至低於 glm-5.2。原因是基礎 prompt 預熱後，快取讀取比例可達 97%，再加上其首發價格。
• Fable 5 的成本溢價同樣取決於工作負載形態：coding 迴圈的成本是 glm-5.2 的 15 倍，對話則為 11 倍；但在快取已預熱的批次項目中，成本只比 sonnet-5 高 5 倍，因為大部分 prompt 都由快取消化。

接下來要先說明如何控制這些成本，再看兩個會在不知不覺間推高費用的因素。

降低 Agent 費用

快取是影響最大的手段，而且 Fable 5 的快取規則沒有改變。Agent 測試數據清楚顯示其價值：移除 cache_control 標記後，同一個 coding 任務的成本提高至 2.0 倍，快取已預熱的批次項目則提高至 6.8 倍。opus-4-8 在相同消融測試中分別為 3.8 倍與 6.9 倍。在迴圈中，滑動標記模式不只是最佳化技巧，而是成本是否可行的關鍵。

第二個手段是 prompt 排序，而且在所有受測模型上都有效。將固定規則放在每次查詢的 context 之前，而不是之後，可讓四個模型的 RAG 查詢成本降低 26-37%；在 Claude 系列上，如果順序錯誤，每次呼叫還要額外支付 1.25 倍的快取寫入費用。LangChain 快取文章已說明其運作方式；此處數據只是確認同樣規則可直接套用於 Fable 5。

Fable 5 另有兩個可調整項目。第一個是可使用快取的最低門檻降至 2,048 個 token，只有 Opus 4.8 的 4,096 個 token 一半。這看似只是規格細節，但 Agent 的成本節省主要來自重複使用的框架內容，包括 system prompt、工具定義，以及滑動更新的對話前綴，而這些內容必須超過門檻才能進入快取。若工具密集型 Agent 每回合的前綴介於 2,048 到 4,096 個 token，在 Opus 4.8 上完全無法使用快取，到了 Fable 5 則可開始快取。後續每回合原本按原價計費的前綴，會變成約為原價 10% 的快取讀取。反過來說，若先前為了跨過 4,096 的舊門檻而填充前綴，現在可能只是徒增負擔。請直接從實際回應讀取 cache_read_input_tokens，不要自行假設；Fable 5 的折扣起點比以前更早。

第二個是 task budgets（beta，header 為 task-budgets-2026-03-13），它正好處理本次比較反覆出現的問題：Fable 5 迴圈很快就會累積高額費用，而 max_tokens 無法解決。max_tokens 是模型看不到的單次回應硬上限，因此模型仍會當作可用空間無限來規劃，最後在思考途中遭到截斷。task budget 的行為不同。你可為迴圈設定模型能看到的 token 上限，最低為 20,000。模型會看到持續遞減的額度，據此調整節奏並妥善收尾，而不是突然遭到截斷。它計算的是模型生成內容，以及模型在該回合讀取的工具結果，不包含每次請求重送的完整歷史。Fable 5 的 coding 迴圈單回合成本是 glm-5.2 的 15 倍，因此讓模型自行依預算收斂，是成本最低的防護措施。

文件不會提醒你的兩個成本陷阱

即使已設定上述控制項，仍有兩個較小的因素會讓費用朝文件未曾提醒的方向變動。

"low" effort 並沒有比較便宜。 Fable 5 的 thinking 深度由 output_config.effort 控制，直覺上 low 應該成本更低，但實測並非如此。設定 effort: "low" 後，coding 迴圈每個任務的成本為 $0.0478，高於預設值的 $0.0451，而且輸出 token 更多，不是更少。我們在 GLM 5.2 也觀察到相同情況，其 effort 名稱同樣無法對應 token 數量。無論使用哪個模型系列，都應先在自己的工作負載上實測，不要直接認定 "low" 就代表「更少」。數字難以預測的其中一個原因，是 adaptive thinking 占輸出 token 的比例會隨工作負載大幅變動：同一模型、同一天，coding 迴圈為 2%，RAG 回答為 30%，批次分類則為 52%。輸出 token 預算應按工作負載形態設定，而不是按模型設定。

絕不要重播 reasoning_content。 在相容 OpenAI 的模型上，reasoning 欄位不是對話歷史。DeepSeek API 要求移除它；在 GLM 5.2 上，重播雖然合法，但會計費。我們曾將它重新放入訊息歷史，導致 GLM 迴圈成本增加約 28%，移除後才恢復正常。Anthropic 自己的 thinking blocks 則不同：使用相同模型時必須原樣重播；但如果將 Fable 5 的 thinking block 路由到另一個模型，例如 fallback 至 Opus，系統會自動從 prompt 移除且不計費，因此不需要自行處理。

請求介面的變更

Fable 5 的大部分請求介面與 Opus 4.7/4.8、Sonnet 5 相同。根據文件，以下功能已移除：

• thinking: {type: "enabled", budget_tokens: N} 會回傳 400。從 Claude 3.7 Sonnet 到 4.5 系列使用 token 預算的 Extended thinking 機制，已在 4.7 以上系列全面由 adaptive thinking 取代。
• thinking: {type: "disabled"} 會回傳 400，而且這是 Fable 5 特有的限制。Opus 4.7/4.8 與 Sonnet 5 仍可關閉 thinking，Fable 5 則不行。
• temperature、top_p 與 top_k 只要設定成非預設值，就會遭到拒絕。
• Assistant message prefill，也就是最後一個回合為 assistant，會回傳 400。

移植既有請求時，最常出問題的是移除 temperature／top_p／top_k 與 prefill。thinking 與資料保留的變更已在上文及資料保留文章說明。

結論

將 Fable 5 用於 Agent，首先是工程問題，其次才是預算問題。執行工具呼叫前必須處理 stop_reason: "refusal"，否則即使只是修正設定這種普通任務，遭截斷的寫入也會破壞狀態。接著要主動控制成本：快取是影響最大的手段；可使用快取的最低門檻已降至 2,048 個 token，因此需要重新檢查前綴；task budget 可避免迴圈持續累積本次比較中最高的單回合費用；effort: "low" 也不像名稱暗示的那樣能省錢。預算還必須按工作負載形態設定：同一模型在 coding 迴圈中的成本是 glm-5.2 的 15 倍，在快取已預熱的批次工作中則是 sonnet-5 的 5 倍。這些數據不是要你一定使用或不要使用 Fable 5，而是說明預設值並非中立；費用與失敗模式都取決於 Agent 的設計形態。

常見問題

Fable 5 經常拒絕工具呼叫嗎？ 拒絕集中在特定任務：某個設定修正任務每次執行都遭拒，其他任務則從未發生；相同任務在串流與非串流呼叫中都能重現。因此這不是重試就能避開的偶發問題。你的工作負載會有不同發生率，但工程上的處理方式相同：執行工具呼叫前先檢查 stop_reason。

可以關閉 Fable 5 的 thinking 嗎？ 不行。thinking.type.disabled 與 enabled 都會遭到拒絕。thinking 預設採 adaptive 模式，唯一可用的控制項是 output_config.effort；在我們的迴圈中，low effort 並未降低成本。

Fable 5 有可能是便宜的選項嗎？ 在這組測試中沒有。它的最小成本溢價出現在快取已預熱且大量使用快取的批次工作，約為 sonnet-5 的 5 倍，因為快取已消化大部分 prompt。在迴圈與長對話中，它都是受測模型裡最昂貴的一個。

驗證方式：所有數據皆於 2026-07-05 透過 https://synthorai.io/ 測得（Claude 系列使用 Anthropic 原生 /v1/messages，glm-5.2 使用 /v1/chat/completions）。五種情境形態共執行 505 次情境與 1,022 次呼叫；需要觀察變異的任務各執行三次。成本採用閘道回報的 usage.cost，表中顯示中位數。任務刻意設計得很簡單，因此通過率只用來確認基本行為，不是能力基準測試；未實測的能力，我們不會提出相關主張。拒絕行為在串流與非串流模式下皆可重現。實際數據會因 prompt、區域與負載而異。

← 返回部落格