OpenAI WebSocket Mode for Responses API

WebSocket 모드는 여러 턴에 걸쳐 Responses API로 가는 연결 하나를 열어 둔다. response.create 이벤트로 조작하며, 첫 이벤트는 일반 요청처럼 새 턴을 시작한다. 소켓이 열려 있으니 표준 스트리밍 API가 매 턴 치르는 연결 설정을 건너뛴다. 그 오버헤드는 한 번이면 작다. 긴 에이전트 실행에서는 그렇지 않다.

후속 턴은 새 입력 항목과 이전 턴으로 이어지는 previous_response_id만 보낸다. 컨텍스트 전체를 다시 보내지 않으며, 긴 사슬에서 절감의 대부분이 여기서 나온다. 첫 턴의 페이로드는 표준 create 본문을 그대로 따르되, 여기서는 적용되지 않는 stream, background 같은 전송 전용 필드는 뺀다. 그래서 대화가 길어져도 요청은 가볍게 유지된다.

핵심 이점은 워크플로가 모델과 도구의 왕복을 많이 포함할 때 나타난다. 그것이 저지연 에이전트 워크플로의 세계이며, 이 전송은 그들을 위해 만들어졌다. OpenAI 지침은 도구 호출이 많은 배포에서 상당한 속도 향상을 가리키며, 이득은 첫 토큰만이 아니라 이어가기 경로에서 나온다. 에이전트가 같은 도구를 계속 맴돌 때 시간을 가장 많이 낭비하는 부분이 바로 거기다. 모든 워크플로가 체감하지는 않는다. 에이전트가 도구를 거의 호출하지 않으면 별로 느끼지 못한다. 끊임없이 호출한다면, 그게 바로 핵심이다.

WebSocket 모드는 store=false와 데이터 무보존 구성에서 동작한다. OpenAI가 응답 상태를 보관하게 둘 수 없을 때 중요하다. 서버는 연결이 살아 있는 동안 최근 응답 상태를 메모리에 둔다. 그래서 턴을 요청 간에 저장하지 않고도 빠른 이어가기를 얻는다. 그렇게 하지 않으면 데이터가 서버에 남는다. 규제 환경이나 프라이버시에 민감한 팀에게 이 조합은 이 전송을 택하는 이유다.

서버 이벤트와 그 순서는 기존 Responses 스트리밍 모델과 일치한다. HTTP로 스트리밍 이벤트를 이미 다루고 있다면 이벤트 형태가 익숙할 테니, 클라이언트 로직을 처음부터 다시 쓰지 않아도 된다. 차이는 전달 채널이지 메시지 형식이 아니다. 그런데 왜 옮기는가. 효과가 큰 경우의 속도 때문이다. 그래서 마이그레이션 비용이 낮게 유지된다.