傳入主體准入

供應商設定參考 說明了 maxInboundBodyBytes，也就是單一傳入 JSON 主體的最大解碼大小。預設值仍為 256 MiB，可設定的範圍仍是 1 MiB 至 512 MiB。變更上限後請重新啟動代理，讓監聽器和讀取器一同採用預期的上限。

提高上限會改變並行能力

當解析後的上限超過 256 MiB，每個涵蓋的 HTTP 請求都會從程序共用的 512 MiB 准入預算中，預留完整的設定額度。因此同一時間最多只能執行一個這類請求，即使多個監聽器共用同一程序也是如此。小型主體同樣預留完整額度；較小的 Content-Length 或壓縮都不能繞過准入。預留額度會維持到回應串流結束、失敗或完成取消，而非在請求 JSON 解析完成後立即釋放。

涵蓋的 POST 端點包括 /v1/responses、/v1/responses/compact、 /v1/chat/completions、/v1/messages、/v1/messages/count_tokens、 /v1/images/generations、/v1/images/edits 與 /v1/alpha/search。 圖片、搜尋與 token 計數仍沿用各自可設定的單一主體上限。內部直接轉譯與 combo 呼叫不會再次預留 HTTP 額度。管理、音訊、上下文歷史及 WebSocket 的上限不變。

省略設定、設為零，或解析後的上限不超過 256 MiB，都不會啟用這道額外的並行閘門。現有的請求數及其他資源限制仍然適用。

暫時拒絕與主體過大的差別

若額度暫時不可用，系統會在協定解析或供應商派送前回傳 HTTP 503、Retry-After: 1 與錯誤碼 server_busy。Messages 與 token 計數用戶端會收到類 Anthropic 的錯誤，其類型為 overloaded_error；OpenAI 相容用戶端則會收到 server_error。請依重試標頭與用戶端退避機制，在目前請求完成後重試。進一步提高主體上限無法解決額度忙碌問題。

超過單次請求上限的主體仍依現有的 HTTP 413 流程處理。已宣告的超大主體也會走這條流程，不會變成忙碌拒絕。中斷連線沿用現有的取消行為。身分驗證與 origin 檢查會先於這道並行閘門執行。

預算衡量的是什麼

512 MiB 是已准入請求的額度總和，不保證程序記憶體用量低於 512 MiB。解碼、字串、物件圖、請求副本與其他應用程式狀態都會使用額外記憶體。現有的 UTF-8 與重新序列化 JSON 計量會保留；輸入位元組長度不會取代可能更大的正規化 JSON 大小。

若要並行處理小型請求，盡可能維持預設上限。只有大型歷史記錄工作流程確實需要時才提高上限，並接受額外的並行限制。