Pricing

OpenRTC Free, Hobby, and Paid usage credits

OpenRTC has three public tiers. All use the same versioned usage-credit meter instead of commercial limits on apps, spaces, rooms, members, devices, or tickets.

All tiers currently share the same 50-member room and space safety ceiling. That product boundary is not a higher-priced tier entitlement.

What consumes credit

Credit is consumed by attributable OpenRTC operations, including:

• identity assertion exchange, device enrollment, capabilities, and gateway grants
• room create/join/leave and token mint/exchange
• authenticated coordination connection, presence, signal, and session events
• one distinct Identity Platform monthly active user when that provider is used
• measured relay bytes, connection duration, and requests

Each operation is charged once at its published credit price. There is no separate metering charge.

Live broadcast hosting is a developer preview. Its published delivery value is $0.10 of customer credit per decimal GB delivered to viewers. Production enablement also requires hard limits for viewer concurrency, bitrate, end time, and delivered data. No broadcast charge is implied while production hosting is disabled.

Your account management and support operations do not reduce your credit. Separately purchased boilerplates are not usage-credit events.

Native local-only enrollment, credential verification, mDNS observation, bilateral admission proof, and direct private/link-local edge traffic consume zero OpenRTC usage credits. They do not use the managed gateway or relay. Optional online synchronization is a separate hosted operation.

How the charge is calculated

OpenRTC assigns each metered operation a versioned credit price. The Developer Portal reports both the credit value and the credits actually used after any included-operation discount. Historical charges retain the price version that was active when the operation settled.

Current credit prices

Reviewed against the current customer-price definitions on 2026-10-01. These are customer credit values. The ledger uses integer nano-USD, so display values are rounded.

Relay delivery is measured rather than a flat session price. Its customer credit value is $0.10 per decimal GB delivered by the relay, plus separately metered connection, request, and settlement work. Direct peer-to-peer payload does not consume relay delivery credits.

Managed broadcast delivery is measured separately at $0.10 per decimal GB delivered to viewers. One byte delivered to ten viewers counts as ten delivered bytes. Uploading a host's source once is not multiplied by viewer count.

Simple workload examples

These examples multiply the customer credit prices above by explicit operation counts. They illustrate the meter, not a total monthly bill. Each excludes identity, admission, gateway coordination, and other operations unless listed; actual usage appears in the Developer Portal.

For the room example: $0.000388056 + 10 × $0.000209946 + 10 × $0.000200346. For the relay example: 1 decimal GB × $0.10. A decimal GB is 1,000,000,000 bytes; a GiB is 1,073,741,824 bytes. The relay and broadcast delivery meters use decimal GB.

A $1 promotional Free allowance covers the illustrated relay subtotal, with about $0.90 left for other metered operations. Free requests stop before the allowance is exceeded. Hobby and Paid overage collection remains paused during launch; these examples do not imply unlimited traffic or an included session count.

Runtime limits are safety controls, not tier entitlements

OpenRTC enforces bounded payloads, queries, listeners, concurrency, request velocity, and transient-data retention. These safeguards protect the shared service and are the same on Free, Hobby, and Paid. They are not commercial limits or promises of included capacity.

account-free spaces, authenticated user-scoped discovery, rooms, and tickets are available under both policies; each consumes usage credits at the current operation price.

Free stops before its credit is exhausted. Hobby and Paid can continue into overages only when overages are enabled and never beyond the developer-selected hard cap. Burn-rate controls can pause either tier before a malicious or buggy client creates an unexpectedly large bill.

Reviewed rooms and spaces can use sparse fan-out after the application enables it in the Developer Portal. Public membership updates and private route updates are measured separately, so one distant member change does not resend every member's connection ticket to the whole avenue. The portal remains the sole source of truth for the credits charged.

Relay guardrails

Each app can disable managed relay or lower capabilityManifest.relay.maxPerHour, relay.uploadMbps, and relay.downloadMbps in the Developer Portal. The default is 600 relay-capable gateway admissions per one-hour window; this is an admission guardrail, not a bandwidth allowance or billable-byte measurement. The app's monthly credit cap remains the broader spend ceiling.

While the app permits relay, the gateway counts relay-capable admission from the stored manifest rather than trusting a client's transports.relay value. This means a direct-only client still consumes the conservative admission allowance. Relay usage is measured for the active relay route.

Managed relay sessions are measured from upload bytes, download bytes, and connection time. The current open interval is shown separately as estimated pending usage.

The Mbps settings are not client-negotiated promises. OpenRTC-owned relays can enforce them directly. Managed TURN uses short credential lifetimes, usage detection, and credential revocation, so an established session may transfer traffic during the reporting delay.

Credit reporting

The Developer Portal separates settled credits from active reservations and attributes current usage to the application that created it. Earlier usage without an application breakdown remains visible in the account balance.

Next steps