feat(llm): investigate WebSocket mode + previous_response_id continuation for Responses (GPT-5.6)

📄 Study page: WebSocket mode + previous_response_id on the OpenHands SDK

Summary

OpenAI's WebSocket mode keeps a persistent connection to /v1/responses and continues each turn by sending only new input items plus previous_response_id. For tool-heavy rollouts (20+ tool calls) OpenAI reports up to ~40% faster end-to-end execution. This issue tracks investigating it for the SDK.

What the feature needs (from the OpenAI docs)

• Persistent wss://api.openai.com/v1/responses connection; each turn is a response.create event (mirrors the normal create body; stream/background unused).
• Continuation via previous_response_id + only new input items (tool outputs, next user message).
• Optional generate: false warmup to pre-stage tools/instructions and get a chainable response id.
• Connection-local cache of one previous-response state; store=false/ZDR has no persisted fallback → previous_response_not_found if the id is evicted.
• 60-minute connection cap (websocket_connection_limit_reached); sequential responses per connection (no multiplexing); reconnect/recovery patterns.
• Compatible with ZDR and store=false; interacts with compaction (context_management server-side, or standalone /responses/compact).

Gaps in the current SDK

• The Responses path calls litellm_responses / litellm_aresponses over HTTP only. → openhands-sdk/openhands/sdk/llm/llm.py:1618 / :1765
• We default to store=false and replay the full input each turn — previous_response_id chaining is not used anywhere in llm.py. So we don't benefit from incremental continuation even on HTTP.
• No websocket transport, no warmup, no reconnect/60-min handling.

Why it matters for OpenHands

Agent loops are exactly the "many model↔tool round trips" workload the feature targets. Even without websockets, adopting previous_response_id continuation (when store=true is acceptable) would cut per-turn upload of the growing transcript.

Proposed scope / phasing

1. Phase 0 (transport-independent): evaluate previous_response_id continuation on the existing HTTP path for stored responses; measure token/latency impact.
2. Phase 1: prototype the websocket transport (blocked on LiteLLM exposing a websocket Responses transport — needs upstream check).
3. Phase 2: warmup (generate:false), reconnect + previous_response_not_found recovery, 60-min reconnect.

Notes / open questions

• Biggest dependency: does LiteLLM support (or plan) a websocket transport for the Responses API? If not, this may need a direct-client path or an upstream LiteLLM contribution. Flagging low-confidence on near-term actionability until that's confirmed.
• Continuation semantics must play nice with our condenser/compaction and with reasoning-item replay for stateless requests.

Investigation for GPT‑5.6 feature parity. Companion issues: programmatic tool calling, tool search, multi-agent.

Companion investigation issues (GPT‑5.6 Responses features): #4082 (Programmatic Tool Calling) · #4083 (Tool search) · #4084 (WebSocket mode) · #4085 (Multi-agent)

Start with the study page and the Responses calls in openhands-sdk/openhands/sdk/llm/llm.py at lines 1618 and 1765. First check whether LiteLLM exposes a WebSocket Responses transport, then evaluate the Phase 0 HTTP continuation path, including stored responses and existing compaction or reasoning-item handling. Done means documenting the dependency, measured continuation impact, and a viable scope for transport, warmup, and reconnect recovery.