> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
> Use this file to discover all available pages before exploring further.

# WebSocket limits

> Each plan's WebSocket subscriptions, connections, and standard replay speed, and how to size subscriptions, replay jobs, and consumers to them.

Your plan sets how many subscriptions and connections you can hold and how fast a standard replay can run. Size your subscriptions, replay jobs, and consumer to fit inside it. For REST request rates, credits, and the full plan table, see [Rate limits](/rate-limits).

## Limits by plan

| Tier | Subscriptions and connections |
| - | - |
| Free | 10 subscriptions per connection, 2 connections |
| Build | 500 subscriptions per connection, 3 connections |
| Pro | 3,000 subscriptions per connection, 5 connections |
| Scale | 20,000 subscriptions per connection, 16 connections |
| Enterprise | Unlimited subscriptions and connections |

Subscriptions are the most channel-symbol pairs one connection can hold. Connections are the most open WebSocket connections per account.

| Tier | Standard replay speed |
| - | - |
| Free | 10× |
| Build | 50× |
| Pro | 100× |
| Scale | 300× |
| Enterprise | 1,000× |

Standard replay speed is the fastest `speed` a standard timed replay accepts. A higher request runs at your plan's maximum.

Every tier, including Free, has WebSocket access to every channel, including the L3 and L4 channels, except one: the live [`mempool`](/websocket/mempool) channel, which comes with the Pro, Scale and Enterprise plans. Otherwise, plans set capacity and history windows; which channels exist depends on the venue family, as listed in [WebSocket channels](/websocket/channels#channel-reference). Free replay reaches the most recent rolling 30 days, with a maximum 30-day window per replay. Build and above keep the full retained archive.

Each connection accepts at most 10 subscribe or unsubscribe operations per second. A faster burst is refused with `Subscription rate limit exceeded. Please slow down.`, so pace subscribe loops instead of sending a whole symbol list at once.

Live Lighter and Lighter on Robinhood Chain subscriptions count toward the same plan limits as every other live channel, and so does each `mempool` subscription, unfiltered or per symbol. HIP-4 live WebSocket delivery covers trades and L4; use REST for current L2 and open interest, while stored L2 and open-interest history remains replayable.

Core L4 checkpoint-anchored bulk replay is available on every tier. It is a replay format, not bulk WebSocket streaming: the `stream` command has been discontinued, and large dataset downloads use the [Data Catalog](/data-catalog) Parquet export. Core L4 bulk replay ignores `speed`; its limit is the requested window and how fast your client processes checkpoint and batch messages.

## What drives stream load

| Dimension | What to watch |
| - | - |
| Subscription count | Active channel-symbol pairs |
| Standard replay speed | How fast historical events are emitted |
| Venue activity | Busy markets send more messages |
| Data depth | L3 and L4 streams are heavier than trades or tickers |
| Unfiltered `mempool` | Several megabytes per second before compression; subscribe with a symbol where you can |
| Consumer lag | Local queue depth and processing delay |
| Reconnect behavior | Duplicate subscriptions or reconnect storms |
| Output storage | Whether replay output can be written as fast as it arrives |

Start with one symbol and one channel, then widen only after the consumer keeps up without dropping messages.

## Size a client

<Steps>
  <Step title="Start with one channel">
    Confirm connection, auth, message handling, gap handling, and unsubscribe with one channel-symbol pair.
  </Step>

  <Step title="Keep subscriptions explicit">
    Subscribe only to the channels and symbols the job needs, and track them so a reconnect neither duplicates nor loses a subscription.
  </Step>

  <Step title="Bound replay windows">
    Split long replays into windows you can resume and audit.
  </Step>

  <Step title="Avoid reconnect storms">
    Reconnect with capped backoff and jitter.
  </Step>

  <Step title="Measure consumer lag">
    Watch queue depth, processing time, and dropped UI updates before adding channels.
  </Step>

  <Step title="Track gaps">
    Treat gap messages as data-quality events and decide whether the downstream job can continue.
  </Step>
</Steps>

Whether you write the client yourself or an assistant generates it, do not default to the maximum subscriptions or the maximum standard replay speed. Name the channel set, symbols, delivery model, output destination, gap tolerance, and stop condition first, and run a bounded sample.

## Backpressure

Protect the client from message bursts. Use bounded queues, drop or pause noncritical UI updates when necessary, and stop a replay rather than letting memory grow without limit. A replay that cannot be consumed in order is not a trustworthy replay, and a client that receives data faster than it can process it produces stale UI state, dropped messages, or incorrect local books.

Track standard replay speed separately from live subscription count: live subscriptions stress steady-state processing, while replay stresses backlog, ordering, storage, and gap handling. Track core L4 by window and batch volume instead of speed. Check consumer lag before raising either one.

A higher plan limit does not fix a consumer that drops messages or cannot write replay output in order. If one job mixes REST preflights, WebSocket replay, and SDK reconstruction, budget them together as one job, and run the [Data quality](/data-quality) checks before you share the tooling.

## Next step

Choose the channels for your job in [WebSocket channels](/websocket/channels).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.