There is a Redis buffer sitting between your AI backend and your client. Someone on the team added it after the first production incident, and it works. Tokens get written to it as they generate, a reconnecting client reads back what it missed, and full page reloads stop losing responses.
Then the bug reports start arriving from somewhere else. Tab switches. Backgrounded mobile apps. A user who read half a response on their laptop and opened their phone to finish it. Each one gets its own fix, and the buffer becomes a session layer nobody planned or budgeted for.
Most teams building multi-device AI end up here. It's worth knowing what the finished version of that buffer costs before you keep extending it.
What most teams build first
The standard workaround is that Redis buffer. It handles full page reloads reasonably well. It doesn't handle tab switches. It breaks on mobile backgrounding. And it has no path for multi-device delivery, because the session state is scoped to one client rather than to the user.
Every serious production team discovers this wall independently and ends up engineering some version of the same architecture. Vercel's own lead maintainer named the fix directly: solving it needs a channel back to the server that can carry that information, and WebSockets are one way to do it. The Redis buffer is an approximation of the real answer.
Why this breaks
HTTP streaming is stateless. Each connection is independent, tied to a specific device and browser session, so when the user switches devices, refreshes, or loses connectivity, the new device has no position in the stream. It doesn't know which tokens the previous device received, it can't resume mid-response, and it starts over.
There's no shared state across connections. Device B has no visibility into what Device A received, and without session tracking built into the architecture, the server treats each connection as a new actor. A stateless delivery layer wasn't designed for conversations that span sessions, devices, or time.
What you end up owning
Teams building multi-device AI experiences without dedicated infrastructure inherit the same set of problems, and each one becomes code your team writes and maintains.
Detecting completion nobody received. The model finishes generating while the user is offline or mid-switch. You now need to know that the output exists, that it went undelivered, and where to hold it until someone reconnects.
Deduplicating repeat work. The user can't tell whether the previous session completed, so they re-prompt. You pay for the same generation twice, and you need request-level idempotency to stop paying for it three times.
Reconciling conflicting state. A new prompt arrives from the phone while the laptop tab still shows an incomplete response. Deciding which version is canonical is your logic to write, and it lives in a place where a bug corrupts a conversation rather than throwing an error.
Maintaining a mobile-specific path. iOS and Android background apps aggressively drop connections, and WiFi-to-cellular handoffs are constant. Whatever works on desktop needs a second implementation with explicit reconnection and resume handling, tested against network conditions you can't reproduce locally.
None of these show up in demos. They arrive in production, under real network conditions, with real users. And once they're in your codebase they behave like infrastructure: they need on-call coverage, they break when platforms change, and they never ship and finish.
The architectural shift: state lives in the channel, not the connection
The underlying problem is that session state is coupled to the connection. The fix is decoupling them.
Instead of streaming directly over an HTTP connection, the server publishes messages to a channel. Any device subscribing to that channel receives the same messages. The state is in the channel. The connection is the transport, nothing more.
This is the foundation of what's increasingly called a durable session, a persistent, addressable session between agents and users that outlives any single connection, device, or participant. Durable execution makes the backend crash-proof. Durable sessions make the experience crash-proof. They sit on opposite sides of the agent and complement each other.
In practice this changes the behavior fundamentally. Any device can join, whether that's the same browser tab, a phone, or a tablet. Subscribing to the channel gives that device access to the conversation. Reconnection becomes catch-up rather than restart: channels persist message history, and when a device reconnects, it replays what it missed and transitions to live delivery.
Conflicts route through the server. User actions – sending prompts, interrupting, deleting messages – go to the server, which publishes the authoritative result to the channel. All devices receive the same update. There's no client-side state to reconcile.
What the transport layer has to handle
This is the build list. Each item below is something your team writes and operates, or something you get from a layer designed for it.
Identity-aware fan-out. The system needs to recognize all active sessions associated with a single user and propagate updates across all of them. When a user sends a message on one device, every other active device should reflect the change immediately. That mapping of user identity to active connections has to live in the infrastructure, underneath your application code.
Ordering and session recovery. If the connection drops – from a device switch, a network blip, or a page refresh – the user shouldn't lose messages or see them out of sequence. A well-designed transport layer replays missed events and keeps message sequences intact. History loads first, then the live stream resumes. The client doesn't need to manage the transition.
Token stream compaction. Replaying thousands of individual tokens to a reconnecting device is wasteful. A better pattern compacts token streams into complete responses in channel history: one message per AI response instead of hundreds of tokens. New devices load the complete response instantly, then receive new tokens for any in-progress generation.
Presence tracking. The backend needs to know which devices are currently active. Should the model keep streaming if the user closed the tab? Should a background task escalate if all devices have disconnected? Presence answers these questions from a live membership set rather than polling or timeout heuristics. Without it, systems rely on assumptions that produce missed interactions, wasted compute, and handoffs that arrive too late.
Presence-aware cost controls. AI agents can quietly generate output that delivers no value but incurs real cost – streaming to an empty room, running tool calls after the user navigates away. Tying agent activity to presence means the infrastructure pauses or deprioritizes automatically when no devices are engaged and resumes when they return. Costs scale with actual usage rather than connection count.
Mobile is the hardest case
Mobile devices are the toughest environment for connection continuity.
Network instability is constant, between WiFi-to-cellular handoffs, tunnel blackouts, and dead zones, so resume capability isn't optional. Apps get backgrounded aggressively, so the model might finish generating while the app is suspended, and the completed response has to be waiting when the user returns.
Push notifications bridge the gap. When significant events occur while the app is backgrounded – task complete, human takeover required – notifications alert the user and deep-link directly to the conversation. The payload should carry enough context for the app to restore state without a full reload. Push notification infrastructure (FCM, APNs, Web Push) ships as a supported capability; AI-specific end-to-end delivery patterns are still being documented, so implementation details vary by platform.
Battery is a real constraint too. Holding open WebSocket connections while the app is backgrounded drains it, so you need reconnection strategies that close connections when backgrounded, reconnect on foreground, and use push notifications to trigger reconnects for important updates.
Does your session outlive the connection?
Not every AI application needs any of this. HTTP streaming works well where a user sends a prompt, the model returns a response, and the interaction is complete. Single session, single device, seconds to finish. For that shape of product, HTTP streaming is the right call and a session layer is overhead.
The decision point is whether your sessions outlive a single connection. Sessions that run for minutes or hours. Agents making tool calls mid-conversation or coordinating with other agents. Background tasks that continue while the user is elsewhere. Humans stepping in to approve an action or take over. Users moving between devices. Any one of those and the session exists independently of the connection that created it, so something has to hold it. Either your code does, or a layer underneath does.
32 of 37 vendors evaluated have no multi-device fan-out capability at all, so most teams building this shape of product are writing the layer themselves or shipping without it.
What it costs to build yourself
Building session synchronization in-house means pub/sub channels, message persistence with configurable retention, client SDKs that handle subscription and history replay, presence tracking, mobile SDKs with background handling, push notification support, and identity-scoped authorization. That's weeks to months of engineering before the first version ships, and the edge cases don't surface until production. Then it stays. Reconnection semantics, mobile platform changes, and ordering guarantees keep coming back to whoever built them, for as long as the product exists.
Ably AI Transport implements this model. The docs on channel history and connection state recovery cover what the infrastructure layer has to handle in detail.
