如何在 OpenRouter 上控管團隊的 AI 支出

你團隊的 AI 付費是每位工程師持有的所有金鑰總額。一位開發者為側面實驗建立了一把金鑰。另一位則將幾把金鑰接入 CI pipeline。還有另一人將 token 貼進筆記本，讓原型運作，卻忘了金鑰仍在啟用。

單獨來看這些行為並不粗心，但將它們累加後，帳單就難以說明。OpenRouter 提供 6 個控制項，能讓費用井然有序，本文將逐一說明每個控制項、適用團隊以及所需方案。

這些控制項是層疊式的。先選擇最便宜、能覆蓋風險的那一項，只有在需要時才再加。若兩個控制項重疊，較嚴格者為主。允許清單相交時，較低預算先被阻擋。

在 OpenRouter 上最快速的團隊 AI 付費管控方式是什麼？

先選擇最便宜、符合團隊風險的控制項，再逐層加上。小團隊通常只需設定每把金鑰的限額以及第一天就啟用 Activity 儀錶板。

每個控制項都有三項職能。預算與每把金鑰限額決定可支出的金額；模型與供應商允許清單決定可支出的物件；Activity 儀錶板顯示誰花了錢。這 6 個控制項分佈在這三項職能上並協同運作，因此通常不需要一次使用全部 6 個。

控制項對照表

從上往下閱讀。先列出阻止開支的控制項，最後列出追蹤開支的控制項。除工作區預算（需 Enterprise）外，所有控制項均可在免費與按需付費方案中使用。

實務設定通常會至少配合一個阻止控制與一個報告控制。例如，生產服務金鑰會有每月上限，而活動儀錶板則告訴你該服務是否真的在產生支出。若某位開發者需要比其他人更嚴格的模型白名單或預算，為該成員新增一條防護線。

你實際上在付費的是什麼？

在設定任何控制前，先了解實際支出會很有幫助。我們不會加價供應商價格，因此模型目錄中的價格即為推論成本。平臺費用會在購買信用時收取（標準即付即用卡片充值收 5.5%，最低 $0.80），並非每一次請求都收費。失敗的請求則不會產生任何費用。

因此沒有隱藏加價需要管制。這些控制的工作僅是限制團隊實際執行的推論量。

模型目錄列出了你將要限制的每個模型費率。

Bring-your-own-key (BYOK) 的支出行為不同

BYOK 花費並不總是按預期計算，使用前請先確認。若透過自己的供應商金鑰進行路由，我們會收取模型成本的 5% 服務費。免費額度依方案而定，並以列表價格推論成本衡量。請參閱 定價頁面 瞭解目前的額度細節。

工作區預算與防護牆預算預設僅計算 OpenRouter 信用支出，因此若團隊主要使用自有供應商金鑰，實際預算覆蓋的費用會少於表面看起來的。每個預算都有一項 Include BYOK spend 設定 (include_byok_in_budgets)，可開啟以讓 BYOK 推論也計入上限。

讓每筆請求更便宜是與限制團隊支出不同的議題。請參閱 供應商路由成本 與 提示快取。

如何限制單一 API 金鑰的支出？

每金鑰限制是最簡單的硬性上限。它限制單一 API 金鑰，且不需組織即可使用。

當您想限制單一工程師、服務、環境、原型或承包商金鑰時使用。測試金鑰可設定小額每日上限；生產服務金鑰可設定較大月度上限；臨時評估金鑰可每週重置，讓實驗在審查結束後停止消費。

您可以在儀錶板或透過 管理 API 設定上限，該 API 可建立、輪換、更新與停用金鑰。這表示內部配置流程可於發行時即為每個金鑰設定上限，而不必等後續再由人員新增。

缺點是每金鑰限制僅限制金鑰本身，無法限制個人。若一人擁有 5 個金鑰，每個都有每日上限，他可累計花費 5 個上限。金鑰無法得知其他金鑰。每金鑰限制也不涉及使用者可使用的模型或供應商。

先從每金鑰限制開始。若需要跟隨個人或結合預算、模型、供應商或隱私限制的規則，請轉向防護牆。

防護牆如何控制預算、模型與隱私？

一個 防護牆 是隨著個人或金鑰的政策。

一個防護牆可包含預算上限、模型白名單、供應商白名單、Zero Data Retention 規則、prompt-injection 與 jailbreak detection、sensitive-info handling，以及自訂 regex filters。將其指派給組織成員，即成為該成員所有金鑰的基準；或直接將防護牆指派給單一 API 金鑰以實現精細控制。

當「限制此金鑰」不足以達成需求，而實際規則是「此人只能使用這些模型、在此預算內、遵守此隱私規則」時，請使用防護牆。

平臺團隊通常會到此階段，因為不同小組需求不同。貴組織的一組在生產環境使用前沿模型，推理準確度比價格更重要；另一組執行批次工作，依賴大量處理並可使用較便宜模型；第三組需處理可能含敏感資訊的輸入，且需要 ZDR。防護牆可一次設定這些規則，而非讓每個應用團隊自行寫入政策。

我們遵循一條簡單的分層規則：較嚴格者優先。在圖中，請求所包含的層級為您的帳戶設定、工作區預設、指派給成員帳戶的防護牆，以及直接指派給 API 金鑰的防護牆。所有層級結合成一個有效的請求政策。

當多個安全防線同時套用於一次請求時，其存取權會受最嚴格規則限制。模型與供應商的白名單亦採相同原則。例如，若帳號基線允許10種模型，但 API 金鑰安全防線只允許其中3種，則該金鑰只能使用3種模型，而非10種。供應商白名單亦同理。對於 ZDR，若任一層級為某模型群組開啟，則即為開啟。

當多層設定敏感資訊過濾器時，全部都會生效；若其中一層阻擋請求，而另一層僅做遮碼，則阻擋規則優先。預算亦會分別檢查。若團隊設定了成員級別預算與金鑰級別預算，兩者不會合併成一個池，請求必須同時符合兩項預算。

對於控制預算的安全防線，執行方式為以使用者與金鑰為單位，且不共享。這表示安全防線預算會獨立套用於你指派的每位成員與每把金鑰。若你將相同每日預算安全防線分配給三位成員，三位成員各自獲得獨立預算；不會共用一個大池。當金鑰向 OpenRouter 傳送請求時，使用量會同時計入該金鑰的預算以及擁有該金鑰的成員預算。

這是使用安全防線而非僅限於金鑰的主要原因。透過安全防線，你可以輕鬆限制某人所有金鑰的總支出，同時仍能針對特定應用程式的單一金鑰加強限制。

以下是幾點須知。於組織內，僅管理員能管理安全防線（個人帳號亦可為自己的金鑰建立安全防線）。請注意，隨著模型政策變更，白名單亦需維護。預算用盡時，呼叫者會收到 403 錯誤，而非先前警告。

何時應使用工作區預算？

當你需要對整個工作區設定硬性上限時，請使用工作區預算，無論其中有多少金鑰。為每日、每週、每月或終身視窗設定 USD 上限，並且 OpenRouter 在達到上限時以 403 封鎖請求。這樣即可一次性限制整個環境，無需逐一管控內部金鑰。

方案層級限制

工作區預算是企業功能，由您組織的管理員建立與管理。按鑰匙限制與防護閘在免費與 PAYG 計畫中都適用，但工作區預算則不行。如果您未使用企業版，則以每位成員的防護閘預算來限制團隊開支。

工作區如何適用

工作區能將一個團隊的設定與另一個團隊分開。每個工作區都有自己的金鑰、保護閘、BYOK、路由、預設、外掛、可觀測性、成員與預算。然而，計費、管理金鑰與隱私設定位於帳戶層級，活動與日誌則是帳戶層級的檢視，您可按工作區過濾。因而，工作區預算實際上一次性限制通過該工作區的所有專案，且僅管理員能建立或刪除工作區。

以下是一些須知的限制：

• 每個較短的時間窗必須有較小的預算。 生命週期預算必須大於每月預算，月度預算必須大於每週預算，週度預算必須大於每日預算。
• BYOK 請求。 使用您自己的供應商金鑰（BYOK）的請求，因而不消耗任何 OpenRouter 積分，預設不計入預算。啟用工作區的 Include BYOK spend 設定即可將其計入。
• 已經在執行中的請求。 在預算達到時仍在執行中的請求將允許完成。因此實際支出可能略高於預算，直到下一個請求被阻止。
• 尚無電子郵件或 webhook 警報。 當請求被阻止時，呼叫者將收到 403，您可以透過前往工作區設定來檢查預算狀態。

欲瞭解完整規則與實作細節，請參閱 工作區預算檔案 與 企業快速入門。

預設能否控制團隊的支出？

不直接。預設設定請求的預設行為，但不會自動限制其成本。這也是為什麼它們位於上述三個硬性上限之下：每鍵限制、護欄預算與工作區預算。

預設是一種命名的配置，引用為 @preset/slug，可包含模型選擇、備援模型、供應商路由、系統提示語與生成引數。團隊不必在每項服務中硬編碼這些選擇，而是將請求指向共用預設並在一處更改配置。

許多 AI 支出浪費始於過時的配置。一項服務將昂貴模型鎖定於不再需要的任務；另一項忘記按價格排序供應商；第三項保留舊提示語，造成沒人使用的上下文浪費代幣。預設讓平臺團隊有一處可以修正預設。

例如，團隊可以建立一個「support-triage」預設，使用成本適當的模型，設定 provider: { "sort": "price" }，並在各應用中保持系統提示語一致。當團隊需要更改模型或路由政策時，可以更新預設，而非在多個服務中釋出程式碼。

限制在於預設僅引導行為而非強制。請求可以透過傳送自己的引數覆寫任何預設值。因此預設適合標準化行為良好的應用，而非阻止傳送不同引數的呼叫者。

組織與角色如何控制誰能支出？

組織將所有人支出集中於一個共用信用池，並決定誰來控制。所有成員從 中央帳單 取用。僅管理員能購買信用並設定帳單、供應商及隱私設定。成員自行建立金鑰，只能檢視自己的。

當兩人以上共用 AI 支出且想要一張帳單與一組管理員時，請建立組織。

有兩種角色，Admin 與 Member。管理員擁有支出授權，成員則在此範圍內操作。沒有更細粒度的子團隊許可權。全組織預設與護欄允許管理員設定適用於整個組織的預設。

組織有一些限制，您需要了解：

• 一個 組織最多 10 名成員 - 如需提升上限，請聯絡支援。
• 將個人信用轉入組織可自助於信用頁面，並須符合資格規則（帳戶與會員年齡、最近購買的信用以及冷卻期）。以發票計費的組織無法接收轉移。
• 無法將個人帳戶轉換為組織。
• 組織內的隔離來自工作區，而非角色。每個工作區擁有自己的金鑰、護欄與預算，組織則保留一張帳單。

活動儀錶板能顯示哪些團隊支出資訊？

The Activity 儀錶板是每個其他控制項之下的報告層。每個 API 回應都包含一個 usage 物件，其中包含 token 數量和成本，另外每個 key 也會顯示每日、每週和每月的使用總量。在組織中，Activity 儀錶板會顯示跨成員的使用情形，匯出可按 Model、API Key 或 Creator（組織成員）分組。這是你可以查到誰在使用哪個模型花了多少的地方。

一件值得注意的事：在組織環境中，activity feed 會將每位成員的使用元資料顯示給每位成員。它涵蓋模型、成本和時間，但不包含提示或回應。成員無法將 feed 限縮為僅自己的活動，這對共享責任有益，但對於期望在共享組織內保有隱私的團隊來說可能會感到驚訝。

另外一件事：新增更多 key 或帳號並不會提升你的速率限制。速率限制與消費限制是不同主題；請參閱 rate-limits reference。

哪些控制項適合你的團隊？

以下是一個決策啟發式，將下列控制項匹配到你的情境。預設選擇最便宜且能完全覆蓋風險的選項，除非有其他理由。只有在你真正需要為整個環境設定硬性上限時，才考慮 Enterprise workspace 預算。以下每一行皆為一項決策：

• Solo 或 side project。 每個 key 的信用額度並配合每月重置，即可滿足需求。
• 小團隊，一張帳單（10 人以下）。 使用組織以共享資源池、每 key 限額，以及 Activity 儀錶板檢視誰在花費什麼。若某人需要不同的存取許可權或預算，請加入 guardrail。
• 多個團隊，或 staging 與 prod。 使用工作空間將它們分開，為每位成員或 key 設定 guardrail 以管理預算、設定模型 allowlist，以及 presets 以標準化設定。如在 Enterprise，請加入工作空間預算。
• 受監管或敏感資料。 Guardrails 搭配每個模型群組的 ZDR、PII 過濾器，以及 provider allowlist。我們符合 SOC 2 Type 2，但不提供 HIPAA 商業夥伴協議 (BAA)，因此需要 BAA 的健康資料工作負載目前不符合此特定需求。

無論你的團隊目前為何，先從簡單開始。立即設定每 key 限額，並在團隊規模或合規性需要時加入 guardrail 與工作空間預算。若想要點選式設定，請參照 team spend controls setup guide。

常見問題

我可以在 OpenRouter 為每個 API key 設定消費上限嗎？

可以。每個 API key 可以在任何計畫（免費或付費）下設定 limit 個信用額度，並且可設定 limit_reset 的每日、每週或每月限制。超過限制的請求將被拒絕，你可以透過 GET /api/v1/key 讀取剩餘餘額。

如何為整個團隊設定消費上限？

這取決於你的計畫。對於免費與即付制計畫，為每位成員或 key 指派一個帶預算的 guardrail。每位成員與 key 都有自己的預算，超過預算的請求會回傳 403。在 Enterprise 中，工作空間預算一次性限制整個工作空間。

我可以限制團隊使用哪些模型嗎？

可以，透過 guardrail 的模型 allowlist（以及配套的 provider allowlist）。空白 allowlist 表示允許所有模型。若多個 guardrail 同時適用，allowlist 會交集，最嚴格的規則優先。

組織成員能看到彼此的消費嗎？

在組織中，活動訊息流會向所有成員顯示所有成員的使用元資料（模型、成本與時間）。我們不會儲存提示或回應，因此請求內容永遠不會被顯示。此訊息流無法僅限於您在組織中的個人活動。

OpenRouter 組織最多可容納多少人？

組織人數上限為 10 位成員。如需超過此數，請告訴我們！

OpenRouter 是否提供團隊層級的成本歸屬？

目前是的，但僅限於個別成員層級。活動儀錶板會以建立者（組織成員）為單位匯出使用量，且每個鍵會報告每日、每週與每月總數。沒有子團隊層級的歸屬。

OpenRouter 是否會在我達到預算前傳送提醒？

還沒有。在達到上限時請求會返回 403，且事先不會有電子郵件或 webhook 警告。您可以在儀錶板檢視目前狀態。此規則同樣適用於每鍵限制、守護線預算以及工作區預算。

OpenRouter 是否符合 HIPAA 標準，適用於醫療團隊？

我們目前不提供 HIPAA 商業合作夥伴協議（BAA）。我們已符合 SOC 2 Type 2 標準，因此對於需要 BAA 的醫療資料工作負載，您需要採用不同的方案來處理該特定工作負載。