Does forwarding 100 participants is cosly ?

Thanks for reaching out, Valérian. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Does bandwith send by participant count into the billing for livekit cloud

Thanks — I’m responding to your question about whether bandwidth a participant sends (upstream) counts toward billing in LiveKit Cloud. Short answer: No — upstream bandwidth (data participants upload to LiveKit: their camera, mic, screen-share) is not billed. LiveKit Cloud bills for downstream bandwidth (data the LiveKit servers send out to participants), connection minutes, and any transcoding minutes. If you’d like, I can: • Estimate downstream bandwidth and cost for your scenario if you tell me expected video resolutions, target bitrates, number of viewers, and session length. • Recommend settings to reduce downstream usage (for example: enabling SVC/simulcast, limiting published track resolution, or lowering target bitrates). Which would be most helpful? Sources: Towards a future-aligned pricing model

So if i forward 100 participant to an admin room, it will not cost more right ?

Thanks — I’m responding to your question about forwarding 100 participants into an admin room and whether that will increase cost. Short answer: Forwarding 100 participants into an admin room will increase your downstream bandwidth usage and therefore your bill. LiveKit Cloud does not charge per participant; billing is based on downstream bandwidth (data LiveKit servers send out), connection minutes, and transcoding minutes. So the cost rises because the server must deliver more data to the admin room (and any viewers of that room), not because of a per‑participant fee. A few practical notes: • If the admin room receives individual streams from all 100 participants and the server forwards those streams to the admin(s), downstream traffic into the admin(s) (and any other viewers) is what is billed. • Upstream from participants (their uploads into LiveKit) is not billed. • Transcoding (if you convert/mix/compose streams server‑side) will add transcoding minutes and may increase cost beyond raw downstream bandwidth. If you want, I can: • Estimate downstream bandwidth and cost for your scenario—share expected resolutions/bitrates per participant, number of admins/viewers, and session length. • Suggest optimizations to reduce downstream costs (for example: using SVC/simulcast, limiting published resolutions for the admin view, or subscribing to lower‑resolution tracks for monitoring). Which option would you like to start with?

But if the at the end, participant send their upstream to room A, but nobody subscribe to Room A, but all the tracks are forwarded to room admin, and admin watch the tracks, does it cost more than if admins was watching directly from room A

Thanks — I’m responding to your question about whether forwarding participant tracks from Room A into an admin room (where admins watch the forwarded tracks) costs more than if admins subscribed directly in Room A. Short answer: It costs the same from a downstream‑bandwidth billing perspective if the same encoded streams are delivered to the same number of admin viewers. Billing depends on downstream data sent by LiveKit servers, not the room topology. Details to be aware of: • Upstream (participants uploading to Room A) is not billed. • Downstream (what LiveKit servers send to viewers/admins) is billed. If admins receive the same streams via the admin room as they would by subscribing in Room A, the downstream bytes consumed are effectively the same and will result in the same bandwidth charges. • Additional costs can appear if you perform server‑side processing during forwarding: ◦ If you transcode, mix, or otherwise re-encode tracks when forwarding to the admin room, that will add transcoding minutes and possibly change downstream volume. ◦ If you forward extra copies or different resolutions (for example, forwarding multiple quality layers or unneeded streams), downstream usage can increase. • Practical example: ◦ Case A (admins subscribe directly in Room A): LiveKit sends stream X once per admin viewer — downstream billed for those deliveries. ◦ Case B (tracks forwarded to admin room and admins watch there): LiveKit still sends stream X to each admin viewer from the admin room — downstream billed for those deliveries. Unless forwarding introduces re-encoding or extra copies, downstream bytes are equivalent. If you want, I can: • Estimate downstream bandwidth/costs for your exact scenario—tell me per‑participant bitrate/resolution, how many admins/viewers, and session length. • Recommend optimizations (for example: subscribe to lower resolutions for admin monitoring, use SVC/simulcast, or avoid server-side transcoding) to reduce downstream and transcoding costs. Which would you like to do next?

So to make an admin dashboard to monitor multiple rooms, can i forweard all the tracks to the admin room ? lets say 100 viewers spread across 100 rooms

Thanks — I’m responding to your question about building an admin dashboard that forwards tracks from many rooms (for example, 100 viewers across 100 rooms) into a single admin room. Short answer: Yes — you can forward all those tracks into one admin room for monitoring, and it’s technically feasible. From a billing perspective, cost is determined by downstream bandwidth and any transcoding, not by the number of source rooms. That means the downstream data sent to each admin viewer is what drives charges. What to watch for (practical considerations): • Downstream bandwidth is billed: If admins watch N total streams delivered from the admin room, downstream bytes for those deliveries are billed. Forwarding from many rooms doesn’t add a per‑room tax — the cost follows the bytes sent to viewers. • Upstream is free: Participant uploads into their original rooms are not billed. • Transcoding adds cost: If you re-encode, mix, or transcode streams when forwarding, you’ll incur transcoding minutes and possibly extra downstream if the re-encoded streams are larger. • Duplicated deliveries: If you forward multiple copies or multiple resolutions of the same stream and admins subscribe to each, downstream increases accordingly. • CPU and scaling: Forwarding many streams increases server CPU and network load. LiveKit’s SFU model and techniques like distributing work across cores and SVC/simulcast help, but you should plan capacity for the admin node(s). • UX and bandwidth for admins: Showing 100 live video tiles at once is heavy for client bandwidth and CPU. Consider aggregated views (thumbnails, lower-resolution monitors, or periodic sampling) instead of full-resolution streams for every tile. Recommended approaches to keep cost and load manageable: • Subscribe admins to lower-resolution tracks (or forward lower-res tracks) for monitoring. • Use SVC/simulcast so admins can request only the layer they need. • Forward only necessary tracks (e.g., audio + small video thumbnails) instead of full-resolution video for all participants. • Avoid server-side transcoding unless you need mixed or composed views; prefer forwarding encoded layers when possible. • If you need many streams simultaneously, consider sharding admin monitoring across multiple admin rooms or services to balance CPU and network. • Start with a small pilot and measure downstream usage and CPU to validate estimates. If you want, I can: • Estimate downstream bandwidth and likely cost for your scenario — tell me expected bitrate/resolution per forwarded track, how many admin viewers will watch, and session length. • Suggest a concrete forwarding architecture (SVC/simulcast settings, selective forwarding patterns, and how to reduce admin client load). Which would you like to do next?

This approach is better or its better that the admins are connected to multiple rooms

Thanks — I’m responding to your question about whether it’s better to forward all participant tracks into a single admin room or have admins connect directly to multiple rooms. Below is a clear comparison, trade‑offs, and practical recommendations to help you choose. Short conclusion • There is no one-size-fits-all answer. Both approaches can work. Choose based on admin UX (how many simultaneous streams they need to see), cost goals (minimize downstream + transcoding), and operational complexity. • Key billing driver is downstream bandwidth (data sent to admin viewers) and any transcoding minutes — not the number of rooms. So design to minimize what the admin clients actually download and what the servers re-encode. Comparison: Forwarding all tracks into one admin room Pros • Centralized monitoring: admins connect to a single room and see all feeds in one place. • Easier client management: one connection per admin instead of multiple room connections. • Easier to control/transform streams centrally (e.g., enforce thumbnails, lower resolutions). Cons • Potentially large downstream from the admin room to admins if you forward full‑res streams for many sources. • Server CPU/network load concentrated on the forwarding/relay node(s). If you re-encode or transcode while forwarding, you incur transcoding minutes. • Single point of scale — you must provision admin server(s) to handle many incoming/forwarded streams. When this is a good fit • You want a single dashboard experience and can forward reduced-quality or sampled streams (thumbnails, low bitrate). • You prefer centralized access control, monitoring logic, or auditing. Comparison: Admins connect directly to multiple rooms Pros • LiveKit only sends the streams directly from the origin room to admin clients — no extra forwarding hop. • Potentially lower server-side complexity and less centralized CPU/transcoding if admins subscribe selectively. • Natural isolation and distribution of load across origin room servers. Cons • Each admin may need multiple simultaneous connections (or multiple subscribes) — client complexity and signaling overhead increase. • Admin clients still incur downstream bandwidth for all subscribed streams; if they open many rooms at once, client bandwidth/CPU becomes a bottleneck. • Managing many room credentials/connections, and orchestrating subscriptions across rooms, is more complex. When this is a good fit • Admins only need to monitor a small number of rooms at once, or you can limit what they subscribe to per room. • You want to avoid extra server-side forwarding/transcoding and rely on origin rooms’ SFU delivery. Practical cost & performance considerations (apply to both) • Downstream bandwidth to admin viewers is billed. Minimize what admins download (lower bitrate, thumbnails, audio-only). • Avoid server-side transcoding unless required — transcoding adds cost. • Use SVC/simulcast so you can request lower-quality layers for monitoring. • Don’t forward multiple copies/resolutions unless needed. • Consider sharding monitoring load across multiple admin nodes or rooms to avoid single-node bottlenecks. • Client UX matters: showing 100 live full‑res tiles will be heavy for any browser/device even if the server scales. Recommendations 1. If you need a single dashboard showing many rooms simultaneously: ◦ Forward reduced-resolution tracks (thumbnails or low bitrate) to the admin room. ◦ Use SVC/simulcast and have the admin subscribe only to low layers. ◦ Avoid server-side transcoding; forward encoded layers when possible. ◦ Start with a pilot (10–20 rooms) and measure downstream and CPU; then scale. 1. If admins only monitor a few rooms at a time: ◦ Let admins connect directly and subscribe to necessary tracks. ◦ Use on-demand subscription and unsubscribe when not viewing. 1. Hybrid approach: ◦ Forward only critical alerts or selected rooms into a central admin room for quick triage. ◦ Allow admins to connect directly to a room for full-resolution investigation when needed. Next step I can help with • Estimate downstream bandwidth and cost for your target scenario if you share expected per-track bitrate/resolution, how many admins will watch simultaneously, and session length. • Propose a concrete architecture (forwarding pipeline, SVC/simulcast settings, and sharding strategy) based on your monitoring goals. Which option best matches your monitoring needs (single dashboard with many thumbnails, a few rooms per admin, or a hybrid)? Share bitrates and number of simultaneous admin viewers and I’ll produce an estimate and concrete recommendations.

Can you access attributes or metadata from a forwarded participant ?

Thanks — I’m responding to your question about whether you can access attributes or metadata from a forwarded participant. Short answer: Yes. Attributes and metadata for a participant are available to any participant that sees that RemoteParticipant in the room, including admins who receive forwarded tracks. What that means in practice • Participant attributes (key/value strings) and the participant

metadata

string are delivered via LiveKit’s signalling and are accessible on the

RemoteParticipant

object in the client or agent SDK. • Forwarding media does not remove those fields — the receiving room/client will still see the participant’s identity and its associated

attributes

and

metadata

. • These values are NOT embedded in the media itself; they come through the participant object and signalling channel. Things to watch for • If you create a new synthetic participant when forwarding (instead of keeping the original participant identity), you’ll need to copy any attributes/metadata to that synthetic participant if you want them preserved. • If you update attributes/metadata dynamically (after forwarding starts), updates propagate via signalling and will be visible to recipients as they occur. • Access is the same in server SDKs and client SDKs: read the

attributes

and

metadata

on the

RemoteParticipant

object. If you’d like, I can: • Show a short code example in your preferred SDK (JS, Python, or Go) for reading participant attributes/metadata in the admin room. • Explain how to handle copying attributes if you use a relay/synthetic-participant forwarding pattern. Which SDK would you like an example for? Sources: Server-side | livekit/livekit_composite | DeepWiki | Handling asynchronous metadata updates in LiveKit | LiveKit | Job lifecycle | LiveKit Documentation | External data and RAG | LiveKit Documentation

So can i detect the actual real room of the participant forwarded ?

Thanks — I’m responding to your question about whether you can detect the original room of a participant whose tracks are forwarded into another room (for example, into an admin room). Short answer: LiveKit does not automatically attach the original room ID to the forwarded participant. However, you can reliably detect or record the source room by including that information in participant attributes or metadata when the participant publishes or when you perform the forward. How to make the original room detectable (options) • Set participant attributes/metadata in the source room: ◦ When a participant joins Room A, set an attribute or

metadata

like

source_room: "room-A"

or

origin_room_id: "<room-id>"

. ◦ When the admin receives the forwarded participant, the admin can read

RemoteParticipant.attributes

or

RemoteParticipant.metadata

to see the original room value. • Copy attributes when creating a synthetic/relay participant: ◦ If your forwarding creates a new synthetic participant identity in the admin room (instead of reusing the original identity), explicitly copy the source participant’s attributes/metadata into the synthetic participant at the time of forwarding. Without copying, the admin will not see the original room info. • Use server-side mapping: ◦ Maintain a server-side map that records which participant identity belongs to which source room. When the admin sees a forwarded participant identity, your server can look up the original room from that map. Important notes • Attributes/metadata travel with the participant via signalling and are accessible on the

RemoteParticipant

object in client and server SDKs. • The original room is not embedded in the media stream; it must be conveyed via attributes/metadata or a server-side record. • If attributes are updated after forwarding, updates propagate to connected participants via signalling (so admins get the new values). If you want, I can: • Provide a short code example in your preferred SDK (JS, Python, or Go) showing how to set `attributes`/`metadata` in the source room and read them in the admin room. • Show how to copy attributes when creating a synthetic participant during forwarding. Which SDK would you like an example for?