OpenAI właśnie uruchomiło tryb WebSocket w swoim Responses API. Zamiast przy każdym zapytaniu pakować od nowa cały kontekst rozmowy i wysyłać go przez osobne żądanie HTTP, aplikacja utrzymuje jedno stałe połączenie z serwerem. Kontekst żyje po stronie OpenAI, a programista wysyła tylko to, co nowe.
To zmiana, na którą czekali wszyscy budujący wieloturowe aplikacje konwersacyjne. Dotychczasowy model komunikacji z API oznaczał, że z każdą kolejną wiadomością rosła objętość danych przesyłanych tam i z powrotem. Teraz ten problem znika.
Dlaczego ponowne wysyłanie kontekstu było problemem
Wyobraź sobie rozmowę telefoniczną, w której po każdym zdaniu musisz się rozłączyć, zadzwonić ponownie i powtórzyć wszystko, co zostało powiedziane wcześniej, zanim zadasz kolejne pytanie. Dokładnie tak wyglądała dotychczasowa komunikacja z modelami OpenAI przez klasyczne REST API. Każde żądanie HTTP było niezależne — bezstanowe z natury protokołu. Aby model „pamiętał” wcześniejszy kontekst, trzeba było przesyłać pełną historię rozmowy za każdym razem.
Przy krótkich wymianach to drobnostka. Ale gdy rozmowa ciągnie się przez dziesiątki wiadomości, a kontekst obejmuje tysiące tokenów, skutki stają się odczuwalne. Rośnie opóźnienie, rośnie koszty (bo tokeny wejściowe są liczone przy każdym wywołaniu), rośnie też obciążenie sieci. Dla aplikacji działających w czasie rzeczywistym — na przykład asystentów głosowych czy narzędzi do kodowania z podpowiedziami na żywo — to była realna bariera.
Jak działa tryb WebSocket w Responses API
Mechanizm opiera się na protokole WebSocket, który od lat stanowi fundament komunikacji w czasie rzeczywistym w przeglądarkach, czatach i grach online. W przeciwieństwie do HTTP, WebSocket utrzymuje dwukierunkowe, trwałe połączenie między klientem a serwerem. Dane płyną w obie strony bez konieczności nawiązywania nowego połączenia przy każdej interakcji.
Zgodnie z dokumentacją OpenAI dotyczącą trybu WebSocket, połączenie nawiązuje się z endpointem wss://api.openai.com/v1/responses. Po uwierzytelnieniu i otwarciu sesji klient wysyła zdarzenia JSON — nowe wiadomości użytkownika, instrukcje systemowe, wywołania narzędzi. Serwer odpowiada strumieniowo, przesyłając tokeny odpowiedzi w miarę ich generowania.
Kluczowa różnica wobec dotychczasowego podejścia: kontekst konwersacji jest przechowywany po stronie serwera OpenAI w ramach aktywnej sesji WebSocket. Programista nie musi go ręcznie odtwarzać. Wysyła jedynie nową wiadomość, a model automatycznie wie, co było wcześniej. Jak ujął to zespół OpenAI Devs na platformie X: sesja WebSocket eliminuje konieczność ponownego przesyłania wcześniejszych odpowiedzi przy każdym żądaniu.
Co to oznacza dla kosztów i wydajności
Pomyślmy o tym w liczbach. Jeśli konwersacja liczy 4000 tokenów kontekstu, a użytkownik wymienia z modelem 20 wiadomości, w tradycyjnym trybie REST łączna liczba tokenów wejściowych wysłanych do API sięga dziesiątek tysięcy — mimo że treść nowych wiadomości stanowi ułamek tego wolumenu. Każde wywołanie niesie ze sobą cały dotychczasowy bagaż.
W trybie WebSocket ten sam scenariusz oznacza przesłanie zaledwie nowych fragmentów. Kontekst nie podróżuje tam i z powrotem. Bezpośrednie konsekwencje to niższe zużycie tokenów wejściowych (a więc niższe rachunki), krótszy czas oczekiwania na pierwszą odpowiedź (time-to-first-token) oraz mniejsze obciążenie łącza. Dla aplikacji agentowych, które prowadzą złożone wieloetapowe rozumowanie, różnica jest szczególnie istotna.
Nie oznacza to, że kontekst jest nieskończony. Ograniczenie okna kontekstowego modelu (np. 128 000 tokenów dla GPT-4.1) nadal obowiązuje. Zmienia się natomiast sposób, w jaki ten kontekst trafia do modelu — nie przez redundantne kopiowanie, lecz przez efektywne utrzymanie stanu sesji.
Strumieniowanie i obsługa zdarzeń
Tryb WebSocket naturalnie współgra ze strumieniowaniem odpowiedzi. Model nie czeka z wysłaniem pełnej odpowiedzi, lecz przesyła tokeny fragmentami, w miarę ich generowania. To zachowanie znane już z trybu stream: true w REST API, ale w WebSocket odbywa się bez narzutu powtarzanego handshake’u HTTP.
Komunikacja opiera się na zdarzeniach (events). Klient wysyła zdarzenia typu conversation.item.create, aby dodać nową wiadomość, lub response.create, aby poprosić model o odpowiedź. Serwer odpowiada strumieniem zdarzeń: response.output_text.delta z kolejnymi fragmentami tekstu, response.completed po zakończeniu. Cała wymiana przypomina bardziej dialog niż serię niezależnych zapytań.
Programiści znający OpenAI Agents SDK dostrzegą tu synergię. Agenci, którzy wykonują wiele kroków — wywołują narzędzia, analizują wyniki, dopytują — mogą teraz robić to szybciej i taniej, bo każdy krok nie wymaga retransmisji całej historii.
Kiedy warto sięgnąć po WebSocket, a kiedy zostać przy REST
Nie każda aplikacja potrzebuje trwałego połączenia. Jeśli budujesz prosty endpoint, który przyjmuje jedno pytanie i zwraca jedną odpowiedź – klasyczne żądanie HTTP POST do /v1/responses jest prostsze w implementacji, łatwiejsze do debugowania i nie wymaga zarządzania stanem połączenia.
WebSocket staje się sensownym wyborem tam, gdzie rozmowa jest wieloturowa i kontekst rośnie z każdą wymianą. Czatboty obsługujące złożone zapytania klientów, aplikacje wykorzystujące duże modele językowe do interaktywnej analizy danych, asystenci kodowania podpowiadający w czasie rzeczywistym, systemy głosowe z niskim opóźnieniem to naturalni kandydaci. Podobnie narzędzia agentowe, które w ramach jednej sesji wykonują dziesiątki wywołań modelu.
Warto też pamiętać o aspektach operacyjnych. Połączenie WebSocket wymaga utrzymywania otwartego socketu, obsługi rozłączeń i ponownych połączeń, zarządzania heartbeatem. W środowiskach serverless (np. AWS Lambda) może to wymagać dodatkowej infrastruktury.
Szerszy kontekst: jak API OpenAI ewoluuje
Wprowadzenie trybu WebSocket wpisuje się w wyraźny trend: OpenAI stopniowo przenosi ciężar zarządzania stanem z programisty na platformę. Wcześniej Assistants API wprowadziło koncept wątków (threads), w których historia rozmowy była przechowywana po stronie serwera. Responses API z obsługą WebSocket idzie dalej — oferuje tę samą wygodę, ale z niższym opóźnieniem i pełną kontrolą nad strumieniem danych.
Jednocześnie OpenAI utrzymuje kompatybilność wsteczną. Tradycyjne wywołania HTTP nadal działają. Nikt nie musi migrować na WebSocket — to opcja, nie wymóg. Dla zespołów, które już zbudowały solidne pipeline’y oparte na REST, przejście może nastąpić stopniowo, zaczynając od najbardziej „rozmownych” części systemu.
Interesujące jest też to, jak ta zmiana wpływa na inżynierię promptów. Gdy kontekst nie jest za każdym razem rekonstruowany od zera, programista zyskuje pewność, że model operuje dokładnie na tym samym stanie, który widział w poprzednim kroku. Eliminuje to subtelną klasę błędów związanych z niespójnym budowaniem historii po stronie klienta.
Praktyczne wskazówki na start
Dokumentacja OpenAI sugeruje kilka dobrych praktyk. Po pierwsze: uwierzytelnianie odbywa się jednorazowo przy nawiązywaniu połączenia, poprzez nagłówek z kluczem API lub tokenem. Nie trzeba go dołączać do każdego zdarzenia. Po drugie: warto implementować mechanizm ponownego połączenia z wykładniczym backoffem, bo nawet najstabilniejsze połączenia WebSocket mogą zostać zerwane przez sieć.
Po trzecie — i to ważna uwaga — sesja WebSocket ma ograniczony czas życia. Po przekroczeniu limitu bezczynności lub maksymalnego czasu trwania (60 minut), połączenie zostaje zamknięte. Aplikacja powinna być przygotowana na odtworzenie kontekstu w takim scenariuszu, najlepiej z wykorzystaniem identyfikatorów odpowiedzi (response IDs), które pozwalają na nawiązanie do wcześniejszych elementów konwersacji.
WebSocket w Responses API to przede wszystkim narzędzie optymalizacyjne. Nie zmienia tego, co modele potrafią. Zmienia to, jak efektywnie można z nich korzystać w aplikacjach wymagających ciągłej, kontekstowej interakcji. Dla wielu zespołów to różnica między prototypem a produktem gotowym na ruch produkcyjny.
