A realtime app’s bill depends on how it delivers updates and what the service meters. Direct peer traffic can avoid a service’s per-message or per-byte payload charge. You still need to account for capacity, connectivity, and the features your application needs.
I build OpenRTC. This is a guide to making that calculation, including the situations where a free library or server-mediated service is a better fit. The examples are modeled arithmetic, not measured benchmarks.
Follow one cursor update
Imagine four people in a room. One moves a cursor and the other three need the new position. There are two useful ways to think about delivery:
- Server-mediated: the sender publishes once; the service delivers to three recipients. The product may count both the publish and the deliveries.
- Direct peers: the sender sends to each of the three peers. The sender’s upload and every recipient’s download still exist, even if the connectivity service does not charge separately for those payload bytes.
A direct path changes where traffic travels and how it may be billed. It does not make bandwidth disappear. A full mesh also asks each participant to maintain more connections as the room grows.
Write down the workload first
Before looking at price tables, record the dimensions that matter:
| Dimension | Why it matters |
|---|---|
| Monthly active users | Distinct people using the app during the billing period |
| Peak concurrent rooms | Rooms that exist at the same time, not total joins |
| Devices in each room | Membership capacity and possible recipients per update |
| Update frequency | Cursor events at 20 Hz behave differently from occasional chat |
| Payload size | Application data before encryption and protocol overhead |
| Active session duration | Time actually sending updates, not merely time connected |
| Delivery requirements | Persistence, replay, ordering, and offline delivery may need other services |
| Route availability | A direct-only design may fail where a relay is necessary |
Monthly active users and simultaneous users are different. Reusing a room does not make a new human disappear from a monthly active-user allowance.
A four-person example
Assume one four-person room, with every participant sending a 128-byte update 20 times per second for ten active minutes. Each update reaches the other three participants; senders do not receive an echoed copy.
Published updates = 4 × 20 × 600 = 48,000
Recipient deliveries = 48,000 × 3 = 144,000
Publish + delivery units = 192,000
Delivered application bytes = 144,000 × 128 = 18,432,000
That is 18.432 decimal MB of delivered application payload. The figure excludes protocol, encryption, presence, signaling, retries, and acknowledgements. For server-mediated delivery it is the modeled recipient payload; for a direct full mesh it is the modeled sum of sender uploads. Do not label it measured network traffic or a guaranteed invoice unit.
Download the model inputs, the results as CSV, or the standalone calculator. Run it with node realtime-workload.mjs after downloading both the calculator and JSON inputs to the same directory. Adjust the inputs to match your app.
Read each service’s counting rules
Supabase documents how Broadcast counts a sent message plus messages delivered to subscribed clients. Ably documents inbound and outbound counting, including echo behavior. Check each service’s allowances, size rules, base subscription, and other billable dimensions before turning message counts into a monthly price.
For small workloads, a competitor’s included free allowance may cover everything. If you already use a backend’s database, authentication, and realtime features, that integration can be worth more than saving on a single messaging dimension.
PeerJS is also a direct-peer option. Its documentation explains the signaling role and the need for TURN in some network conditions. OpenRTC is not the only way to keep application payloads on a direct path.
What OpenRTC charges for
As checked on October 20, 2026, OpenRTC’s public pricing starts at Free and a $5/month Builder plan. Plans meter capacity, including active users, rooms, spaces, and devices. Direct peer messages, connection time, and payload bytes have no separate OpenRTC usage charge. Consult the current pricing page for the full allowances and flat overages.
For the example’s four distinct users, one room, and four devices, Builder’s published allowances cover those dimensions at $5/month, assuming the app also stays within every other allowance. Free’s two-device room limit does not cover this room. Repeating sessions with new people increases monthly active users. This is an eligibility illustration, not a comparison of equivalent complete product bundles or a recommendation to run arbitrary traffic without testing.
Managed TURN and MoQ relays are disabled by default in this release; relay allowances and pricing are not sold here. Do not assume a zero-price managed relay fallback. Room membership allowances also do not guarantee an all-to-all connection topology or a measured room size.
Compare the complete application
Build your estimate in layers:
- Choose a plan that admits your users, devices, and concurrent rooms.
- Calculate billable messaging and traffic using that service’s documented units.
- Add required storage, persistence, server hosting, and any supported relay service.
- Check rate limits and required delivery semantics before comparing totals.
- Validate connectivity on the networks and devices your users actually use.
Use direct peers when the app fits their topology and delivery constraints. Use server-mediated infrastructure when centralized delivery, integrations, retained history, or network reachability are more important to the product.
Sources and limitations
Sources checked October 20, 2026:
No latency, throughput, cross-NAT success rate, or savings percentage was measured for this article. Prices and capabilities can change. The downloadable model counts a stated workload; it does not reproduce a service’s invoice.
Prepared with AI assistance for this founder-led OpenRTC publication. Sources and assumptions are included so you can check the conclusions.