當你要求 Codex 修正錯誤時，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，我們的目標是令速度數量級躍升：超過 1,000 TPS，並透過針對 LLM 推論最佳化的專用 Cerebras 硬件來達至加速。為確保用戶能真正體驗這款新模型的速度，我們必須降低 API 處理開銷。
大約在 2025 年 11 月，我們為 Responses API 推展效能衝刺，針對單一請求的關鍵路徑延遲實施多項最佳化：
- 將已運算的 Token 和模型設定快取到記憶體中，避免多輪回應中昂貴的 Token 化處理和網絡調用
- 移除對中介服務的調用（例如圖像處理解像度），直接調用推論服務本身，從而減少網絡跳轉延遲
- 改進安全性堆疊，讓我們可以更快執行特定的分類器來標示對話
透過這些改善，我們看到首個 Token 產生時間（TTFT）改善了接近 45%。TTFT 反映 API 的回應感覺有多快，但這些改善對 GPT‑5.3‑Codex‑Spark 來說仍然不夠快。即使有這些改善，相對於模型速度，Responses API 的處理開銷仍然太大。換言之，用戶要先等待執行 API 的 CPU 完成工作，才能使用提供模型服務的 GPU。
更深層的問題，其實在於架構本身：我們將每個 Codex 請求都視為獨立請求，因此每次跟進請求都要處理對話狀態和其他可重用的上下文。即使對話大部分內容沒有改變，我們仍然要為整段對話記錄相關的工作消耗成本和資源。隨著對話變長，這些重複處理就會變得更昂貴。
為了令設計更加精簡，我們重新思考傳輸協定：我們是否可以保持持續連線並快取狀態，而不是每次跟進請求都要透過 HTTP 建立新連線，並傳送完整對話記錄？我們的理念是希望只傳送需要驗證和處理的新資料，並在連線存續期間將可以重用狀態快取在記憶體中。這可以減少重複工作的處理開銷。
我們考慮了幾種不同方法，包括 WebSockets 和 gRPC 雙向串流。最後我們選擇 WebSockets，因為這是一種簡單的訊息傳輸協定，用戶毋須更改 Responses API 的輸入和輸出結構。對開發人員而言這很方便易用，亦能在不大幅改動的情況下配合我們現有架構。
第一個 WebSocket 原型改變了我們對 Responses API 延遲可能性的想像。Codex 團隊一位對 API 堆疊有深入專業知識的工程師，透過讓 Codex 智能代理通宵執行，整合出一個原型。
在該原型中，智能代理推出流程被建模為單一長時間執行的 Response。透過 asyncio 功能，Responses API 會在取樣循環中，於取樣到工具調用後非同步封鎖，並向客戶端傳回 response.done 事件。客戶端執行工具調用後，會傳回包含工具結果的 response.append 事件，解除取樣循環的封鎖，讓模型繼續執行。
我們可以將這個流程想像成將本機工具調用視為託管工具調脂。當模型調用網絡搜尋時，推論循環會封鎖、調用網絡搜尋服務，並將服務回應放入模型上下文中。在我們的設計中，我們採用了相同概念；但我們並非調用遠端服務，而是透過 WebSocket 將模型的工具調用傳送回客戶端。當客戶端回應時，我們就將客戶端的工具調用回應放入上下文，然後繼續取樣。
這個設計非常有效，因為當中消除了智能代理推出流程中的重複 API 工作。我們可以先執行一次推論前工作，暫停以等待工具執行，並在最後執行一次推論後工作。
問題是，這種做法的代價是 API 形態變得較不熟悉，而且更加複雜。我們希望開發人員可以直接加入 WebSocket 支援，而毋須圍繞新的互動模式重寫 API 整合。
在我們推出的版本中，我們改回較熟悉的形態：繼續使用相同請求主體的 response.create，並使用 previous_response_id 從上一個回應的狀態延續對話情境。
在 WebSocket 連線上，伺服器會保留一個以連連為範圍的記憶體內快取，用於儲存先前的回應狀態。當後續 response.create 包含 previous_response_id 時，我們會從快取擷取該狀態，而不是從頭重建完整對話。
這個快取狀態包括：
- 上一個
response物件 - 先前的輸入和輸出項目
- 工具定義和命名空間
- 可重用的取樣成品，例如先前已運算的 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 團隊緊密合作，我們在短短數星期內就由構思走向投入生產環境。這不但大幅改善智能代理推出流程的延遲，亦支援開發人員日益增長的需求：隨著模型推論速度提升，圍繞推論的服務和系統亦需要加速，才能將這些增益真正帶給用戶。
