拒絕與備援

Claude Fable 5 包含可拒絕請求的安全分類器。當發生這種情況時，您會收到一個正常的回應（而非錯誤），其中包含 stop_reason: "refusal"。通常您仍可透過將相同的請求傳送至另一個 Claude 模型來取得答案。本頁面將說明如何辨識拒絕，以及如何設定該重試機制。

當您基於 Claude Fable 5 進行建置，並希望被拒絕的請求能自動轉由另一個模型處理時，請閱讀本頁面。當您剛在回應中看到 "refusal" 並想知道接下來該怎麼做時，本頁面同樣適用。

stop_reason 值的完整清單請參閱停止原因與備援。關於被拒絕請求的計費方式，以及如何避免在重試時為提示快取支付兩次費用的詳細資訊，請參閱備援額度。封裝上述所有功能的 SDK 輔助工具請參閱 SDK 中介軟體。如需完整的端對端範例，請參閱備援與計費 Cookbook。

最簡單的設定：在請求中指定一個備援模型，API 會處理重試。

await client.beta.messages.create({
  model: "claude-fable-5",
  max_tokens: 1024,
  messages,
  betas: ["server-side-fallback-2026-06-01"],
  fallbacks: [{ model: "claude-opus-4-8" }]
});

以下各節涵蓋拒絕回應包含的內容、何時使用伺服器端或用戶端備援，以及各自的計費方式。

拒絕回應的樣貌

拒絕是一個成功的 HTTP 200 回應，其中包含 stop_reason: "refusal"：

{
  "id": "msg_01XFUDYJgAACzvnptvVoYEL",
  "type": "message",
  "role": "assistant",
  "model": "claude-fable-5",
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "This request was declined because it could enable cyber harm."
  },
  "usage": {
    "input_tokens": 412,
    "output_tokens": 0
  }
}

stop_details 物件說明了拒絕的原因。其 category 欄位指出觸發分類器的政策領域。其 explanation 欄位是人類可讀的描述；該文字並非穩定不變，因此請將其顯示而非解析。當拒絕未對應到具名類別時，這兩個欄位皆為 null，且 null 是正常的永久值，而非佔位符。對於 refusal 以外的所有停止原因，stop_details 本身為 null。

拒絕可能在任何輸出之前到達，或在部分輸出後於串流中途到達。無論哪種情況，請將任何部分輸出視為不完整並予以捨棄。

選擇備援方式

有三種方式可在另一個模型上重試被拒絕的請求。正確的選擇取決於您的執行環境以及您需要多少控制權。

伺服器端備援和 SDK 中介軟體會為您套用備援額度，因此只有在自行建置重試時才需要參閱該頁面。

伺服器端備援

伺服器端備援會在單一 API 呼叫內重試被拒絕的請求。您最多可指定三個備援模型，當 Claude Fable 5 拒絕時，API 會對相同的請求執行鏈中的下一個模型。您會收到一個回應，其中指出回答的模型，因此您的使用者可在一次往返中取得答案。

發出請求

在 fallbacks 參數中指定備援模型，並傳送 server-side-fallback-2026-06-01 測試版標頭。

fallbacks 清單適用以下幾項規則：

• 項目會依序嘗試。每個項目必須與其他項目及所請求的模型不同。
• 每個項目必須是所請求模型的允許目標之一。設定測試版標頭後，該清單會以 allowed_fallback_models 的形式發布在 Models API 中該模型的項目上。
• 每個項目指定一個 model，並可僅針對該次嘗試覆寫 max_tokens 和 thinking。
• 該請求必須對所指定的每個模型而言都是有效的直接請求。如果備援模型不支援請求所使用的某項功能，API 會預先拒絕該請求。
• 只有安全分類器的拒絕會觸發備援。所請求模型上的速率限制、過載或伺服器錯誤會原樣回傳給您。

回應包含的內容

回應看起來與任何其他訊息相同，但有兩項新增內容：

• 頂層的 model 欄位回報產生所回傳訊息的模型，無論是所請求的模型還是備援模型。
• fallback 內容區塊標記 content 中一個模型的輸出讓位給下一個模型的每個位置：{"type": "fallback", "from": {"model": ...}, "to": {"model": ...}}。當拒絕的環節是所請求的模型時，from.model 會回傳您所傳送的模型字串。to.model 始終是接續模型的解析後 ID。

在任何輸出之前的拒絕，fallback 區塊會是第一個內容區塊：

{
  "id": "msg_01XFUDYJgAACzvnptvVoYEL",
  "type": "message",
  "role": "assistant",
  "model": "claude-opus-4-8",
  "content": [
    {
      "type": "fallback",
      "from": { "model": "claude-fable-5" },
      "to": { "model": "claude-opus-4-8" }
    },
    { "type": "text", "text": "Hi! How can I help you today?" }
  ],
  "stop_reason": "end_turn",
  "stop_details": null,
  "usage": {
    "input_tokens": 412,
    "output_tokens": 264,
    "cache_read_input_tokens": 0,
    "cache_creation_input_tokens": 0,
    "iterations": [
      {
        "type": "message",
        "model": "claude-fable-5",
        "input_tokens": 535,
        "output_tokens": 0,
        "cache_read_input_tokens": 0,
        "cache_creation_input_tokens": 0
      },
      {
        "type": "fallback_message",
        "model": "claude-opus-4-8",
        "input_tokens": 412,
        "output_tokens": 264,
        "cache_read_input_tokens": 0,
        "cache_creation_input_tokens": 0
      }
    ]
  }
}

usage.iterations 陣列記錄每次嘗試。拒絕的模型會以一般的 message 項目出現，而服務該回合的模型會以 fallback_message 項目出現。如果鏈中的每個模型都拒絕，回應會是最後一個模型的拒絕，其中每個先前的環節都有一個 message 項目，最後一個則有一個 fallback_message 項目。

繼續對話

在下一回合，將助理內容按您收到的原樣傳回。在輸出中途備援後，content 可能包含拒絕模型在交接前產生的區塊類型；下表涵蓋在回傳該回合時應保留哪些、捨棄哪些。

串流

在串流請求中，重試會在同一個串流上發生，且您已收到的任何內容都不會失效。當拒絕發生在任何輸出之前時，message_start 會指出備援模型，且 fallback 區塊是第一個內容區塊；由於 message_start 會等待備援嘗試開始，首位元組時間會包含被拒絕的嘗試。當拒絕發生在輸出中途時，開啟的內容區塊會關閉，fallback 區塊（一對沒有 delta 的普通 content_block_start 和 content_block_stop）會標記邊界，備援模型會從部分輸出繼續。只有部分輸出的 text 區塊會作為上下文傳遞給備援模型；其他區塊類型仍保留在 content 中。在輸出中途的情況下，message_start 已指出所請求的模型，因此請從 fallback 區塊的 to.model 以及最終 message_delta 的 usage.iterations 中的 fallback_message 項目讀取服務模型。

在非串流請求中，輸出中途的拒絕行為不同：回應會省略被拒絕模型的部分輸出，備援模型會從頭開始回答。結果看起來像是任何輸出之前的拒絕，fallback 區塊位於最前面。被拒絕的嘗試及其輸出 token 仍會出現在 usage.iterations 中。

使用 SDK 中介軟體的用戶端備援

TypeScript、Python、Go、Java 和 C# SDK 包含拒絕備援中介軟體。您在用戶端上使用備援模型清單設定一次。透過 client.beta.messages 的呼叫隨後會在任何平台上自動重試被拒絕的請求。該中介軟體也會在其處理的每個請求上傳送 fallback-credit-2026-06-01 測試版標頭，因此重試會重新定價，無需逐請求設定。

設定方式

將中介軟體傳遞給用戶端建構函式，並在對話的各個請求之間共用一個 BetaFallbackState 實例。

行為方式

• 重試會依序遍歷您的備援清單。本身也拒絕的備援模型會將請求傳遞給下一個項目。
• 只有當清單中的每個模型都拒絕時，才會回傳原始的拒絕回應。中介軟體不會為此引發錯誤。
• 來自 Claude Fable 5 的思考區塊會為您處理：中介軟體會從重試中移除它們，並在後續請求的對話歷史中管理它們。
• 透過中介軟體服務的回應會在每個模型邊界包含一個 fallback 內容區塊，與伺服器端備援回應相同。中介軟體會在後續請求中為您管理這些區塊。
• 接受請求的模型會記錄在 BetaFallbackState 中，因此共用該狀態的後續請求會固定使用該模型，而非重新詢問已拒絕的模型。

Message Batches 中的拒絕

Message Batch 中被拒絕的請求會以 result.type: "succeeded" 和 stop_reason: "refusal" 的形式回傳。批次結果中的 stop_details 欄位可能為 null，因此請直接檢查 stop_reason 來偵測拒絕。

伺服器端備援不適用於批次（包含 fallbacks 的批次請求會產生逐項目的錯誤結果）。若要重試被拒絕的批次項目：

1. 從結果中收集被拒絕的項目。
2. 從任何多回合歷史中移除 Claude Fable 5 的思考區塊。
3. 將它們作為新批次或直接請求在備援模型上重新提交。

常見陷阱

• **在不同的模型上重試。**將被拒絕的請求重新傳送至相同的模型通常會再次遭到拒絕。請將重試指向備援模型。
• **以每個請求為單位預算重試，而非每回合或每工作階段。**單一回合可能產生多次拒絕，例如一個代理程式加上其子代理程式。
• **在每個請求路徑上設定備援。**重試處理器、錯誤復原分支和背景工作程式都需要它。在沒有備援的情況下重新發出請求的處理器，恰恰會在最可能需要保護的請求上失去保護。
• 為子代理程式呼叫提供各自的備援。fallbacks 參數不會傳播到工具執行內部發出的模型呼叫中。
• **讓備援成為請求的屬性，而非環境狀態的屬性。**共用旗標、快取的設定值或全域開關可能會失去同步，並悄悄地使請求失去保護。當您無法確認備援是否啟用時，請設定它，而非假設它已開啟。
• **將拒絕作為獨立的訊號進行監測。**拒絕是 HTTP 200，因此基於錯誤率或 5xx 回應建置的監控永遠看不到它。為每次拒絕發出一個事件，為每個由備援服務的回應發出一個事件（usage.iterations 中的 fallback_message 項目標記後者），然後針對兩個計數之間的差距發出警示。
• 根據 stop_reason 進行分支，而非 stop_details 或 content。stop_details 僅供參考，在拒絕時可能為 null。請直接檢查 是否等於 。

後續步驟