Przyspieszanie procesów pracy agentów za pomocą protokołów WebSocket w interfejsie Responses API

Gdy poprosisz Codex o naprawienie błędu, przeszukuje on bazę kodu w poszukiwaniu odpowiednich plików, odczytuje je w celu zbudowania kontekstu, wprowadza zmiany i uruchamia testy, aby sprawdzić, czy poprawka zadziałała. W praktyce oznacza to dziesiątki żądań do interfejsu Responses API wysyłanych w obie strony: określenie kolejnego działania modelu, uruchomienie narzędzia na komputerze, przesłanie wyników z powrotem do API i powtórzenie tego procesu.

Wszystkie te żądania mogą wydłużyć czas oczekiwania użytkowników na ukończenie przez Codex złożonych zadań. Z perspektywy opóźnień pętla agenta Codex spędza większość czasu na trzech głównych etapach: pracy w usługach API (w celu weryfikacji i przetwarzania żądań), wnioskowaniu modelu oraz czasie po stronie klienta (uruchamianiu narzędzi i budowaniu kontekstu modelu). Wnioskowanie to etap, w którym model działa na procesorach graficznych, aby generować nowe tokeny. W przeszłości uruchamianie wnioskowania LLM na procesorach graficznych było najwolniejszą częścią pętli agenta, więc dodatkowy koszt operacyjny obsługi API można było łatwo ukryć. W miarę jak wnioskowanie staje się szybsze, skumulowany narzut API wynikający z działania agenta staje się znacznie bardziej zauważalny.

W tym wpisie wyjaśnimy, jak przyspieszyliśmy pętle agentowe korzystające z API o łącznie 40%, dzięki czemu użytkownicy mogą odczuć wzrost szybkości wnioskowania z 65 do niemal 1000 tokenów na sekundę. Osiągnęliśmy to dzięki mechanizmom buforowania, wyeliminowaniu zbędnych pośrednich połączeń sieciowych, usprawnieniu naszego systemu zabezpieczeń, aby szybciej wykrywać problemy oraz – co najważniejsze – stworzeniu sposobu na ustanowienie trwałego połączenia z interfejsem Responses API zamiast wykonywania serii synchronicznych wywołań API.

W interfejsie API Responses wcześniejsze modele podstawowe, takie jak GPT‑5 i GPT‑5.2, działały z szybkością około 65 tokenów na sekundę (TPS). Przy tworzeniu GPT‑5.3‑Codex‑Spark, szybkiego modelu do programowania, naszym celem było osiągnięcie dziesięciokrotnie większej szybkości: ponad 1000 TPS, co było możliwe dzięki wyspecjalizowanemu sprzętowi Cerebras zoptymalizowanemu pod kątem wnioskowania modeli LLM. Aby mieć pewność, że użytkownicy mogą doświadczyć rzeczywistej szybkości tego nowego modelu, musieliśmy zmniejszyć narzut interfejsu API. 

Około listopada 2025 roku rozpoczęliśmy intensywną optymalizację dotyczącą pracy z Responses API, wprowadzając wiele usprawnień wpływających na opóźnienia w ścieżce krytycznej dla pojedynczego żądania: 

• Buforowanie wyrenderowanych tokenów i konfiguracji modelu w pamięci, aby uniknąć kosztownej tokenizacji i wywołań sieciowych na potrzeby odpowiedzi wieloetapowych
• Zmniejszenie opóźnienia wynikającego z przeskoków sieciowych poprzez wyeliminowanie wywołań do usług pośrednich (na przykład przetwarzania obrazów) i bezpośrednie wywoływanie samej usługi wnioskowania
• Ulepszamy nasz system bezpieczeństwa, aby móc szybciej uruchamiać określone klasyfikatory do oznaczania konwersacji

Dzięki tym usprawnieniom odnotowaliśmy niemal 45-procentową poprawę czasu do wygenerowania pierwszego tokenu (TTFT) – który odzwierciedla odczuwaną responsywność API – jednak to nadal nie był wystarczający wynik dla GPT‑5.3‑Codex‑Spark. Nawet po tych zmianach narzut interfejsu Responses API był zbyt duży w stosunku do szybkości modelu – to znaczy, że użytkownicy musieli czekać na procesory CPU obsługujące nasze API, zanim mogli skorzystać z procesorów graficznych obsługujących model.

Problem leżał głębiej i miał charakter strukturalny: traktowaliśmy każde żądanie do Codex jako niezależne, przetwarzając stan konwersacji i inny kontekst wielokrotnego użytku w każdym kolejnym żądaniu. Nawet gdy większość rozmowy się nie zmieniła, ponosiliśmy koszt pracy związanej z całą jej historią. W miarę wydłużania się rozmowy to powtarzające się przetwarzanie stawało się coraz bardziej kosztowne.

Aby dopracować projekt, przemyśleliśmy na nowo protokół komunikacji: czy moglibyśmy utrzymywać trwałe połączenie i przechowywać stan w pamięci podręcznej, zamiast za każdym razem ustanawiać nowe połączenie przez HTTP i wysyłać pełną historię rozmowy przy każdym kolejnym żądaniu? Założenie było takie, aby przesyłać wyłącznie nowe informacje wymagające weryfikacji i przetworzenia oraz przechowywać stan nadający się do ponownego użycia w pamięci przez cały czas trwania połączenia. To zmniejszyłoby narzut wynikający ze zbędnej pracy.

Rozważaliśmy kilka różnych opcji, w tym protokoły WebSocket i dwukierunkowe strumieniowanie gRPC. Zdecydowaliśmy się na WebSocket, ponieważ jako proste protokoły transportu wiadomości nie wymagały od użytkowników zmiany struktur danych wejściowych i wyjściowych w API Responses. Rozwiązanie to było przyjazne dla programistów bez większych zakłóceń wpisywało się w naszą istniejącą architekturę.

Pierwszy prototyp WebSocket zmienił nasze wyobrażenie o tym, co jest możliwe w zakresie opóźnień interfejsu Responses API. Inżynier z zespołu Codex z dogłębną wiedzą specjalistyczną obejmującą cały stos API przygotował prototyp, uruchamiając agenta Codex na noc.

W tym prototypie przebiegi agentowe były modelowane jako jedna długotrwała odpowiedź. Korzystając z funkcji asyncio, interfejs Responses API asynchronicznie blokował się w pętli próbkowania po wybraniu wywołania narzędzia, a interfejs Responses API wysyłał z powrotem do klienta zdarzenie response.done. Po wykonaniu wywołania narzędzia klienci odsyłali zdarzenie response.append z wynikiem działania narzędzia, co odblokowywało pętlę próbkowania i pozwalało modelowi kontynuować działanie.

Można to porównać do traktowania lokalnego wywołania narzędzia jak wywołania narzędzia hostowanego. Gdy model wywołuje wyszukiwanie w sieci, pętla wnioskowania zatrzymuje się, wywołuje usługę wyszukiwania i umieszcza jej wynik w kontekście modelu. W naszym projekcie zrobiliśmy to samo, ale zamiast wywoływać usługę zdalną, odesłaliśmy wywołanie narzędzia modelu z powrotem do klienta przez WebSocket. Gdy klient odesłał wynik, dodawaliśmy go do kontekstu i kontynuowaliśmy próbkowanie.

To rozwiązanie było wyjątkowo skuteczne, ponieważ wyeliminowało konieczność powtarzania pracy związanej z interfejsem API podczas wdrażania agenta. Wystarczyło raz wykonać czynności przed wnioskowaniem, poczekać za zakończenie działania narzędzia, a na koniec raz wykonać czynności po wnioskowaniu.

Niestety wiązało się to z mniej znaną i bardziej skomplikowaną strukturą API. Chcieliśmy, aby programiści mogli dodać obsługę protokołów WebSocket bez konieczności przepisywania integracji z API pod kątem nowego modelu interakcji.

W uruchomionej wersji wróciliśmy do znanej formy: nadal używamy response.create z tą samą treścią żądania i parametru previous_response_id, aby kontynuować kontekst konwersacji na podstawie stanu poprzedniej odpowiedzi.

W połączeniu WebSocket serwer utrzymuje w pamięci podręcznej (cache) stan poprzednich odpowiedzi powiązany z danym połączeniem. Gdy kolejne wywołanie response.create zawiera previous_response_id, pobieramy ten stan z pamięci podręcznej, zamiast odtwarzać całą rozmowę od zera.

Ten buforowany stan obejmuje:

• Poprzedni obiekt odpowiedzi
• Poprzednie elementy wejściowe i wyjściowe
• Definicje narzędzi i przestrzenie nazw
• Artefakty próbkowania wielokrotnego użytku, takie jak wcześniej wygenerowane tokeny

Dzięki ponownemu wykorzystaniu przechowywanego w pamięci stanu poprzedniej odpowiedzi udało nam się wprowadzić kilka istotnych optymalizacji:

• Sprawiliśmy, że niektóre z naszych klasyfikatorów bezpieczeństwa i modułów sprawdzających poprawność żądań przetwarzają wyłącznie nowe dane wejściowe, a nie za każdym razem całą historię
• Utrzymujemy w pamięci bufor wygenerowanych tokenów, do którego dodajemy kolejne elementy, aby pominąć zbędną tokenizację
• Ponownie wykorzystujemy naszą sprawdzoną logikę doboru i routingu modelu w kolejnych żądaniach 
• Nakładamy nieblokujące zadania po wnioskowaniu, takie jak rozliczanie, na kolejne żądania

Celem było maksymalne zbliżenie się do prototypu o minimalnym narzucie, ale z taką strukturą API, którą programiści już znali i wokół której tworzyli swoje rozwiązania.

Po dwumiesięcznym intensywnym okresie prac nad budową trybu WebSocket uruchomiliśmy wersję alfa ze startupami tworzącymi agenty kodujące, aby mogły zintegrować nowe rozwiązanie ze swoją infrastrukturą i bezpiecznie zwiększać ruch. Użytkownicy wersji alfa byli zachwyceni i zgłaszali poprawę nawet o 40%⁠(otwiera nowe okno) w swoich procesach pracy agentów. Biorąc pod uwagę pozytywne opinie o wersji alfa, byliśmy gotowi na oficjalne wdrożenie.

Wyniki po wdrożeniu były natychmiastowe. Codex szybko przeniósł większość ruchu w Responses API do trybu WebSocket, uzyskując znaczną redukcję opóźnień. W przypadku GPT‑5.3‑Codex‑Spark osiągnęliśmy docelowy poziom 1000 TPS i odnotowaliśmy skoki do 4000 TPS, pokazując, że Responses API było w stanie nadążyć za znacznie szybszym wnioskowaniem w rzeczywistym ruchu produkcyjnym. Na efekty nie trzeba było długo czekać również w społeczności deweloperów:

• Codex szybko przeniósł większość ruchu do protokołów WebSocket. Użytkownicy korzystający z najnowszych modeli, takich jak GPT‑5.3‑Codex⁠(otwiera nowe okno), GPT‑5.4⁠(otwiera nowe okno) i nie tylko, korzystają z przyspieszenia procesów dzięki trybowi WebSocket.
• Vercel zintegrował tryb WebSocket z AI SDK i odnotował spadek opóźnień o nawet 40%⁠(otwiera nowe okno).
• Wieloplikowe procesy Cline przyspieszyły o 39%⁠(otwiera nowe okno).
• Modele OpenAI w Cursor stały się nawet o 30% szybsze⁠(otwiera nowe okno).

Tryb WebSocket to jedna z najważniejszych nowych funkcji w interfejsie Responses API od czasu jego uruchomienia w marcu 2025 roku. Przeszliśmy od pomysłu do wdrożenia produkcyjnego w zaledwie kilka tygodni dzięki ścisłej współpracy zespołów API i Codex w OpenAI. Nasze rozwiązanie nie tylko znacząco zmniejsza opóźnienia wdrażania agentów, ale także odpowiada na rosnącą potrzebę twórców: wraz z przyspieszeniem wnioskowania modelu usługi i systemy związane z tym procesem również muszą działać szybciej, aby przekazać te korzyści użytkownikom.