WebSockets vs. Server-Sent Events for AI Features

"Real-time" gets reflexively translated to "WebSocket" in a lot of AI-generated code, even when the feature only ever sends data in one direction. That's usually the wrong call — WebSockets are heavier infrastructure than the job needs, and Server-Sent Events (SSE) cover the vast majority of "stream this to the browser" use cases with a fraction of the complexity. Knowing which one you actually need saves you from debugging reconnection logic you didn't need to write.

The one question that decides it

Does the browser ever need to send more than the initial request?

• No → use SSE. Streaming LLM tokens, live log tails, a progress bar, a notification feed — all one-directional, server-to-client. This is /api/chat on this very site: the browser sends one prompt, the server streams tokens back, done.
• Yes, and it needs to happen mid-stream → use a WebSocket. A multiplayer cursor, a live chat where both sides type, a collaborative editor — the browser needs an open channel to send and receive without re-establishing a connection each time.

If you're building a chat interface for an LLM and the "chat" is really just repeated request/stream cycles (user sends a message, waits for the full response, sends the next one), that's still SSE per request — you don't need a persistent bidirectional socket just because the UI looks like a chat window.

Why SSE is the simpler default

SSE rides on top of plain HTTP. That means:

• It works through the infrastructure you already have — reverse proxies, CDNs, and load balancers understand HTTP; WebSockets need to be explicitly proxied and can get silently dropped by infrastructure that doesn't expect a protocol upgrade.
• Reconnection is built into the browser. EventSource automatically reconnects on a dropped connection with no code from you. A WebSocket disconnect requires you to detect it and re-establish the connection yourself, usually with backoff logic.
• The server-side code is a plain HTTP response. No separate WebSocket server, no upgrade handshake — you write a route handler that streams chunks, same as any other endpoint.

The tradeoff: SSE is one-directional and text-only (no binary frames), and browsers cap concurrent SSE connections per origin at 6 over HTTP/1.1 (HTTP/2 removes this limit — another reason to make sure your deploy target serves over HTTP/2).

Why WebSockets earn their complexity sometimes

A WebSocket is a persistent, full-duplex TCP-like connection. Once open, either side can send at any time. That's the right tool for:

• Collaborative state — multiple users editing the same document, cursor positions, live presence indicators.
• Low-latency bidirectional exchange — a voice-to-text feature streaming audio chunks up while streaming partial transcripts down, simultaneously.
• Anything where the client-to-server direction is itself streaming, not just occasional requests.

The cost is operational: you need a process that holds connections open (harder to scale statelessly than plain HTTP request handlers), you own reconnection and message-ordering logic, and most serverless platforms either don't support long-lived WebSocket connections at all or require a separate always-on service for them.

A concrete decision example

Say you're adding a feature where an AI assistant narrates progress while it works through a multi-step task (planning → searching → synthesizing — the shape of a deep-research tool). Even though it feels like a live multi-stage process, the browser only ever listens — it never needs to interrupt or send follow-up input mid-stream. That's SSE: one connection, multiple named event types (phase, token, done) distinguishing what kind of update just arrived, no WebSocket required.

Now say you're adding a feature where two users can both nudge the same AI-generated diagram in real time and see each other's edits instantly. That needs a WebSocket, because both sides are simultaneously senders and receivers on the same channel.

The takeaway

Reach for SSE first. It's simpler to build, simpler to deploy, and covers streaming LLM output, progress updates, and live feeds — the large majority of what "real-time AI feature" means in practice. Only step up to a WebSocket when the client genuinely needs to push data back through the same open connection while it's receiving, not just make another request.