OpenRouter BYOK 費用、Fallback 與金鑰輪替全解析（2026）

明明填入了有效的 OpenAI 金鑰，請求也順利完成，OpenRouter 餘額卻還是下降？這不一定是金鑰設定錯誤。OpenRouter BYOK 並不是單一的計費開關：供應商推論費、平台費，以及 fallback 容量的費用，各自走不同路徑。更重要的是，現行規則已不再採用過去「每月一百萬次請求」的算法。

先釐清：你看到的究竟是哪一筆費用？

OpenRouter BYOK 可讓請求使用儲存在 workspace 中的供應商憑證，同時保留 OpenRouter 作為 API 與路由層。因此，費用可能來自三條不同管道：

排查時，第一個問題不該是「我有沒有加入自己的金鑰？」而是「這次請求最後由哪個供應商實際處理？」即使金鑰已正確設定，也可能因速率限制、上游帳戶餘額不足、權限不符，或供應商暫時故障而失敗。若啟用了 fallback，OpenRouter 可能改由其他供應商完成請求，並從你的 OpenRouter 餘額扣除該路徑的費用；這正是其 BYOK 收費說明所描述的情況。

BYOK 改變了什麼，又沒有改變什麼？

BYOK 會將符合條件的流量透過你的供應商憑證送出，但 API 與路由層仍由 OpenRouter 負責。根據其BYOK 文件，憑證會經過加密，且僅用於導向指定供應商的請求。

BYOK 不代表推論免費。模型用量仍由供應商計費，而適用額度用完後，OpenRouter 可能另收平台費。自備金鑰也不會跳過 workspace、帳戶或單次請求層級的隱私規則；若已沒有可用的合格 endpoint，即便憑證有效，請求依然會失敗。

現行 BYOK 收費看推論金額，不看請求次數

目前的 OpenRouter pricing 頁面，是依推論的牌價金額計算 BYOK 免平台費額度，而不是依請求數量計算：

這項額度依據的是相同模型與供應商在 OpenRouter 的一般牌價，不一定等同於你與供應商議定的實際帳單價格。超出額度後，5% 的 BYOK 費用會從 OpenRouter credits 扣除；供應商帳單則仍是另一筆獨立費用。

帳務上要分開看的三種成本

1. 供應商推論費：由 BYOK 憑證所代表的供應商帳戶支付。
2. BYOK 平台費：超過目前方案額度後，OpenRouter 以 OpenRouter credits 收取 5%。
3. Fallback 推論費：當路由沒有走原先預期的 BYOK 路徑，而是使用 OpenRouter 付費的供應商容量時，由 OpenRouter credits 支付。

購買 credits 的手續費又是另一回事。OpenRouter pricing 列出的 Pay-as-you-go 平台費為 5.5%。單純的儲值扣款，不能證明某一次特定請求曾經走 fallback。

為何搜尋結果仍常看到「100 萬次請求」的說法？

OpenRouter 在 2025 年 10 月的公告中，曾說明每月一百萬次 BYOK 請求免平台費，之後收取 5%。那是當時公告採用的歷史政策；該頁目前也註明，BYOK 定價已於 2026 年 8 月變更。進行估算時，應以現行定價頁面的牌價推論額度為準，並記錄你的查閱日期。

Fallback 決定 BYOK 是硬性邊界，還是彈性路由

OpenRouter 預設優先追求請求成功。其BYOK guide將優先金鑰、OpenRouter 共用 endpoint 與 fallback 金鑰，定義為路由流程中不同的位置：

• 優先 BYOK 金鑰會依設定順序嘗試。
• 這些嘗試失敗後，可能會改試 OpenRouter 的共用容量。
• 標記為 fallback 的 BYOK 金鑰，會在共用 endpoint 之後才嘗試。
• 同一供應商若有多把符合條件的金鑰，也會依順序逐一嘗試。

供應商排序還有一項容易忽略的細節：只要 endpoint 符合 BYOK 條件，即使該供應商在你指定的 order 陣列中排得較後，也會優先於共用 endpoint 嘗試。因此，實際請求可能比你依一般供應商排序規則預期的更早使用 BYOK 金鑰。

可靠性與帳務確定性，只能依需求取捨

Dashboard 中的 Always use for this provider 選項，可避免 OpenRouter 對同一供應商改用它的共用憑證。但它不是全域的「絕不使用 OpenRouter credits」開關。OpenRouter 的支援文章指出，若跨供應商 fallback 仍可用，請求仍可能從 Anthropic BYOK 金鑰轉往其他相容供應商，例如 Google Vertex。

若你需要帳務上的明確性，應直接在請求中限制供應商：

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

使用 provider.only 後，Anthropic 發生故障時，API 會直接回傳失敗，而不是悄悄轉往其他供應商。這很適合受監管工作負載、供應商特定資料協議，或每筆請求都必須對應到單一上游帳戶的成本報表。反過來說，對於重視可用性勝過嚴格供應商歸屬的互動式產品，這通常不是理想預設值。

r/openrouter 中也有使用者描述相同的控制方式：

「你可以直接在請求中指定 order/only providers，強制只使用自己的 BYOK。」 — u/Randomdotmath，Reddit thread

如果 fallback 是你可靠性設計的一部分，就應將其成本納入預算；如果不是，應在請求邊界將它關閉。

先看 Activity 的實際路由，再判斷費用原因

OpenRouter 的FAQ指出，Activity 可查看用量歷史，並依模型、供應商與 API key 篩選。建議依序檢查：

1. 實際服務供應商：是否與 BYOK 憑證綁定的供應商一致？
2. 模型與 endpoint：路由器是否選擇了另一個相容 endpoint？
3. 應用程式 API key：這次請求來自哪個環境或 workspace 金鑰？
4. Credit 扣款：扣除的是推論費、BYOK 費用，還是與儲值相關的餘額變動？

若 Activity 顯示的供應商不同於 BYOK 供應商，應先調查 fallback，而不是立刻更換憑證。若供應商一致、用量又接近方案額度，才應檢查 BYOK 平台費。這能避免為了解決路由政策問題，卻誤把有效金鑰拿去輪替。

適合正式環境的金鑰配置與輪替方式

OpenRouter 應用程式金鑰與上游 BYOK 憑證，是兩種不同秘密，應由不同角色負責管理：

建立並測試 BYOK 憑證的基本流程

在排查正式環境流量前，先走完這條簡短流程：

1. 在 workspace 的 BYOK 設定加入供應商憑證，或透過 BYOK management API 建立。
2. 為憑證命名時，清楚標示供應商、環境與用途。
3. 在分享 workspace 憑證前，先設定模型、OpenRouter API-key 或成員篩選條件。
4. 將金鑰放入優先區段；只有在已明確定義其計費與故障應對角色時，才加入 fallback 金鑰。
5. 送出測試請求，在 Activity 確認實際服務供應商，再決定是否保留共用 fallback。

對雲端供應商而言，憑證彼此並不能任意替換：

這些限制來自 OpenRouter 的供應商專屬 BYOK 文件。金鑰本身有效，但資源類型、區域、deployment 或權限不正確，代表的是設定失敗，並不表示 BYOK 不支援該供應商。

OpenRouter 的 BYOK 設定支援以模型 slug、OpenRouter API-key hash 與 workspace 成員篩選。憑證要符合資格，每一項啟用中的篩選條件都必須匹配；文件也說明，每個篩選器最多可設定 100 筆項目。建議採用明確 allowlist，大型團隊應拆分 workspace，而不是持續把單一憑證的適用範圍越放越寬。

不動供應商金鑰，零停機輪替 OpenRouter application key

OpenRouter 的API key rotation cookbook說明，BYOK 供應商憑證是與 OpenRouter 帳戶綁定，而不是綁定某一把 application key。其零停機輪替順序如下：

1. 建立一把新的 OpenRouter application key，使用易辨識名稱並設定合適限制。
2. 將新金鑰存入 secrets manager，部署至所有仍在使用舊金鑰的服務、工作與環境。
3. 透過 Activity 確認正式環境流量已使用替換後的金鑰。
4. 待遷移完成後，才刪除舊金鑰。

Management API 文件指出，Management API key 屬於管理用憑證，不能呼叫 completion endpoint。在撤銷舊 application key 前，新的替換金鑰必須已可正常使用。

供應商憑證要獨立輪替

供應商金鑰輪替是另一項變更，應遵循供應商自身的憑證政策，並測試工作負載實際使用的模型、區域、權限與配額。

1. 在上游建立替換憑證，並只授予所需的最小權限。
2. 以不同名稱和受控優先順序，將它加入 OpenRouter BYOK 連線。
3. 送出測試請求並檢查 Activity。
4. 將替換憑證移至主要位置，同時觀察錯誤與供應商用量。
5. 重疊使用窗口結束後，在上游撤銷舊憑證。

這套順序是根據 OpenRouter 已記錄的優先順序行為提出的操作建議；供應商本身的撤銷規則仍具最終效力。OpenRouter 的BYOK create API可接收原始憑證，但說明中指出它會靜態加密，且不會在後續 API 回應中再次回傳。原始憑證仍應保存在你自己的 secret manager，因為 OpenRouter 並不是備份或復原來源。

哪些情況不該把 OpenRouter BYOK 當預設選項？

若你更重視單一供應商的原生 logs、精確 endpoint 行為或廠商工具，直接使用供應商 API 是較好的預設選項。若你需要整合多個供應商帳戶、既有的供應商 credits 或承諾容量，以及 workspace 層級控管，BYOK 則更適合。

OpenRouter BYOK 常見問題

使用自己的金鑰，OpenRouter 還會收費嗎？

會。供應商仍可能針對 BYOK 憑證的推論用量計費；超過目前方案額度後，OpenRouter 可從 credits 扣除 5% 的 BYOK 平台費；若發生 fallback，也可能改由 OpenRouter credits 支付其他供應商路由的費用。

「Always use for this provider」會停止所有 fallback 嗎？

不會。它會阻止 OpenRouter 對指定供應商使用自己的共用憑證，但無法阻止請求改由另一個相容供應商處理。若跨供應商路由必須完全不可能，請使用 provider.only。

企業如何管理 BYOK 的安全性與預算？

OpenRouter 表示憑證會加密、原始供應商金鑰不會透過 management API 回傳，而且 BYOK 支出預設不計入 guardrail 與 workspace 預算。其BYOK 文件指出，若需要合併預算，應啟用 Include BYOK spend 或 include_byok_in_budgets。企業團隊也應採用最小權限憑證、workspace 隔離、篩選器、secret manager 保管、定期輪替與 Activity 檢視。

預設配置應由你最不能接受的失敗來決定

請依據你最無法妥協的條件來選擇路由與預算控制：是請求一定要完成、供應商歸屬必須固定，還是成本可見性必須完整。