Auto、TokenLab Verified 或 Official：如何選擇交付層級

當我們發現一條非預期的路由時，模型名稱並非有用的線索，交付層級（delivery tier）才是。即使邏輯模型保持不變，服務請求的路由仍可能改變價格適用性。這種不匹配正是我們將交付層級視為路由決策而非品質標章的原因。當價格適用性和路由需要明確時，這一點至關重要。而當您的預設策略已經符合您的風險與成本目標時，其重要性則相對較低。

重點摘要

• 請求可以透過 official（官方）路由或 verified（驗證）路由提供服務。選擇結果會記錄在每個請求的 resolvedDeliveryTier 中（值為 verified 或 official，若記錄早於此功能則為 null）。
• auto 是預設策略，而非第三種路由類型。它會保留可達路徑，並在分派前估算請求的最大可能成本。
• 工作區（Workspace）和 API-key 策略繼承是標準設定。在 2026-09-11 的生產環境回讀中，5,536 個工作區擁有明確的 Auto 策略，217 個繼承了系統預設值，而所有 4,134 個 API key 皆繼承自其工作區。該週稍晚的回讀顯示有 219 個繼承了系統預設。明確設定的數量保持不變，因為那些繼承的工作區是尚未設定策略的新建立帳戶。這些數據來自內部發布排練筆記中記錄的 TokenLab 2.0 啟動回讀（觀察時間為 2026-09-11）；請將其視為內部生產環境回讀，而非公開基準測試。
• Official 定價適用性要求精確的 Official 路由匹配。當沒有 Official 路由匹配時，Verified 交付仍然可用。
• 您可以透過標頭 X-TokenLab-Delivery-Policy 針對每個請求覆寫交付選擇。工作區預設值涵蓋了常見情況。

三種交付層級選項的實際含義

通道（Channels）將交付層級宣告為 VERIFIED 和 OFFICIAL。只有具有活躍公開交付層級的通道才能綁定至組織模型綁定。工作區可以將邏輯模型綁定至特定通道。除非該通道處於活躍狀態、未被刪除且宣告了活躍的公開交付層級，否則該綁定將被拒絕。該模型在該通道上的路由也必須啟用。

Official 意味著路由由官方提供者路徑服務，而 Verified 意味著由 TokenLab 驗證的路徑服務。Auto 是一種讓路由器在可達路由中進行選擇的策略；當我們在分派後檢查請求時，resolvedDeliveryTier 會告訴我們是由 verified 還是 official 服務。若記錄早於此功能，該欄位則為 null。

選擇交付層級後的變化

選擇層級會改變價格適用性、單次請求記錄以及您在分派前看到的估算值。定價可以透過組織層級的交付價格調整規則針對每個交付層級進行調整，該調整在應用前會經過正規化與驗證。發布後，明確的 Verified 或 Official 選擇將持續適用，而早於此策略的請求則預設為 Auto。

Auto 估算的是請求的最大金額，而非單一價格。可能有多條路由可達，但 Auto 會保留所有可達路由，且不會為了讓估算值看起來更低而捨棄較昂貴的路由。在我們的管道中，我們會在分派前檢查估算值，並在完成後檢查 resolvedDeliveryTier。

選項	優化目標	選擇時機	事後可驗證內容
Auto	可達路由與最大成本估算	您希望預設策略在可達路由中進行選擇	resolvedDeliveryTier 顯示服務該請求的路由
TokenLab Verified	當 Official 不可用或非必要時，存取 TokenLab 驗證路徑	您需要驗證路由，或沒有 Official 路由匹配	resolvedDeliveryTier 顯示 verified
Official	精確的 Official 路由匹配以符合官方定價適用性	您需要官方定價適用性	resolvedDeliveryTier 顯示 official

團隊通常如何設定交付層級策略

本節中的回讀數據來自內部發布排練筆記中記錄的 TokenLab 2.0 啟動回讀（觀察時間為 2026-09-11）；請將其視為內部生產環境回讀，而非公開基準測試。

預設設定是繼承，而非針對每個請求進行操作。在 2026-09-11 的生產環境回讀中，我們看到 5,536 個工作區擁有明確的 Auto 策略，而另外 217 個繼承了系統預設值。所有 4,134 個 API key 皆繼承自其工作區，因此舊客戶端無需使用新標頭。這種模式很合理，因為工作區策略涵蓋了常見情況，而針對每個請求的覆寫則屬於例外。

該週稍晚的回讀顯示有 5,536 個明確設定與 219 個繼承，明確設定的數量保持不變，而繼承數量從 217 變為 219。那些繼承的工作區是尚未設定策略的新建立帳戶，因此這些數字會隨著帳戶建立而變動。設定策略從來不是一種遷移，發布時沒有執行工作區或 key 策略的批次回填，繼承的 key 也不需要客戶端變更。

當工作區將邏輯模型綁定至特定通道時，綁定規則仍然適用。除非通道處於活躍狀態、未被刪除且宣告了活躍的公開交付層級，否則綁定將被拒絕。該模型在該通道上的啟用路由也必須存在。通道只有在 Registry 宣告為 ACTIVE 且其自身記錄為 ACTIVE 且無刪除時間戳時，才能綁定至組織模型綁定，因此暫停或退役的通道無法被釘選（pinned）。

將邏輯模型釘選至特定通道是工作區在不影響個別請求的情況下，針對該模型表達「始終使用 Official」的方式。早於交付策略的請求預設為 Auto。無需客戶端變更，發布時也沒有執行工作區或 key 策略的批次回填。若需模型層級的背景資訊，請搭配 模型資料中心指南 使用。

如何檢查服務請求的交付層級

當請求完成時，請讀取請求記錄中的 resolvedDeliveryTier；其值為 verified 或 official，null 值表示記錄早於此欄位。請求還會攜帶 requestedDeliveryPolicy，記錄呼叫者所要求的內容，當應用工作區預設值時，此欄位可為 null。

若要針對單一請求覆寫層級，請加入 X-TokenLab-Delivery-Policy 標頭；接受的值為 auto、verified 和 official。以下是該標頭的範例：

# 將此標頭加入 Claude Sonnet 5 請求
X-TokenLab-Delivery-Policy: verified

例如，此 cURL 呼叫針對 Claude Sonnet 5 並要求 official：

curl https://api.tokenlab.sh/v1/chat/completions -H "Authorization: Bearer $TOKENLAB_API_KEY" -H "Content-Type: application/json" -H "X-TokenLab-Delivery-Policy: official" -d '{"model":"Claude Sonnet 5","messages":[{"role":"user","content":"Hello"}]}'

呼叫後，該請求的請求記錄將攜帶：

{
  "requestedDeliveryPolicy": "official",
  "resolvedDeliveryTier": "official"
}

請求記錄也包含使用量欄位，請求控制台指南 顯示了該記錄的位置以及目前的使用量欄位名稱。

如果所要求的層級沒有啟用的路由，閘道會回應 delivery_tier_unavailable，且不會靜默回退到另一個層級。請求控制台顯示了該記錄的位置，請求控制台指南 解釋了如何找到它。當價格或路由看起來不符合預期時，我們從這裡開始檢查，因為控制台和請求證據可以顯示是哪個層級服務了該流量。

當 Auto 選擇了非預期的交付層級時

當 Auto 選擇了您未預期的層級時，請讀取請求上的 resolvedDeliveryTier 並將其與您組織綁定的通道進行比較。然後，您可以將模型綁定至您想要的通道，或針對該請求覆寫層級。這既保持了預設策略的簡單性，又為您提供了糾正非預期路由的具體方法。

限制

此處的數字是 2026-09-11 的時間點回讀，且會隨時間漂移。交付層級的可用性取決於您的模型與組織啟用了哪些路由。如果通道處於非活躍狀態、已刪除、缺乏活躍的公開交付層級，或該模型沒有啟用路由，工作區綁定可能會被拒絕。各交付層級的價格調整取決於您自己的組織規則。我們無法提供通用的比較，因為來源數據並未提供。交付決策是在路由選擇後解析的，因此您獲得的層級取決於該時刻為您的組織啟用了哪些路由。

常見問題

Auto 實際上選擇了什麼？

Auto 是預設策略，而非第三種路由類型。它會保留可達路徑，並在分派前估算請求的最大可能成本。早於此策略的請求預設為 Auto。分派後，resolvedDeliveryTier 會記錄請求是透過 verified 還是 official 路由服務。

為什麼 Verified 路由的成本可能高於 Official 路由？

定價可以透過組織層級的交付價格調整規則針對每個交付層級進行調整。該調整在應用前會經過正規化與驗證。因此，差異取決於您的設定，您應該檢查分派前顯示的價格。

我是否必須在每個請求上設定交付層級？

不需要。工作區和 API-key 策略繼承是標準設定。在 2026-09-11 的生產環境回讀中，5,536 個工作區擁有明確的 Auto 策略，217 個繼承了系統預設值，而所有 4,134 個 API key 皆繼承自其工作區。隨著新帳戶的建立，繼承數量在該週稍晚變為 219。這些數據來自內部發布排練筆記中記錄的 TokenLab 2.0 啟動回讀（觀察時間為 2026-09-11）；請將其視為內部生產環境回讀，而非公開基準測試。您可以針對每個請求覆寫交付選擇，但工作區預設值已涵蓋常見情況。

我如何知道哪個層級服務了已完成的請求？

讀取請求記錄中的 resolvedDeliveryTier。其值為 verified 或 official，若記錄早於此欄位則為 null。requestedDeliveryPolicy 顯示呼叫者所要求的內容，當應用工作區預設值時，此欄位可為 null。請求控制台和 請求控制台指南 顯示了該記錄的位置。

如果我要求的層級沒有啟用的路由，會發生什麼事？

閘道會回應 delivery_tier_unavailable。它不會靜默回退到另一個層級。請讀取請求記錄，然後啟用匹配的路由或變更所要求的策略。

建立一個 API key 並比較您獲得的層級與預期的層級；請求控制台指南 顯示了該記錄的位置。