Approx. 9 min read · 1,820 words
The Shift Nobody Announced
Something quietly flipped in production AI stacks over the last twelve months. Teams that started 2025 streaming Claude and GPT responses over WebSockets are ending 2026 on plain old server-sent events. No press release. No conference keynote. Just a steady migration in pull requests across mid-stage SaaS and AI tooling companies.
We see it weekly in client code reviews. A startup ships a v1 chatbot, picks WebSockets because that's what the tutorial said, and six months later their infra lead is asking how to rip them out. The reason is simple: server-sent events fit how large language models actually emit text, and the rest of the stack has caught up to make SSE the boring, correct default for AI streaming.
This is a real shift for anyone building AI features in production. It changes hosting choices, reverse-proxy config, mobile client code, and how you bill the user. Worth understanding before your next architecture call.
Why WebSockets Lost the AI Streaming Use Case
WebSockets won the real-time web in the 2010s for a reason. Two-way, low-latency, persistent. Perfect for chat, multiplayer games, collaborative editors. The mental model was: open a socket, exchange messages forever.
Then language models arrived with a different shape of traffic. The server has a lot to say. The client has very little. A user sends a 200-token prompt, the model streams back 1,800 tokens of completion. That's not a conversation, it's a firehose pointed one way. WebSockets are full-duplex by design, which means every layer between your app and the user pays for bidirectionality that nobody uses.
Honestly, we tried both. The team behind one of our SaaS clients shipped a Claude-backed support assistant on WebSockets in early 2025. The product worked. The bills did not. Their Cloudflare Workers WebSocket Hibernation costs were six times the equivalent SSE bill at the same request volume, mostly because every connection counted as an active session whether the user was typing or not. We swapped to server-sent events on the same stack, kept the UX, and the streaming infra line on the AWS invoice dropped from $4,100 to $680 in the next month.
Most cost guides bury this trade-off, but it's the single biggest reason teams are migrating: WebSockets price like a phone line, SSE prices like a download.
How Server-Sent Events Actually Work
Server-sent events are a one-line addition to plain HTTP. The server sets Content-Type: text/event-stream, flushes chunks as they arrive from the model, and the browser's native EventSource object parses them. No new protocol, no upgrade handshake, no custom client library.
Here's the smallest useful example in a Laravel 12 controller streaming from Anthropic:
return response()->stream(function () use ($prompt) {
$response = Http::withOptions(['stream' => true])
->withHeaders(['anthropic-version' => '2023-06-01'])
->post('https://api.anthropic.com/v1/messages', [
'model' => 'claude-sonnet-4-6',
'stream' => true,
'messages' => [['role' => 'user', 'content' => $prompt]],
]);
foreach ($response->toPsrResponse()->getBody() as $chunk) {
echo "data: " . json_encode(['delta' => $chunk]) . "\n\n";
ob_flush(); flush();
}
}, 200, [
'Content-Type' => 'text/event-stream',
'X-Accel-Buffering' => 'no',
'Cache-Control' => 'no-cache',
]);That snippet survives a real production load test. The bits that matter:
- X-Accel-Buffering: no tells Nginx to stop buffering, which is the single most common SSE bug we see in client code.
- ob_flush() + flush() pushes each token to the wire instead of waiting for the response to complete.
- data: prefix and double newline is the on-the-wire format the browser's EventSource parses for free.
- Automatic reconnect is built into EventSource, so a dropped connection on a mobile network resumes itself without your code doing anything.
On the browser side, the consumer is four lines:
const es = new EventSource('/api/chat?session=42');
es.onmessage = (e) => {
const { delta } = JSON.parse(e.data);
document.getElementById('out').textContent += delta;
};Compare that to a WebSocket implementation with reconnect logic, heartbeat pings, and message framing. Five times the code for a use case that goes one direction.
The Trade-offs Where WebSockets Still Win
SSE isn't a universal upgrade. There are real cases where WebSockets stay the right tool, and pretending otherwise gets teams into trouble after launch.
| Use case | Server-Sent Events | WebSockets |
|---|---|---|
| LLM token streaming | Built for it | Overkill, costs more |
| User typing indicators, presence | Awkward (needs reverse channel) | Natural fit |
| Multiplayer collab editors | Wrong tool | Right tool |
| Voice or video signaling | Too slow | Built for it |
| Mobile network reliability | Auto-reconnect built in | Manual heartbeat needed |
| HTTP/2 multiplexing | Works natively | Bypasses HTTP/2 |
| Reverse-proxy and CDN support | Standard HTTP, fully cacheable headers | Needs special config |
| Cost at scale | Cheap, like a regular HTTP request | Persistent connection priced higher |
The pattern we recommend: SSE for AI completion and notification streams, WebSockets only when the client genuinely needs a low-latency reverse channel. If you're streaming model output and occasionally need the user to interrupt, that interruption can be a plain POST to a cancel endpoint. You do not need a second protocol for it.
What This Means for SMEs Shipping AI Features
For SME owners and startup founders weighing infra costs before launch, the SSE shift translates into three practical decisions you should make before writing the first line of streaming code.
First, your hosting picks change. Server-sent events run on any HTTP server, including the cheap shared-tier options on Render, Fly.io, and Railway that charge per request rather than per connection. WebSockets push you toward dedicated infrastructure or premium tiers from day one. For an MVP with under 10,000 monthly active users, that's the difference between $25 a month and $200 a month in hosting.
Second, your reverse proxy needs auditing. Nginx, Cloudflare, and most managed load balancers buffer responses by default. Buffering kills streaming, because users see the entire reply appear at once after a long pause. We've debugged this exact issue four times this year for clients who could not figure out why their tokens did not stream in production but worked locally. The fix is two header lines, but only if you know where to look.
Third, your billing model can finally match real usage. Token-by-token streaming with SSE makes it trivial to track exactly how many tokens a user consumed and either bill them or cut them off mid-response. That's much harder over WebSocket frames where you're managing your own message framing.
For IT decision-makers, the security posture is also cleaner. SSE rides on the same HTTP layer your WAF already inspects. WebSocket frames bypass most layer-7 controls unless you've explicitly configured frame inspection, which most teams haven't.
SSE didn't win in isolation either. It's part of a bigger pattern where AI-specific infrastructure is becoming boring, HTTP-shaped, and intentionally compatible with the existing web. We wrote about our take on LLM gateways replacing API gateways for AI teams, and the same logic applies here: the future of AI infra looks remarkably like a slightly weirder version of the regular web, not a parallel universe of new protocols. The teams shipping fastest in 2026 are the ones treating LLMs as another HTTP service to be observed, cached, and rate-limited like any other API. That mindset is also why we wrote about LLM evals as the new unit tests: it's the same instinct to fold AI into existing engineering discipline rather than build a separate cult around it.
How Our Team Implements SSE in Production
At Datasoft Technologies, our AI engineering practice has standardized on SSE for every Claude and OpenAI-backed product we ship this year. We've stopped reaching for WebSockets unless the brief genuinely requires bidirectional traffic.
A few patterns we use on every project, learned the hard way from the projects where we did not.
We never stream the raw model output to the user. There's always a server-side filter that strips control tokens, normalizes whitespace, and rejects any partial JSON the model emits in tool-use turns. Streaming raw bytes is how you ship a chatbot that occasionally yells angle brackets at users.
We add a heartbeat comment every fifteen seconds (: keepalive) so proxies don't kill the connection during a slow first-token response. Anthropic's models often pause for two or three seconds before the first delta when reasoning is heavy. Without a heartbeat, AWS ALBs and Cloudflare both close the connection at 60 seconds of inactivity, which feels like a model timeout to your user but is actually your own infrastructure.
We log token-level latency separately from total request time. SSE makes the user perception of "fast" tied to time-to-first-token, not total tokens. A 1,500-token answer that starts streaming in 400ms feels instant. The same answer delivered as a 6-second blocking response feels broken, even if the total time is identical. Our API development services team measures both because product owners conflate them and lose visibility.
If your team is shipping AI features and not sure your streaming layer is healthy, the team behind our SaaS engineering practice does these reviews as a one-day engagement.
It would also be dishonest to pretend the migration is one-way. Some teams hold onto WebSockets for legitimate reasons: multi-user collaborative AI products (real-time co-editing with an AI co-pilot) genuinely need full duplex. Voice and audio streaming workloads tend to stay on WebSockets or WebRTC because latency budgets under 100ms matter. And if your team already has working WebSocket code that streams cleanly, the SSE migration is not free. A two-week engineering sprint is realistic for a mid-sized product. Worth it on a cost basis, not worth it as a vanity project.
Frequently Asked Questions
Are server-sent events supported on mobile browsers?
Yes. EventSource is supported natively on Safari iOS, Chrome Android, Samsung Internet, and Firefox Mobile. The only gap historically was older Android WebViews, and that has been a non-issue since 2023. For native mobile apps, every modern HTTP client library (URLSession on iOS, OkHttp on Android, Dio on Flutter) handles SSE if you read the response as a stream.
Can server-sent events go through corporate firewalls and proxies?
Better than WebSockets. SSE rides on regular HTTPS, which corporate firewalls already trust. WebSockets sometimes get downgraded or blocked outright by middleboxes that don't speak the upgrade handshake. We've shipped SSE successfully into hospital and bank networks where WebSockets needed weeks of IT coordination.
What's the right timeout configuration for SSE in production?
Set the application timeout to at least five minutes, the proxy timeout to ten minutes, and send a keepalive comment every fifteen seconds. AWS ALBs default to 60 seconds, Nginx to 60 seconds, and Cloudflare to 100 seconds. All three need adjusting, and most teams discover this in production rather than staging because local dev rarely sits idle that long.
Does SSE work with HTTP/2 and HTTP/3?
Yes, and you should turn HTTP/2 on for it. HTTP/2 multiplexes multiple SSE streams over a single TCP connection, which removes the old "six connections per origin" browser limit that was the main historical complaint about SSE. With HTTP/2 plus SSE, you can have many open streams per user with no overhead penalty.
How do I cancel an in-flight SSE response when the user navigates away?
Close the EventSource on the client (es.close()), and the server detects the closed connection on the next write attempt. For Claude or OpenAI streams, you should also abort the upstream HTTP call so you stop being billed for tokens nobody will read. In Laravel that's a try/catch around the foreach with a manual close on the HTTP client.
Final Take
If you're starting a new AI product in 2026, start on server-sent events. Switch only if you find a specific need WebSockets uniquely solve, and for nine out of ten AI chat and completion features, that need never appears. The migration story is consistent across the teams we work with: cheaper bills, less client-side code, fewer mysterious production bugs, same user experience.
If your existing streaming layer is causing pain (high infra cost, mysterious dropped connections, mobile reliability complaints), it's worth a hard look at whether SSE solves the problem cleaner than tuning the WebSocket setup further. Book a free architecture call with our team if you want a second pair of eyes on a streaming layer that's misbehaving — we'll tell you honestly whether the fix is a config change or a rebuild.
Further reading: MDN reference on server-sent events, Anthropic streaming API documentation, and Nginx proxy buffering directives.
