Responses API WebSockets 도입, agent loop 지연 최대 40% 절감

개발자 트윗이 실제로 바꾼 것

OpenAI 개발자 계정이 말한 것은 단순한 전송 프로토콜 교체가 아니다. agent 인프라의 병목이 inference만이 아니라는 점을 드러낸 변화다. 트윗은 Responses API의 WebSockets가 tool call 사이에서 상태를 warm하게 유지해 workflow를 종단 간 최대 40% 빠르게 만든다고 적었다. 이 지점이 중요한 이유는 coding agent가 파일을 읽고, 테스트를 돌리고, 도구를 오갈수록 자잘한 API 오버헤드가 몇 초가 아니라 몇 분의 대기로 누적되기 때문이다.

“WebSockets keep response state warm across tool calls, helping workflows run up to 40% faster.”

OpenAI의 engineering 글은 문제의 크기를 더 분명하게 보여준다. 이전 주력 model들은 Responses API에서 초당 약 65토큰 수준으로 돌았지만, GPT-5.3-Codex-Spark는 목표를 초당 1,000토큰 가까이로 밀어 올리면서 반복적인 request validation, routing, history 처리 비용을 그대로 드러냈다. OpenAI는 persistent connection을 유지하고, 이전 response state를 메모리에 재사용하고, tool 왕복마다 같은 작업을 다시 하지 않도록 바꿨다고 설명한다. 그 결과 production traffic에서는 초당 4,000토큰 burst도 나왔다고 적었다.

왜 빌더가 신경 써야 하나

가장 강한 증거는 실제 채택 속도다. OpenAI는 Codex가 Responses API 트래픽 대부분을 빠르게 WebSockets로 옮겼고, Vercel은 최대 40% 낮은 지연, Cline은 39% 빠른 multi-file workflow, Cursor는 OpenAI model에서 최대 30% 속도 향상을 봤다고 적는다. 이 수치들은 protocol 선택을 곧 product 체감으로 바꾼다. model 행동과 tool 결과 사이의 빈 시간을 줄이는 일이 agent 경험에서는 핵심이기 때문이다.

OpenAIDevs 계정은 보통 빌더에게 직접 영향을 주는 변화를 올리는 채널이다. 그래서 이번 신호는 미래 약속이 아니라 이미 운영에 들어간 최적화에 가깝다. 다음 관전점은 더 많은 agent framework가 persistent connection을 기본값으로 채택하는지, 그리고 browser automation이나 computer use처럼 tool 왕복이 잦은 표면에도 같은 지연 절감이 이어지는지다. 추론이 더 빨라질수록, 주변 시스템에서 그 속도를 낭비하지 않는 쪽이 이긴다. 출처: OpenAIDevs source tweet · OpenAI engineering 글