將 retry 與 fallback 分開
retry 會將請求再次送往同一路由，因為失敗可能只是暫時性的。fallback 則會更換供應商或模型，因為原始路由不可用或不適合。
把兩者當成單一的通用重試迴圈，會讓事件更難診斷，也可能在不提升成功率的情況下成倍增加成本。
- retry: 逾時、連線重設、429 或暫時性的 5xx 回應。
- fallback: 供應商反覆失敗、模型容量問題或政策限制。
- 停止: 無效請求、不支援的參數或輸出驗證失敗。
建立能力相容的路由表
fallback 模型應依能力而非品牌分組。視覺請求不能 fallback 到僅支援文字的模型，而嚴格的 JSON 工作流程也不應路由到經常違反 schema 的模型。
- 必要的輸入與輸出模態。
- 最小上下文與輸出長度。
- 工具呼叫與結構化輸出支援。
- 可接受的最高價格與延遲。
套用單一請求層級預算
請求預算應涵蓋所有 retry 與 fallback 嘗試。在開始下一次嘗試之前，先檢查剩餘的延遲與成本預算是否足以支援。
const routePolicy = {
maxAttempts: 3,
maxLatencyMs: 18_000,
maxEstimatedCost: 0.12,
retryOn: [408, 429, 500, 502, 503, 504],
fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};衡量 fallback 品質，而不只是可用性
即使請求成功回傳，也可能代表產品失敗。請在 fallback 事件後追蹤輸出驗證、使用者修正率與任務完成情況。
建議儀表板：路由成功率、fallback 率、p95 延遲、預估成本、驗證通過率，以及依模型區分的品質分數。