Ably vs PubNub for AI applications: streaming continuity, duplicate delivery, and agent visibility compared

• Ably and PubNub differ at two levels. At the transport layer, Ably uses WebSocket-native connections while PubNub uses long-held HTTP requests. At the product layer, each has built different AI-specific features on top of that transport: PubNub's investment is Illuminate, a fleet-level anomaly-detection layer, while Ably's is AI Transport, a session-continuity, deduplication, and presence layer.

• Ably and PubNub are evenly matched on message ordering; both guarantee order per channel. But they perform differently in production when it comes to connection recovery, duplicate-tool-call handling, multi-device continuity, and agent visibility.

• The differences between Ably and PubNub show up in four scenarios: a connection dropping mid-response, a retried tool call, a device switch, and a stalled agent. This is because handling each one well requires session continuity, deduplication, and presence built into the delivery layer, which PubNub doesn't provide out of the box.

The two platforms take different approaches at the transport layer, which is worth understanding before looking at how each platform's connections actually behave.

PubNub's own connection-management documentation describes its subscribe mechanism as a long-held HTTP request: the server holds each request open until a message arrives or 280 seconds pass, then the SDK reissues it. Some PubNub SDKs offer a WebSocket-compliant interface, but it wraps this same long-held-request cycle rather than replacing it with a true persistent connection.

Ably's connections are WebSocket-native by default, with SSE, MQTT, and a long-polling fallback reserved for environments that can't support WebSockets at all (such as behind a restrictive corporate proxy or VPN).

This difference between a persistent connection and a long-held request has two implications for AI applications:

1. A persistent WebSocket, like Ably's, skips the repeated connection setup that a long-held HTTP request, like PubNub's, requires. That can mean fewer connection-setup gaps and steadier latency for a continuous token stream. Note: this is inferred from documented connection mechanics, not a benchmarked result.

2. Ably's SSE, MQTT, and long-polling fallback handles a load balancer or CDN timing out a long-lived connection, with no detection or recovery work needed from the application. PubNub has only its long-held HTTP request to fall back on. If a load balancer or CDN times that out sooner than PubNub's 280-second cycle expects, the SDK just reissues a new request as usual, more often than intended, adding extra connection-setup overhead.

The rest of the difference between the platforms comes down to the AI-specific features each has chosen to build on top of this transport layer, not to the transport layer itself. Those features are where PubNub's and Ably's AI application offerings actually diverge.

PubNub has three AI-adjacent products.

1. PubNub MCP Server lets AI coding assistants like Cursor and Claude Code build PubNub apps via natural language.

2. Illuminate provides realtime decisioning on streaming data for fleet-level monitoring.

3. Blocks.ai is a marketplace where developers list AI agents, connect to them, and charge for access, running on PubNub's realtime infrastructure rather than its own.

None of the three provides resumable token streaming, multi-device session continuity, or agent presence. Ably, on the other hand, provides all three as part of AI Transport. The rest of this page covers the impact of this on their performance when it comes to streaming tokens in production.

Five properties separate a good demo from a dependable production AI feature: delivering messages in the order they were sent, resuming a response after a dropped connection, avoiding a duplicated side effect when a tool call is retried, keeping a conversation continuous across devices, and knowing whether an agent is still working.

Message ordering is one property both platforms handle identically, so it isn't a point of difference. Across the other four - connection recovery, duplicate-tool-call handling, multi-device continuity, and agent visibility - what diverges is how much each platform gives you by default, and how much your team has to build yourself.

A dropped connection during a streamed AI response isn't just a lost message: it can mean the user never sees the rest of the answer.

By default, nothing recovers automatically. PubNub's own documentation describes live delivery as "at-most-once." A subscriber can miss messages if its buffer overflows (100 messages, up to 16 minutes) or if it's disconnected when a message is published. For a streamed AI response, tokens generated during that gap are lost from live delivery. Recovering them means enabling Message Persistence yourself, tracking the last received timetoken, and replaying history from that point after reconnecting.

Ably's connection recovery keeps the session continuous automatically. Once the client reconnects, Ably replays any missed messages in order. This happens within a live recovery window (typically around two minutes) beyond which Ably falls back to channel history instead. AI Transport builds on this for AI applications by publishing into the session rather than a single connection. This means that a reconnecting client picks the stream back up from the exact token it last received.

A duplicated side effect from a retried tool call isn't just a rough UX edge: a double-booked appointment or a duplicate message sent is a correctness bug, not a cosmetic one.

No. PubNub's own documentation is explicit that it has no server-side or publish-side deduplication mechanism, so publishing the same payload twice always creates two distinct messages. Some SDKs offer subscribe-side deduplication, but only for messages sharing the same timetoken, publisher, and payload, which a genuine retry never does. PubNub's own guidance for exactly-once processing is to add your own idempotency key and deduplicate on the receiving side.

By default, Ably deduplicates automatically. It publishes idempotently in current SDKs, using a unique key per message to detect and suppress resends at the platform level, within a two-minute detection window, with no application-side code required. Combined with per-channel ordering, this provides exactly-once processing (within a two-minute window), unlike PubNub's at-most-once delivery with no dedup layer of its own.

A conversation that resets when a user switches devices feels broken, even though nothing actually failed.

Not automatically. A PubNub User ID can span multiple devices, but each device's subscription is independent and doesn't share conversation state. Picking up on a second device means your team has to build the logic to persist and re-hydrate that state.

Ably's channels already let multiple devices subscribe to the same realtime state, and AI Transport's multi-device sessions feature packages this for AI conversations. Every device on the same session channel sees the same conversation state in realtime, so switching devices mid-conversation needs no application-level state transfer.

A stalled agent looks the same as a working one from the outside, unless something surfaces the difference.

Only if you build that visibility yourself. PubNub's Presence State lets any client attach custom status data to a channel. It's a primitive, not a packaged feature, so you decide the state shape, when it updates, and how a dashboard consumes it. There's no built-in "agent status" concept out of the box.

Ably's presence mechanism lets any client publish and observe realtime state changes on a channel. AI Transport's agent presence feature uses this for AI sessions. An agent publishes its own state (thinking, streaming, idle, or offline) on the session channel, and every subscribed client sees it immediately, with the state shape and lifecycle already defined.

This also separates a transport problem from a model problem. If presence is still "thinking" but no tokens arrive, the delay is in the model or agent logic. If presence goes silent, the disconnection is at the transport layer instead.

Each comparison above looked at one property on its own. Here's what those same differences look like in four concrete situations, and how PubNub and Ably handle each one.

A user is reading a streamed AI answer when their laptop briefly loses its network connection for longer than the subscriber buffer can absorb. On PubNub, the tokens generated during that gap are gone from live delivery once the buffer overflows. The application either shows a broken response or has to replay from Message Persistence, if enabled, using its own tracked timetoken. On Ably AI Transport, the client reconnects and resumes exactly where the stream left off, with no buffer limit to exceed and no history query required.

An AI agent is mid-task when the connection drops briefly. The agent retries a tool call, such as creating a calendar event or submitting a form, before the acknowledgment arrives. On PubNub, both the original and the retried publish are delivered as two distinct, undeduplicated messages. The downstream system has to detect and discard the duplicate message itself. On Ably, the idempotency key suppresses duplicate messages at the platform level, so the downstream system receives the tool call once.

A user closes their laptop mid-conversation with an AI assistant and picks up their phone to continue. On PubNub, this is a new subscription with no relationship to the old one, unless the application has built and maintained its own cross-device state sync. Both devices share a User ID, but a shared ID doesn't carry conversation state along with it. On Ably AI Transport, both devices subscribe to the same session channel, so the phone shows the conversation exactly where the laptop left it.

A supervisor overseeing several live AI support conversations needs to know, at a glance, which sessions are progressing and which have stalled. On PubNub, this means instrumenting a custom status-message convention on top of Presence State across every session, since there's no built-in agent-status concept. On Ably AI Transport, agent presence surfaces this directly. Each session's agent state is visible to any subscribed dashboard in realtime, with no custom schema to design.

Although PubNub's offering is more limited for AI use cases, it's still a reasonable choice in scenarios like these:

• Your AI feature streams to a single device in a single session, with no requirement for the conversation to survive a device switch.

• Occasional lost tokens during a rare, extended disconnection are an acceptable user experience, and regenerating a response is cheap enough not to matter.

• Your tool calls are read-only or naturally idempotent, so an occasional duplicate delivery has no real-world side effect.

• You want built-in, no-extra-pipeline anomaly detection across streaming data (via Illuminate) more than you need session-level continuity primitives.

• Your team has the capacity to build and maintain custom reconnection, offset-tracking, deduplication, and presence-state logic on top of PubNub's primitives.

Ably's AI Transport is purpose-built for AI applications, and it's the better fit in scenarios like these:

• Your token stream benefits from a persistent, WebSocket-native connection rather than a long-held HTTP request, for steadier latency and a fallback that handles both blocked networks and CDN or load-balancer timeouts automatically.

• Users expect a conversation to survive a dropped connection or a device switch without restarting or losing context.

• Any tool call with a side effect (booking, payment, or sending a message) can't be delivered twice, and you don't want to build and maintain your own deduplication layer.

• You need visibility into whether an agent is actively working, stalled, or has crashed, without designing a custom presence-state schema yourself.

• You want this session and delivery layer to work alongside your existing model provider and agent framework rather than replace either.

PubNub gives you capable primitives for AI applications: guaranteed per-channel ordering and, with Illuminate, a genuinely useful decisioning layer on top of streaming data. What it leaves for your team is the layer that turns those primitives into connection recovery, exactly-once tool calls, multi-device continuity, and agent visibility for AI-specific use cases. Ably, through AI Transport, treats those four as properties of the session layer itself. A dropped connection, a retried tool call, a device switch, or a stalled agent doesn't automatically become a broken user experience.

The question to ask: can your product tolerate an occasional lost stream, a rare duplicate side effect, or a conversation that doesn't survive a device switch, today? And can it tolerate an agent that goes quiet with no way to tell why? If so, building on PubNub's primitives, and Illuminate if fleet-level anomaly detection matters to you, is a reasonable starting point. If continuity, exactly-once delivery, and visibility are core to the AI experience you're shipping, that's exactly what a dedicated session layer is built to handle.

Start building on Ably for free, or talk to an engineer about your AI streaming requirements.

They're evenly matched. PubNub assigns each published message a monotonically increasing timetoken, so tokens on a channel form a single ordered sequence for both live delivery and Message Persistence retrieval. Ably guarantees ordering the same way, per publisher per channel, using a unique incrementing serial. On PubNub, the risk to watch for in a token stream isn't reordering, it's loss. If a subscriber's buffer overflows or it's disconnected, tokens are dropped rather than delivered out of order. Ably's replay-on-reconnect avoids that gap within its recovery window.

PubNub has no server-side or publish-side deduplication, so a retried tool call always creates a second, distinct message that your application has to detect and discard. Ably suppresses the duplicate at the platform level by default, using idempotency keys.

On PubNub, a shared User ID doesn't mean shared conversation state: each device subscribes independently, so your application has to persist and re-hydrate state itself. Ably AI Transport puts every device on the same session channel automatically.

PubNub's Presence State is a real primitive for this, but the status shape and update logic are yours to design. Ably AI Transport ships agent presence as a defined feature on the same kind of primitive, with no schema to design.

No. PubNub's closest products, PubNub MCP Server, Illuminate, and Blocks.ai, solve different problems: developer tooling, fleet-level decisioning, and an agent marketplace, respectively.

No, neither does. Both sit between your agent and your users as a delivery and session layer, regardless of which model or agent framework you're using. The difference isn't whether they replace part of your AI stack. It's how much of the continuity, deduplication, and presence behavior each one provides by default, versus what it leaves for your team to build.