Add support for WebSocket mode in Responses API

[thanoskaravangelis]

The Go SDK supports the Responses API over HTTP and SSE streaming, but it does not appear to provide a first-class client surface for the Responses API WebSocket mode documented here:

WebSocket mode guide

This request is specifically about Responses API WebSocket mode on /v1/responses, not the Realtime API.

Why this matters

The WebSocket mode is a useful execution model for long-running, tool-call-heavy workflows:

• persistent WebSocket connection to /v1/responses
• response.create events over the socket
• incremental turns using only new input items plus previous_response_id
• compatibility with store=false and Zero Data Retention
• optional warmup with generate: false
• the same response chaining semantics as HTTP mode, but with lower continuation overhead on an active connection

This mode boosts agentic workflows with many model-tool round trips, and can reduce end-to-end latency significantly. The docs specifically mention that for rollouts with 20+ tool calls, OpenAI has seen “up to roughly 40% faster end-to-end execution.”

That makes this especially relevant for coding agents, orchestration loops, and other iterative tool-using systems in Go.

What seems missing in openai-go

Today, it looks like users need to hand-roll their own WebSocket client and event handling around /v1/responses. A first-class SDK surface would help a lot.

Useful additions would include:

• a supported WebSocket client for Responses API WebSocket mode
• typed request/event models for:
  • response.create
  • response streaming events over the socket
  • error events such as previous_response_not_found
• helpers for incremental continuation with previous_response_id
• examples for tool-call-heavy agentic flows using WebSocket mode
• support for request warmup with generate: false

Why this should live in the SDK

Without SDK support, Go users have to implement and maintain:

• websocket connection setup and auth
• event encoding/decoding
• response lifecycle handling
• incremental continuation logic
• reconnect/recovery behavior
• typed wrappers around socket events that conceptually belong to the Responses API

This is exactly the kind of integration work the official SDK can standardize.

Distinction from Realtime API

This is not a request for Realtime API support.

It is a request for first-class support for the Responses API WebSocket mode documented under the Responses API/run-and-scale docs. The transport is WebSocket, but the model here is still Responses API semantics on /v1/responses.

References

• WebSocket mode guide: https://developers.openai.com/api/docs/guides/websocket-mode