OpenRouter Provider Routing 深入解析：2026 年 10 月更新

OpenRouter 在 2026 年 10 月 28 日重建了預設路由：首個 Token 回應時間降低 16.9%，整體 429 事件減少 67%，但請求成本約增加 6%。自動路由可能在不知不覺間把請求轉到更昂貴的供應商，因此真正重要的不是單看速度提升，而是能否接受這筆交換。

OpenRouter 的新路由器不再只挑選輸入 Token 價格最低的供應商，而是估算一次「取得好答案」的實際成本——把價格、等待時間與重試成本一起算進去，再將請求送往 Routing Cost 最低的供應商。

30 秒看懂結論，數據也在這裡

OpenRouter 現在以 Routing Cost 為最佳化目標，不再單純按照提示詞 Token 價格選路。只要請求沒有明確設定 provider.sort、provider.order、provider.only 或 provider.ignore，就會自動套用新路由。根據 OpenRouter 的公告，這項變更涵蓋約 77% 的流量，也就是由多個供應商提供服務的模型。

結果來自為期一週的 switchback 測試，共涵蓋 2,400 萬次請求與 1,030 億個輸入 Token，新舊路由器各分配一半流量。

\*請求占比與事件數下降幅度都來自公告：67% 與 47% 分別指整體 429 事件及整體重試次數的減少，不是命中率的比例變化，因為同一個請求可能遇到多次錯誤。

根據公告，從呼叫端量測的 TTFT p95 由 6,032 毫秒降至 4,504 毫秒，完整請求的 p50 由 4.00 秒降至 3.24 秒，而失敗嘗試浪費的時間則從每次請求 349 毫秒降至 242 毫秒。

結論很簡單：互動式聊天或 Agent 如果能接受約 6% 的成本增加，建議維持新版預設路由；大型批次工作若每一分錢都重要，則切回只看價格的模式。

用白話理解 Routing Cost

Routing Cost 會替每個供應商回答兩個問題：一次嘗試要花多少錢？成功的機率又有多高？OpenRouter 的例子是：一次嘗試成本 $0.40，加上 $0.60 的等待成本，合計 $1.00；再除以 80% 的成功率，得到每次成功回答 $1.25 的成本。成本最低者就會獲得更多流量。

這個數字由三項因素組成：

1. 看實際價格，不看牌價。 OpenRouter 會根據近期流量估算輸入與輸出 Token，再套用每個供應商真實的快取命中率與 Token 價格。公告中的計算範例是：40K 個未快取輸入，按 $2.00/M 計算為 $0.080；60K 個已快取輸入，按 $0.50/M 計算為 $0.030；約 4K 個輸出，按 $8.00/M 計算為 $0.032，總計 $0.142。輸入價格便宜，但快取輸入或輸出 Token 昂貴的供應商，在這裡就沒有優勢。
2. 把等待時間換算成金額。 吞吐量是包含首個 Token 回應時間在內、從頭到尾計算的輸出 Token 每秒數量。例如，等待 5 秒收到首個 Token，接著在 5 秒內輸出 500 個 Token，吞吐量就是 50 tok/s。路由器會根據各模型常見的供應商費用與速度，以每個模型不同的費率換算等待成本。首個 Token 回應時間的權重更高，因為 Agent 的工具呼叫鏈每一步都得等它回來。
3. 計入失敗成本。 429 代表供應商拒絕了請求；你得先等到拒絕結果，再把請求送往其他地方。例如等待 2.50，加上懲罰係數乘以 0.4% 的發生率，會增加 0.01 成本。可靠性錯誤的懲罰更重，約為 8 倍，因此 1% 的錯誤率會讓成本增加約 8%；表現遠差於其他供應商者，在恢復前會停止接收流量。目前品質評分也會檢查工具呼叫是否格式正確——95% 格式正確會讓成本增加約 5%——而被標記的供應商會被降至測試流量，詳見公告。

為避免所有流量集中到同一個贏家，系統設有兩道防線，公告指出：每個供應商都會持續獲得少量流量，讓系統看得到它何時恢復；同時，路由器會對失敗中的供應商降低流量，並持續學習每個供應商的容量上限，把超出的流量分散到其他地方。

為什麼預設路由仍可能在生產環境出問題

使用者回報揭示了四種反覆出現的故障模式，而這些問題不可能只靠每 Token 價格反映出來。

工具呼叫中途切換，Schema 就可能失效

真正讓我的工具呼叫出問題的是請求中途切換，而不是任何單一供應商的表面價格。

— u/Michael_Jeffords，r/openrouter 避免使用哪些供應商討論串

目前的品質評分主要看工具呼叫格式是否正確，以及基準測試準確度標記，詳見公告。不過，對話進行到一半時切換供應商，仍可能改變量化方式或拒答行為，因為供應商品質本來就有差異，有些還會提供量化程度更高的模型版本。

快取失效，帳單跟著膨脹

有一則討論記錄了約 700K Token 的上下文：原本預期每次快取請求只要 $0.20，供應商切換後卻接近 $2.00，形成「因快取損壞而多付 10 到 32 倍」的情況。新版路由會在快取仍有效時，讓同一段對話固定使用原始供應商，並只對第一個請求進行演算法選擇，這是 OpenRouter 的快取感知路由設計；但一旦 fallback 到另一個供應商，這種黏著性就會失效。解決問題的使用者，通常會透過 sticky session 固定一個供應商。

我覺得 OR 有個很根本的問題，就是你得事先手動設定這些東西。

— u/welcome_to_milliways，r/openrouter 快取失效導致費用暴增討論串

悄悄 fallback 到昂貴供應商

一份生產環境報告指出，部分流量在服務狀態仍顯示正常的情況下，悄悄從 Sonnet 轉到標價約貴 5 倍的 Opus，整體支出也從每小時 $184 暴增至 $412，詳見 @CarbonOnX。新版路由把這項取捨攤在檯面上：速度更快、可靠性更高的供應商，確實可能排在最便宜的供應商之前。

付費帳戶仍然遇到 429

OpenRouter 帳戶裡有餘額，並不會增加上游供應商的容量，這則 429 討論串的使用者也提到同樣情況。429 反映的是該供應商針對特定模型的共享資源池限制。這次重建在測試中讓 429 事件減少 67%，但在生產環境，固定供應商或忽略受限供應商仍是實際解法。可以先參考如何修復 OpenRouter 429 錯誤，再查看OpenRouter Auto Router 指南，了解舊版以價格加權的預設路由。

三種真正經得起考驗的路由設定

該選哪種設定，取決於你要的是免手動管理的速度、嚴格的成本上限，還是可預測的行為。三種設定都使用同一個 provider 物件：provider.order 會繞過新版邏輯，嚴格按照指定順序嘗試供應商；provider.only 與 provider.ignore 會先篩選候選者，再由新演算法從剩餘供應商中選擇；任何明確設定的 provider.sort（price、throughput、latency）則會取代新版路由。

1. 維持新版預設值（互動式聊天與 Agent）

不需要修改程式碼。這種模式適合面向使用者的聊天功能，以及多步驟 Agent，因為每次工具呼叫都要等待首個 Token——只要能接受約 6% 的成本增加，就能換取更好的延遲與重試表現。連續記錄一週 API 回應與活動頁面回傳的服務供應商，以及 TTFT p50 和 429 比率：如果你的 429 占比維持在新版約 4% 的基準附近，且快取命中率沒有下滑，就繼續使用；若某個供應商持續主導失敗，或快取命中率大幅崩落，再改用設定 3。

2. 鎖定最便宜的路徑（批次工作與成本受限任務）

如果成本比速度重要，可以用以下三種方式偏好以價格為基準的路由：

{ "provider": { "sort": "price" } }

也可以在模型 slug 後加上 :floor（meta-llama/llama-4-maverick:floor），或在帳戶設定中把預設排序方式設為 price，詳見公告 FAQ。請注意，:floor 也會納入 flex-tier endpoint，而單獨使用 sort 則不會，詳見 OpenRouter 路由指南。

再搭配價格上限：

{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }

適合大型提示詞、短輸出，以及成本低廉的重試。

3. 固定穩定的供應商（需要快取或工具呼叫的生產環境）

當正確性、快取命中率或合規要求比每次請求的最佳化更重要時，就應該固定供應商：

{
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true,
    "require_parameters": true
  }
}

require_parameters 只能排除缺少必要請求參數的 endpoint，無法保證不同供應商之間的工具呼叫或 Schema 行為完全一致。只有在合規或 BYOK 情境下，才建議使用 allow_fallbacks: false 的 order，因為這些情況寧可服務中斷，也不能轉到未核准的供應商。多數應用程式應允許 fallback，再用 only/ignore 縮小範圍，並傳入穩定的 session_id 來重複使用熱快取（sticky routing）。如果某個供應商經常不穩定，就在防護規則中封鎖它，並比較直接呼叫供應商 API 的結果——有幾名使用者表示，模型確定後改用直連，就不再遇到速度緩慢與快取問題（討論串範例）。

自動路由確實比以前更好，但當一次錯誤的中途切換所造成的損失，超過一週稍高的每 Token 價格時，它仍然取代不了固定供應商的做法。

常見問題

要使用新版路由，需要修改程式碼嗎？

不用。沒有明確設定 provider sort、order、only 或 ignore 的請求，都會自動使用新版路由器。

如何維持只看價格的路由？

將 provider.sort 設為 "price"、加上 :floor，或把帳戶預設排序方式設為 price。

新版路由會覆蓋我的 provider order 嗎？

不會。order 會繞過新版路由；only/ignore 會先篩選，接著才由新版演算法挑選。

新版路由會讓成本增加嗎？

請看上方結論表：測試中每 1,000 次請求增加 6.0%，每百萬 Token 增加 7.3%。

如何查看實際處理請求的供應商？

根據 OpenRouter 文件，查看 API 回應中的 provider 欄位與活動頁面。

為什麼付費帳戶仍然會遇到 429？

原因是上游共享資源池的限制，而不是帳戶餘額不足。請固定供應商，或忽略受到速率限制的供應商。