當你請 Codex 修正錯誤時，它會掃描程式碼庫找出相關檔案，讀取內容建立上下文，進行修改，並執行測試確認修改是否成功。這個流程背後包含數十次來回的 Responses API 呼叫：判斷模型下一步動作、在你的電腦上執行工具、將工具輸出回傳至 API，然後重複上述流程。
由於要處理大量請求，當 Codex 執行較為複雜的任務時，使用者可能需要花上數分鐘等待。從延遲角度來看，Codex 智慧體運作循環大部分時間花在三個主要階段：API 服務中的作業（用於驗證及處理要求）、模型推論，以及用戶端執行（執行工具和建構模型上下文）。其中，「推論」指的是模型在 GPU 上生成新 Token 的過程。過去，在 GPU 上執行 LLM 推論是智慧體運作循環中最慢的部分，因此 API 的額外負擔不明顯。但隨著推論速度加快，智慧體流程中累積的 API 額外負擔也變得更加顯著。
在這篇文章中，我們將說明如何讓使用 API 的智慧體運作循環整體提速 40%，讓使用者體驗推論速度從每秒 65 個 Token 提升到每秒接近 1,000 個 Token。我們透過多項優化著手改善，包括導入快取機制、減少不必要的網路傳輸、強化安全機制以更快速地標記問題，最關鍵的是建立可與 Responses API 持續連線的方式，取代過去需進行一連串同步 API 呼叫的做法。
在 Responses API 中，先前的 GPT‑5 和 GPT‑5.2 等旗艦模型運行速度約為每秒 65 個 Token (TPS)。為了推出高速程式碼編寫模型 GPT‑5.3‑Codex‑Spark，我們採用針對 LLM 推論最佳化的 Cerebras 專用硬體，目標是提升一個數量級，達到超過 1,000 TPS。為了讓使用者真正感受到新模型的速度提升，我們必須降低 API 的額外負擔。
約在 2025 年 11 月，我們針對 Responses API 進行效能衝刺，並對單一請求關鍵路徑的延遲進行多項優化：
- 在記憶體中快取已生成的 Token 與模型設定，即可在多輪回應時省略成本較高的 Token 化處理與網路呼叫
- 移除對中介服務的呼叫（例如影像處理解析度），改為直接呼叫推論服務，以改善網路延遲
- 優化安全機制，讓部分分類器能更快速地標記對話內容
透過上述優化，我們看到首次 Token 生成時間 (TTFT) 縮短了近 45%，這也直接反映在 API 的回應速度。不過，對於 GPT‑5.3‑Codex‑Spark 而言，這樣的速度仍然不夠。即使完成這些優化，Responses API 的額外負擔相較於模型的速度仍然過高，換句話說，使用者必須先等待執行 API 的 CPU 完成處理，才能開始使用負責模型的 GPU。
更根本的問題在於架構設計：我們將每一次 Codex 請求都視為獨立處理，導致每次後續請求都必須重新處理對話狀態與可重用的上下文。即使大部分對話內容沒有改變，系統仍需付出處理整段對話歷史的成本。隨著對話變長，重複處理的成本也隨之提高。
為了讓整體設計更加精簡，我們重新思考了傳輸協定：是否能維持持續連線並保留狀態快取，而不是每次後續請求都透過 HTTP 建立新連線，並傳送完整的對話歷史？我們的做法是只傳送需要驗證與處理的新增資料，並在連線存續期間，將可重用的狀態保存在記憶體中。這將可減少重複作業所帶來的額外開銷。
我們評估了多種方案，包括 WebSockets 與 gRPC 雙向串流。最終我們選擇 WebSockets，這是一種簡潔的訊息傳輸協定，讓使用者無需更動 Responses API 既有的輸入與輸出結構。此方案對開發者相當友善，且不需大幅調整即可融入現有架構。
第一版 WebSocket 原型讓我們重新認識了 Responses API 在改善延遲表現上的可能性。Codex 團隊中一位熟悉整體 API 架構的工程師，在一夜之間透過執行 Codex 智慧體，快速完成了一個原型。
在該原型中，智慧體流程被建為一個單一長時間執行的回應。透過 asyncio，在取樣到工具呼叫時，Responses API 會在取樣運作循環中進入非同步等待，並將 response.done 事件傳回用戶端。工具呼叫完成後，用戶端會透過 response.append 事件回傳結果，解除取樣運作循環的等待狀態，讓模型繼續運作。
這就像是將本地工具呼叫視同為託管工具呼叫來處理。當模型呼叫網頁搜尋時，推論運作循環會暫停，呼叫網頁搜尋服務，並將回應結果納入模型上下文。我們在設計中採用了相同概念，但不是呼叫遠端服務，而是透過 WebSocket 將模型的工具呼叫傳回用戶端。當用戶端作出回應時，系統會將用戶端的工具呼叫回應放入上下文，並繼續取樣。
這項設計非常有效，因為它解決了智慧體導入流程中重複的 API 處理。系統只需執行一次推論前處理，在工具執行期間暫停，最後再進行一次推論後處理即可。
不過，這樣做的代價是 API 的使用模式變得較不直觀，整體結構也更複雜。我們希望開發者能夠直接導入 WebSocket，而不必為了配合新的互動模式重寫整個 API 整合流程。
在正式推出的版本中，我們回到開發者熟悉的使用方式：持續使用 response.create 搭配相同的請求內容，並透過 previous_response_id 延續前一次回應的對話上下文。
在 WebSocket 連線中，伺服器會於該連線範圍內，在記憶體中維持一份先前回應狀態的快取。當後續的 response.create 包含 previous_response_id 時，系統會從快取中擷取該狀態，而不是從頭重建完整對話。
快取狀態包含：
- 先前的
回應物件 - 先前的輸入與輸出項目
- 工具定義與命名空間
- 可重複利用的取樣產出結果，例如先前已產生的 Token
透過重複使用記憶體中的先前回應狀態，我們得以實現多項關鍵優化：
- 讓部分安全分類器和請求驗證器只需處理新增輸入，而不必每次都重新掃描完整對話歷史
- 在記憶體中維持已生成 Token 的快取，並持續追加內容，避免不必要的 Token 化處理
- 在多次請求之間重用已驗證可行的模型解析與路由邏輯
- 讓不會阻礙其他作業的的推論後處理（例如計費）與後續要求同步進行
我們的目標是在維持開發者熟悉且已用來建構應用的 API 形式下，盡可能貼近這個低額外負擔的原型設計。
在經過兩個月的開發衝刺並完成 WebSocket 模式後，我們與幾家關鍵的程式智慧體新創合作推出 alpha 版本，協助他們整合至既有基礎架構，並在安全的情況下逐步提升流量。Alpha 測試回饋相當正面，使用者回報其智慧體工作流程效率最高提升 40%(在新視窗中開啟)。在 alpha 測試獲得正面回饋後，我們已準備好正式推出。
推出後，成效立即顯現。Codex 迅速將大部分的 Responses API 流量轉移至 WebSocket 模式，整體延遲顯著下降。針對 GPT‑5.3‑Codex‑Spark，我們達成了 1,000 TPS 的目標，且尖峰可達 4,000 TPS，證明 Responses API 在實際生產環境中也能跟上更高速的模型推論。這項改進的影響力也很快在開發者社群中浮現：
- Codex 迅速將大部分流量切換到 WebSockets。使用最新模型（例如 GPT‑5.3‑Codex(在新視窗中開啟)與GPT‑5.4(在新視窗中開啟) 等）的 Codex 使用者皆能受益於 WebSocket 模式帶來的效能提升。
- Vercel 將 WebSocket 模式整合至 AI SDK 後，延遲降低多達 40%(在新視窗中開啟)。
- Cline 的多檔案工作流程速度加快 39%(在新視窗中開啟)。
- Cursor 中的 OpenAI 模型速度最高提升 30%(在新視窗中開啟)。
WebSocket 模式是 Responses API 自 2025 年 3 月推出以來最重要的新功能之一。從構想到正式投入生產，我們僅用了數週時間，這一切都歸功於 OpenAI 的 API 團隊與 Codex 團隊的緊密合作。這項技術不僅大幅降低智慧體流程的延遲，也回應了開發者日益增長的需求：隨著模型推論速度持續提升，周邊系統與服務也必須同步優化，才能真正將效能提升傳遞給最終使用者。
