SSE vs WebSockets for AI apps: ten web standards and two patterns

Out of the box, the official OpenAI and Anthropic Python SDKs talk HTTP/1.1, a protocol from 1997 (RFC 2068). Both build on HTTPX2, which leaves HTTP/2 off unless you turn it on (OpenAI SDK, Anthropic SDK, HTTPX2).

Streaming answers? When they stream over HTTP, both APIs use Server-Sent Events, a W3C standard since 2015 (OpenAI, Anthropic, W3C). Live voice? OpenAI recommends WebRTC for browser and mobile clients (OpenAI). Even MCP’s Streamable HTTP transport, which remote MCP servers use, sends HTTP POST requests, with SSE for streaming. Since the 2026-07-28 revision, each POST gets back either JSON or its own SSE stream, and the old always-open GET stream is gone (MCP).

Here are ten web standards and two patterns, with what each is good for in AI and where it falls short. Years mark standardization, not adoption. They don’t all compete: some are HTTP versions, others are transports, browser APIs or an authentication scheme, and several stack. HTTP/3 runs on QUIC (RFC 9114), and SSE works over any HTTP version.

SSE or WebSockets?

If only the server talks while an answer streams, SSE is often enough. Reach for WebSockets when both sides talk at once.

Feature	SSE	WebSocket
Direction	Server to client	Both ways
Data	UTF-8 text	Text and binary frames
Runs over	An ordinary HTTP response	Its own protocol, after an HTTP upgrade
Use it for	Streamed answers, progress, notifications	Live sessions where both sides talk
Standardized	WHATWG HTML, W3C since 2015	RFC 6455, in 2011

With SSE, the client still talks back, just with separate HTTP requests. Binary data has to be encoded as text first.

Pick by job

You need to	Start with	Spec
Make one API or tool call at a time	HTTP/1.1 is fine	RFC 9112
Stream a model’s answer, progress or notifications	SSE	WHATWG HTML
Run a live session where both sides talk	WebSocket	RFC 6455
Add live voice or camera from a browser or phone	WebRTC	W3C
Make several API or tool calls at once to one origin	HTTP/2, or HTTP/3 on lossy networks	RFC 9113, RFC 9114
Run a complex read-only search with a body	HTTP QUERY, once every hop supports it	RFC 10008
Mix must-arrive results with droppable live updates	WebTransport	W3C CR
Show a site which agent is calling	Web Bot Auth	IETF draft
Follow a long job	Polling, or a webhook to your server	MCP Tasks, OpenAI

Established

HTTP/1.1

1997 · Simple requests and responses, first specified in RFC 2068. RFC 9112 is the current version.

• Good for: single API calls and tool calls.
• Falls short: no multiplexing. Parallel requests usually need several connections, and pipelined responses still come back in order.

WebSocket

2011 · A two-way connection kept open, carrying text or binary frames (RFC 6455).

• Good for: live sessions where both sides talk, like server-side voice agents.
• Falls short: for one-way text streaming, SSE is often enough.

SSE

2015 · Text pushed from server to client over HTTP (WHATWG HTML).

• Good for: streamed answers, progress updates and notifications.
• Falls short: no binary messages, and no two-way traffic on the same stream.

HTTP/2

2015, updated 2022 · Many streams over one TCP connection. RFC 9113 replaced the original RFC 7540.

• Good for: an agent making several API or tool calls at once to the same origin. Native gRPC uses it (gRPC).
• Falls short: one lost TCP packet can delay every stream on that connection.

QUIC

2021 · Encrypted transport over UDP with independent streams (RFC 9000).

• Good for: a connection can survive a device changing networks, if the server allows it (§9). A lost packet holds up only the streams with data in it, which can be several, while the rest keep going (§13).
• Falls short: some networks block UDP. Fallback is up to the app (RFC 9114).

WebRTC

2021 · Real-time audio, video and data. It first became a W3C Recommendation in January 2021.

• Good for: live voice and camera with a model, from a browser or phone.
• Falls short: often unnecessary for text. It needs connection setup, and maybe a relay server.

HTTP/3

2022 · HTTP over QUIC instead of TCP (RFC 9114).

• Good for: it can cut setup time and cross-stream delays on lossy networks.
• Falls short: making the model faster.

New standard

HTTP QUERY

June 2026 · Like GET, but with a request body. It’s safe and idempotent (RFC 10008).

• Good for: complex read-only searches like AI retrieval, with safe retries and caching where supported.
• Falls short: relying on it before your whole stack supports it: client, CDN, proxies and server.

Still developing

WebTransport

W3C Candidate Recommendation · Reliable streams plus droppable datagrams. Major browsers have shipped it since March 2026; older ones and embedded webviews need a check (MDN).

• Good for: results that must arrive next to live updates that can go stale.
• Falls short: code that can’t absorb changes. The IETF protocol is still a draft (IETF).

Web Bot Auth

IETF draft · Signed requests that show a site which agent is calling.

• Good for: telling real agents from bots posing as them. Cloudflare already checks these signatures (Cloudflare).
• Falls short: deciding what an agent may do. It proves identity, not permission.

Patterns, not protocols

Polling

Asking the server again and again whether something changed.

• Good for: long AI jobs where checking every few seconds is fine, like MCP tasks. Where client and server support the Tasks extension, each job gets a handle to poll, and a client can pick it up again after reconnecting.
• Falls short: live updates. You either waste requests or lag behind.

Webhooks

An HTTP request a service sends you when something happens.

• Good for: telling your system that a batch run or agent task has finished. OpenAI, for one, sends them for batch and background jobs (OpenAI).
• Falls short: they can’t reach a browser tab directly. Receiving them is a small integration of its own: a server that verifies signatures, handles duplicate deliveries and passes the event on.

I first shared this list on LinkedIn on 20 October 2026.