簡短回答： 不要因為每次請求失敗就從 Claude 切換到 GPT。401 表示必須修復認證；與路徑相關的 404 表示需要更正 URL 或端點。429 或臨時性的 5xx 可採用退避重試；若在有界重試後仍失敗，再由相容的後備模型接手。
只有一個重要例外：帶有 error.code: invalid_request 的 500 仍屬於請求問題。重試它——或把同樣壞掉的負載送去另一個模型——只會掩蓋程式錯誤。
本文已於 2026 年 8 月 20 日依據 CometAPI 的錯誤、重試、基底 URL、速率限制與模型回退文件完成驗證。本文僅涵蓋錯誤分類。關於路由設計、供應商憑證與多層回退，請參考完整的模型回退教學與技術回退指南。
從「重試或失敗」的決策開始
| 狀態 | 通常代表 | 需要重試？ | 需要回退？ | 首要行動 |
|---|---|---|---|---|
| 401 | 金鑰遺失或無效 | No | No | 修正 Bearer 權杖 |
| 404 | 路徑或端點錯誤 | No | No | 檢查基底 URL 與路由 |
| 429 | 速率限制或飽和 | Yes | 在有限次重試後 | 以抖動退避 |
| 500 + invalid_request | 異常或不合規的請求 | No | No | 修正請求負載 |
| 500/503/504/524 | 平台或供應商暫時性故障 | Yes | 在有限次重試後 | 保留請求 ID |
實務問題不在於「Claude 是否失敗？」，而在於「在不改動此請求中無效部分的情況下，換一個模型能否成功？」認證與路徑錯誤會影響連線本身，改變模型無法解決。臨時性的容量與伺服器故障可能是路由特定的，因此回退可能有助益。
在切換模型之前先讀懂錯誤
結合 HTTP 狀態與 error.code、error.message 一起判讀。許多 CometAPI 的失敗會使用如下包裝格式：
{
"error": {
"message": "human-readable detail and request id",
"type": "comet_api_error",
"param": "problematic_parameter_or_empty",
"code": "error_code_or_empty"
}
}
不要僅憑狀態碼的第一位數來分類。500 仍可能帶有 invalid_request，而錯誤的 CometAPI 路徑可能返回重新導向或 HTML，而非乾淨的 JSON 404。
401 未授權：停止並修正驗證
401 通常代表 API 金鑰遺失、格式錯誤、已過期，或取自錯誤的環境。標頭必須是：
Authorization: Bearer $COMETAPI_KEY
不要重試，也不要切換模型。兩條路由都會使用同樣壞掉的認證。檢查部署服務是否載入舊密鑰、金鑰是否被加入空白字元，與請求是否送往預期的環境。僅透過你的祕密管理流程輪換或重新載入金鑰。
404 找不到：在回退前修正 URL
對於與 OpenAI 相容的請求，請精確使用這個基底 URL：
https://api.cometapi.com/v1
缺少 /v1、重複的路徑片段或錯誤的端點都可能導致 404、重新導向、HTML 回應，或 SDK 解析錯誤。在除錯時停用自動跟隨重新導向，並依照 API 參考確認最終請求路徑。
若回應明確表示模型不可用或找不到，請於目前的 CometAPI Models API 驗證模型 ID。不要把每個 404 都當成模型不可用。只有在擷取並測試到那個明確訊號後，才新增模型特定的回退。
429 請求過多：進入回退前先退避
429 可重試。使用帶抖動的指數退避、降低突發並發，並衡量是哪一條路由飽和。所有工作者立即重試會把短暫的速率限制放大為更大的流量尖峰。
在少量且有界的重試之後，當下一個模型支援相同的輸入、輸出契約與必要能力時，回退才是合適的。回退不是免費的：它會增加延遲，並可能改變成本或行為，因此請記錄其使用頻率。
5xx 錯誤：先檢查錯誤代碼，再重試
500、503、504 與 524 通常代表平台、供應商或逾時類故障。保留請求 ID、端點、模型與時間戳，然後採用退避重試。若同樣的暫時性故障在重試額度內仍持續，才切換到下一條相容路由。
但先檢查回應本文。當 500 內含 error.code: invalid_request 或 invalid_request_error 時，請先修正請求本文，僅在內容改變後再重試。常見原因包括缺少 messages 欄位，或選用的端點不接受某個供應商特定參數。
在程式碼中使用一個簡潔的策略
以下 Python 範例在應用程式內管理重試與回退。它使用一個 CometAPI 金鑰、與 OpenAI 相容的基底 URL，並透過環境變數指定當前的 Claude 與 GPT 模型 ID。它只對暫時性失敗進行重試，並在耗盡重試額度後才更換模型。
import os, random, time
from openai import APIError, OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_KEY"],
base_url="https://api.cometapi.com/v1",
max_retries=0,
)
MODELS = [os.environ["CLAUDE_MODEL"], os.environ["GPT_MODEL"]]
RETRYABLE = {429, 500, 503, 504, 524}
def complete(messages):
for model in MODELS:
for attempt in range(3):
try:
response = client.chat.completions.create(model=model, messages=messages)
return response.choices[0].message.content
except APIError as error:
status = getattr(error, "status_code", None)
code = getattr(error, "code", None)
if status in {401, 404} or code in {
"invalid_request", "invalid_request_error"
}:
raise
if status not in RETRYABLE:
raise
if attempt < 2:
time.sleep(2**attempt + random.random())
continue
break
raise RuntimeError("No configured route completed.")
print(complete([{"role": "user", "content": "Summarize this ticket."}]))
已停用 SDK 的自動重試，讓應用程式掌握總體重試與回退預算。否則，SDK 的重試與應用程式的重試會相乘，造成過量呼叫並延遲最終回應。
在不猜測的情況下測試策略
| 模擬訊號 | 預期結果 | 絕不可發生的情況 |
|---|---|---|
| 401 | 立即拋出 | 不得重試，也不得呼叫 GPT |
| 404 | 立即拋出 | 不得以回退掩蓋錯誤路徑 |
| 429 | 退避，然後回退 | 不得立即引發重試風暴 |
| 500 + invalid_request | 立即拋出 | 不得重複送出有問題的請求 |
| 503/504/524 | 退避，然後回退 | 不得出現無邊界的路由鏈 |
這些是策略測試，而非對線上供應商可靠性的主張。在測試環境中，將狀態與錯誤本文注入分類器，驗證呼叫的次數與順序，並確認你的最終錯誤仍包含原始請求脈絡。
何時從 Claude 回退至 GPT 才真正安全
只有在兩條路由都能滿足相同的應用契約時，跨模型家族切換才安全。請正規化請求與回應欄位，在兩個模型上測試結構化輸出或工具行為，並驗證任何必要的影像、文件、脈絡或推理能力，然後再啟用該路由。
回退也應尊重副作用。若第一條路由已觸發工具、寫入資料，或已串流部分回應，盲目重送整個請求可能重覆動作或讓使用者困惑。請從檢查點恢復或回傳可控的失敗。
讓重試保持邊界的生產檢查清單
- 設定單一總延遲預算：所有重試與回退嘗試都必須計入同一個截止時間。
- 對重試設上限：使用帶抖動的退避，並在小且可配置的次數後停止。
- 控制並發：在請求離開應用程式前就降低突發流量。
- 加入斷路器：暫時停止呼叫反覆失敗的路由。
- 記錄決策：在不儲存機密的前提下，捕捉狀態、錯誤代碼、請求 ID、模型、嘗試次數、延遲與回退原因。
- 追蹤回退率：持續上升是營運訊號，而非正常的成功度量。
常見問題
401 是否應觸發模型回退？
不應。請修正或重新載入 API 金鑰。透過相同無效憑證呼叫的其他模型也會因相同原因失敗。
404 是否應觸發回退？
預設不應。先修正基底 URL 或端點。只有在獨立驗證的「模型不可用」訊號下，才讓其進入回退分類器。
遇到 429 應重試幾次？
使用符合使用者端延遲預算的小型應用端上限。以抖動退避並降低並發；不要立即或無限期重試。
所有 5xx 都可重試嗎？
不是。暫時性的 500、503、504 與 524 可考慮重試，但帶有 invalid_request 的 500 應直接失敗，直到修正負載為止。
Claude 與 GPT 是否能在不變更請求的情況下共用？
僅限於你的應用已測試過的共用欄位。供應商特定參數、工具格式、結構化輸出與多模態輸入可能需要轉接器。只更換模型 ID 並不能保證相容。
哪裡可以找到完整的回退實作？
請參考如何打造穩健的 LLM 模型回退策略，以及 CometAPI 模型回退指南以取得實作細節。
讓錯誤分類器成為守門員
自動回退在範圍窄且可觀測時最有用。讓認證、路徑與不合規請求的錯誤大聲失敗。對速率限制與臨時伺服器故障採用退避重試，並僅在耗盡重試預算後才切換到相容路由。此策略使回退成為可靠性控制，而非用來掩蓋設定錯誤的手段。