AIREITEROpenRouter 的模型頁面上，Fusion 請求看起來可能是免費的，但實際費用卻可能是一般 completion 的數倍。原因很簡單：OpenRouter Fusion 的定價，是多次底層模型呼叫的總和，而不是獨立的單一 Token 費率。面板規模與 Token 用量，決定了這份額外審查是否值得付費。
先用一個判斷掌握 OpenRouter Fusion 定價
相較於直接呼叫一次同等級模型，OpenRouter Fusion 通常更貴。OpenRouter 的 Fusion Router 文件指出，預設配置包含三個模型的面板，以及一次分析器呼叫；以相同 Prompt 進行比較，整體成本約是單次 completion 的 4–5 倍。
如果面板的品質能減少後續審查工作，Budget 面板可能比 Premium 模型更划算。但 Fusion 的本質是「成本換驗證」的取捨，不能直接當成更便宜的模型。
| 情境 | 較適合的預設選擇 |
|---|---|
| 簡短、例行且低風險的請求 | 單一模型 |
| 存在相互競爭證據的研究工作 | 視情況使用 Fusion |
| 高流量或對延遲敏感的請求 | 單一模型或針對性升級 |
| 錯誤代價高昂，或需要人工審查 | 先試行 Fusion，再量測節省的成本 |
計費單位是一整層呼叫堆疊，不是 Fusion Token
OpenRouter 的 Fusion API 頁面將 Fusion 定義為 Router，並顯示該 Router 別名的 Prompt 與 completion 價格為零。這代表 Fusion 本身沒有獨立的單一費率，不代表底層推論完全免費。
文件描述的執行流程如下：
- Prompt 會傳送給每個選定的面板模型。
- 分析器或評審模型會比較各個面板的回應。
- 外層模型產生最終答案。
估算預算時，可以使用以下公式：
Fusion cost = sum(panel model costs)
+ analyst/judge cost
+ any final outer-model cost shown for your integration實際計費方式取決於你是以 openrouter/fusion 模型別名，還是以 openrouter:fusion Server Tool 呼叫 Fusion。不要根據 Router 顯示的 $0 項目，推斷最後的帳單金額。請查看實際的 generation 與 OpenRouter Activity 紀錄。
OpenRouter 文件支援 1–8 個分析模型，預設面板則包含三個模型。由於 Quality、Budget 與自訂配置各有不同，因此不存在一個適用所有情況的 Fusion 每百萬 Token 統一價格。
面板規模會讓帳單近似線性增加，但評審成本還會跟著膨脹
如果每個面板模型收到相同的 Prompt，產生的輸出量也大致相同，那麼每增加一個面板成員，就等於多增加一次模型呼叫。OpenRouter 也明確指出，成本會隨面板規模線性增加。
不過，單看呼叫次數仍會低估評審成本，因為評審模型的輸入會隨面板輸出增加：
C(n) = n × Cp + Cj(n) + Co其中 n 是面板模型數量，Cp 是每個面板回應的平均成本，Cj(n) 是包含遞增輸入成本在內的評審成本，而 Co 則是在適用時的外層回應成本。
| 面板規模 | 面板呼叫 | 分析器呼叫 | 外層回應前的簡化呼叫堆疊 |
|---|---|---|---|
| 1 | 1 | 1 | 2 次呼叫 |
| 2 | 2 | 1 | 3 次呼叫 |
| 3（預設） | 3 | 1 | 4 次呼叫 |
| 4 | 4 | 1 | 5 次呼叫 |
| 5 | 5 | 1 | 6 次呼叫 |
| 8（上限） | 8 | 1 | 9 次呼叫 |
因此，預設三模型面板的 4–5 倍估算，比 Router 顯示的 $0 更適合作為規劃基準。當評審模型價格較高、輸出較長，或外層模型又增加一次付費 completion 時，實際倍數還可能進一步上升。
用可調整費率實際算一次
你可以把這份工作表套用到所選模型的即時費率。以下數字只是示意，並非 OpenRouter 的價格：假設每個面板答案包含 10,000 個輸入 Token 與 2,000 個輸出 Token，評審模型則有 6,000 個輸入 Token 與 1,000 個輸出 Token。
Panel input = 10,000 × sum(panel input rates)
Panel output = 2,000 × sum(panel output rates)
Judge input = 6,000 × judge input rate
Judge output = 1,000 × judge output rate
Fusion total = panel input + panel output + judge input + judge output如果單一模型基準同樣處理 10,000 個輸入 Token 與 2,000 個輸出 Token，就可以直接將它的總成本與這份工作表比較。以三模型面板為例，Prompt 會被計費三次，而評審模型在這個示例中還會讀取一份 6,000 Token 的獨立內容。若你的 Prompt 或答案更長，記得同步調整假設。
在各次模型呼叫成本相同的簡化假設下，呼叫次數的變化如下：
| 配置 | 面板小計 | 分析器 | 標準化總成本 |
|---|---|---|---|
| 單一模型 | — | — | 1× |
| Fusion，1 個面板 | 1× | 1× | 2× |
| Fusion，3 個面板 | 3× | 1× | 4× |
| Fusion，5 個面板 | 5× | 1× | 6× |
| Fusion，8 個面板 | 8× | 1× | 9× |
這些不是 OpenRouter 的實際價格，而是用來說明：即使模型費率尚未納入差異，面板數量本身就會影響成本。便宜的面板可能遇上昂貴的評審模型，反過來，前沿面板模型的費用也可能遠高於評審成本。
Token 用量會從兩個方向拉開成本差距
相較於單次呼叫，Token 用量對 Fusion 的影響更大，因為 Prompt 會被重複處理，而評審模型還會接收面板產生的答案。
1. 面板會重複計算輸入 Token
令 I 代表 Prompt Token 數量，Pi 代表面板模型 i 的輸入價格：
Panel input cost = I × (P1 + P2 + ... + Pn)一份 10,000 Token 的 Prompt 傳給三個面板模型，就會產生三筆底層輸入費用，而且三者的費率可能各不相同。
2. 輸出 Token 也會隨面板數量增加
如果每個面板產生 O 個輸出 Token，整個面板大約會產生 n × O 個輸出 Token。若計費中包含推理 Token，成本差距還可能超過可見答案的長度所呈現的幅度。
接著，評審模型還要讀取這些輸出：
Judge input ≈ original prompt + n × panel output + orchestration overhead因此，答案越長，成本不只會增加在每個面板回應上，也會增加評審模型的輸入內容。
| 工作負載形態 | Fusion 的成本壓力 | 實務上的做法 |
|---|---|---|
| 短 Prompt、短答案 | 面板呼叫次數是主要成本 | 除非已證實品質提升，否則維持小面板 |
| 長 Prompt、短答案 | 重複輸入是主要成本 | 仔細比較輸入費率 |
| 短 Prompt、長面板答案 | 評審輸入快速增加 | 限制 completion 與推理預算 |
| 長研究 Prompt、長答案 | 兩種效應疊加 | 只有在節省的審查成本足以抵銷時才使用 Fusion |
| 大量重複的相同任務 | 每次請求都會重複整個呼叫堆疊 | 單一模型通常是較合理的經濟基準 |
估算每月成本時，可以使用以下公式：
Total monthly cost ≈ requests × (panel input + panel output
+ judge input + judge output
+ outer response)請使用面板中各個具體模型 ID 的最新費率。「Budget」只是預設配置的名稱，不代表總成本一定會低於每一個單一模型。
該選 Budget、Quality，還是單一模型？
當速度、可重複性與可預測的計費，比獨立審查更重要時，就選單一模型。格式化、資料擷取、自動完成、例行改寫，以及許多一般的程式設計 Prompt，都適合採用這種方式。
如果漏掉問題的代價很高，則可以考慮 Fusion，例如來源密集型研究、專家批評、盡職調查，或存在相互競爭證據的決策。先從能回答問題的最小面板開始。三個模型是文件記載的預設值；八個模型是上限，不是建議配置。
真正該比較的是：
incremental Fusion cost
versus
avoided correction cost + saved human review time + reduced error exposureOpenRouter 的另一篇基準測試公告公布了 100 個任務的 DRACO 評估結果，其中 Frontier Fusion 配置的結果為 69.0%，Budget 面板則為 64.7%。這些數字支持的是深度研究用途，不能視為所有 Prompt 的轉換率，也不能證明面板越大就一定越省錢。
擴大規模前，先把數字查清楚
第一次部署 Fusion 時，應該把它當成一次測量工作。請記錄：
- 面板模型 ID 與評審模型 ID。
- 在系統提供的情況下，記錄輸入、輸出與推理 Token 用量。
- 確認 Fusion 是否實際執行的 Router 中繼資料。
- 總成本與延遲。
- 最終答案是否減少人工修正。
Fusion 文件表示，generation metadata 可能包含 "router": "openrouter/fusion"。一般的 model 欄位只會指出處理請求的具體模型，不足以證明 Fusion 確實執行。
以下是一則使用者回報，也反映了配置上的風險：
「這個 \"Fusion\" 還是會呼叫 Opus 4.8 當評審。我找不到停用它的方法。」— X 上的 @teortaxesTex
這是使用者回報，不是 OpenRouter 的定價規則。它說明了：即使面板成本低，如果評審模型昂貴，或實際配置與預期不同，也不能保證整次執行的費用低廉。
在正式環境中，若 API 允許，請固定面板與評審模型，設定預算上限，並把 Fusion 設計成明確的升級路徑，而不是讓每個自主請求都使用它。
OpenRouter Fusion 定價 FAQ
Fusion 比單一模型便宜嗎？
通常不會，至少相較於價格相近的單一模型是如此。不過，如果 Budget 面板能提供足夠品質，可能會比 Premium 模型便宜；最終結果仍取決於面板費率、評審成本與 Token 用量。
OpenRouter Fusion 是免費的嗎？
Router 別名的 Prompt 與 completion 欄位可能顯示 $0。但 OpenRouter 另有說明，底層面板與評審 completion 仍會計費，因此不應假設一般 Fusion 請求的成本為零。
一次 Fusion 請求會產生多少次呼叫？
文件記載的流程是 N 次面板呼叫加上一次分析器呼叫，至於最後的外層回應，則取決於整合方式。預設的三模型面板配置，文件描述為約等於一次可比較 completion 的 4–5 倍。
面板越大，價值一定越高嗎？
不一定。增加模型可能帶來更廣的覆蓋範圍，但同時也會增加面板費用、評審輸入、延遲，以及彼此相關的錯誤。只有在留出來的測試顯示品質提升所節省的成本高於新增費用時，才應擴大面板規模。
如何估算 OpenRouter Fusion 的成本？
列出所有底層模型呼叫，按照預期 Token 用量乘上目前的輸入與輸出費率，將包含面板輸出的評審輸入納入計算，然後在實際發出請求後，於 Activity 中核對結果。第三方計算器可以協助模擬不同情境，但 OpenRouter 的即時費率與 Activity 紀錄才是最終依據。
實際該怎麼做
先把單一模型當作基準。準備一組包含 20–50 個 Prompt 的留出測試集，分別交給基準模型與小型 Fusion 面板處理。只有在減少的事實修正、補回的遺漏證據，或節省的審查工時，足以支付額外面板與評審 Token 成本時，才保留 Fusion。
對多數團隊而言，最務實、也最重視成本的導入方式是：例行流量使用單一模型；不確定或高成本的決策使用小型 Fusion 面板；只有在量測到的效益經得起帳單考驗時，才採用更大型的面板。