OpenRouter 與混合模型工作流程研究

查核日期：2026-09-17（台灣）｜公開方法版｜文件研究，未執行付費模型評測

值得試行：保留主力訂閱，加上有預算上限、可以獨立運作的 API 工作池。

目標是提高交付品質、減少返工，並在訂閱額度耗盡時保有工作能力。OpenRouter 可以統一模型供應與路由，但效果取決於任務拆分、交接資料、驗收及成本控制。本文的模型是試測候選，並非已驗證的勝出者。

1. 先保留有價值的分工

現有本機助手若已有佇列、快取、來源驗證，應在其上新增可選後端，避免另建一套工作系統。規則能回答的分類先走規則。這是本研究的工程建議，仍需用實際任務證明效益。

2. 三種「路由」不能混為一談

1. 供應商路由：同一模型挑不同供應端，改善價格或可用性；不是改用更適合的模型。可用 require_parameters 與單價限制篩選端點。官方說明
2. 自動選模：openrouter/auto 依任務分類及近七天市場支出排序，再套用成本級別與允許模型清單。這是群體使用訊號，不是針對自己的中文工作品質測驗。新版使用 cost_tier；舊 cost_quality_tradeoff 已淘汰但保留相容。官方說明
3. 工作流程路由：由自己的程式依任務、風險、資料權限與驗收結果決定模型。第一階段最適合採這種明確分工。

API 成功回傳不代表內容正確。OpenRouter 的錯誤 fallback 不會自動判斷「待辦漏了一條」並交給更強模型；品質升級要另外設計。fallback 文件

建議先固定少量模型建立基準，再用同一批測例評估 Auto Router。自動路由的成本級別是價格帶，不是整筆任務的費用上限。市場排序會變，固定版本比較容易追查品質變化。

3. 省的是 API、額度，還是總支出？

訂閱費不變且仍有可用額度時，改走 API 會增加現金支出；效益可能是延後額度用盡、縮短等待、避免升級與少返工。訂閱的 API 牌價換算值不等於實際帳單。OpenAI 官方也把訂閱用量與 API 按量收費分開。Codex 定價

OpenRouter 按量方案目前列平台費 5.5%，模型推論費另計；Auto Router 不另收路由費，但仍付所選模型費用。實際付款、最低費、稅與匯率以結帳為準。平台定價

以上只是固定 token 數、無快取、無工具、無額外 reasoning 費用的單次算例。同一文本在不同模型的 token 數也可能不同。單價差不代表品質相同；價格是查核時的頁面標示，端點與條件可能不同。

假設 1,000 個任務先全部跑 Flash-Lite，其中 20% 驗收不過，再以完整同尺寸輸入跑 Sonnet：推論費為 US$2.80＋US$18＝US$20.80；全跑 Sonnet 為 US$90。這是約 77% 的推論費理論下降，尚未計驗收、重試、路由額外上下文與維護，也完全不能解讀為訂閱費省 77%。若只示意加上 5.5% 平台費，兩者約為 US$21.94 與 US$94.95。

真正比較式：混合月成本＝現有訂閱＋新增 API＋工具與主機費＋返工／維護時間成本。升級月成本＝新訂閱＋升級後仍需的其他費用。新增 API 的合理上限，應低於升級價差並留有維護餘裕；必須先確認實際帳單，不能把舊記憶中的月費當現況。

4. 兩條工作路徑，分開建置

A. 平時分流：節省主力模型的閱讀與整理

每個子任務帶明確輸入、輸出 schema、來源範圍與截止條件。主力只接收短結果、來源索引、尚未解決的問題；抽樣回查原文，重要結論仍讀原文。若主力最後又重讀全文、重做全部工作，通常省不到額度。

B. 額度耗盡：獨立執行入口與完整交接

額度用盡時，不能仍依賴原主模型來拆任務。必須提前保存任務目標、完成步驟、未完成項目、檔案／版本、驗收指令，並提供可直接啟動的備援 CLI 或 agent。純摘要 worker 不能代替會操作工具的 agent。第一次試行只接沒有外部寫入的工作；有日曆、訊息與部署等副作用的任務，要以 task id 和執行狀態避免重複操作。

快取可降低重複前綴處理成本，但依模型與供應端而異；頻繁換模型／端點可能破壞效益。API worker 不會自動取得現有工具、記憶與權限，這些必須明確提供。快取文件

5. 預算與資料邊界要做到程式裡

• 先用獨立 API key、小額總預算、關閉自動加值。新台幣 300～600 元可作第一輪討論預算，這是建議，尚未授權支出。
• 路由服務記錄 task id、模型／供應端、input／output／reasoning／cached tokens、實際費用、延遲、重試與人工修正時間。
• 工作開始前預留最大預估費用，併發共用原子預算帳；結束後依實際帳務結算。每任務限制輸出、重試與總費，不能只檢查「目前累計還沒超額」。單價上限也不是月預算上限。
• 連線或供應端錯誤與內容驗收失敗分開處理；必要時只升級一次。最多三次嘗試後回報失敗，不無限重跑。
• 先用公開或去識別化樣本。需要時限制 provider、禁用資料蒐集並要求 ZDR；ZDR 對推論端點生效，不自動涵蓋搜尋等插件，仍須核對資料政策。官方 ZDR 邊界

6. 用 30 個真實任務決定，不靠模型排行榜

建議試行 7～14 天。取逐字稿抽取、跨文件整理、固定格式改寫各 10 件。保留長文本、否定句、多人角色、數字與日期等難例，遮蔽必要個資。由人工標註關鍵項目與來源，先鎖定標準，再比較既有流程、本機模型、固定便宜 API，以及通過前測後的受限 Auto Router。

1. 先看品質：關鍵數字、日期、角色不能出錯；抽取完整度目標至少 95%。引文存在只能證明可回查，不能證明理解正確。這些是建議門檻，不是已測結果。
2. 再看可直接採用率：建議至少 90%，平均人工修正時間不能高於目前流程。先盲評，不讓模型品牌影響判斷。
3. 算完整任務成本：所有失敗、驗收與升級成本均計入，分母為真正通過的任務數。同時計主力整合成本，不只計便宜 worker。
4. 看主力額度：以官方用量與同類工作量對照，記錄模型、日期及其他同時工作；API token 無法直接換算訂閱百分比。沒有隔離干擾的數字只能當趨勢。
5. 演練備援：不呼叫主力模型，從 checkpoint 啟動替代 agent，完成一個檔案任務並通過驗收，證明額度耗盡時仍能工作。
6. 採用決策：品質不降、返工不增、備援可用，且追加費用小於可接受預算／升級差額才擴大。只省幾美元卻多出大量維護就停止。

30 件只能做初篩；正式接管重要工作前，要逐步擴樣並觀察一個完整計費週期。低風險工作抽查，正式交付完整審閱，避免每個小任務都再叫高價模型重做一次。

7. 其他方案與導入順序

優先順序：訂閱內分級與縮短上下文 → 既有任務工具接一個便宜 API 做評測 → 建立獨立備援入口 → 達標後擴大。研究不等於已批准付費、切換主模型或部署。