2 篇文章含有標籤「responses-api」

Auto-Router：在不發生加密內容失敗的情況下切換層級

2026年9月18日

Tin Lo

AI Product Engineer, LiteLLM

Auto-Router 可以在請求從簡單工作變成較困難的任務時，在不同層級之間移動對話。Responses API 用戶端可能會讓這種切換變得困難，因為先前的回應可能包含只有建立它的部署才能解密的加密推理內容

LiteLLM 現在會保留可讀的歷史記錄，並移除新選定層級無法驗證的加密推理。請求可以繼續送往所選模型，而不是因為 invalid_encrypted_content 而失敗

這項修正已包含在 LiteLLM v1.102.x 發行線，並已合併於 PR #40280

事件報告：多區域 Responses API 負載平衡中的加密內容失敗

2026年2月24日

Sameer Kankute

SWE @ LiteLLM (LLM Translation)

Krrish Dholakia

CEO, LiteLLM

Ishaan Jaffer

CTO, LiteLLM

日期： 2026 年 2 月 24 日
期間： 持續進行中（直到修正部署）
嚴重性： 高（適用於在不同 API 金鑰之間對 Responses API 進行負載平衡的使用者）
狀態： 已解決

摘要

當在具有不同 API 金鑰的部署之間對 OpenAI 的 Responses API 進行負載平衡時（例如，不同的 Azure 區域或 OpenAI 組織），包含加密內容項目（例如 rs_... reasoning items）的後續請求會失敗，錯誤如下：

{
  "error": {
    "message": "The encrypted content for item rs_0d09d6e56879e76500699d6feee41c8197bd268aae76141f87 could not be verified. Reason: Encrypted content organization_id did not match the target organization.",
    "type": "invalid_request_error",
    "code": "invalid_encrypted_content"
  }
}

加密內容項目在密碼學上與建立它們的 API 金鑰所屬組織綁定。當路由器將後續請求負載平衡到使用不同 API 金鑰的部署時，解密就會失敗。

帶有加密內容的 Responses API 請求： 路由到錯誤部署時會完全失敗
初始請求： 不受影響。只有包含加密項目的後續請求會失敗
其他 API 端點： 沒有影響。Chat completions、embeddings 等功能皆正常運作

摘要​

摘要