Your SFU bill is a transcode bill — the 24/7 publish nobody ordered
One multiplication tells you whether your media bill is a bandwidth problem or a transcoding problem — and it is almost always the second. Modelled at 1000 cameras against a published price list, the difference between two configurations is a six-figure monthly line, and the fix has a price nobody quotes.
On this page
- Which line on your invoice is actually wrong?
- Why is that line so much bigger than anyone expected?
- What does it look like at 1,000 cameras?
- The billing boundary nobody documents: ingress versus participant
- The wall is not the invoice — it is your own compute
- What about the viewers?
- Does recording draw from the same budget?
- Which tier should you be on?
- What this model is, and what it is not
- FAQ
- The four things worth taking away
TL;DR: If your real-time media bill grew faster than your viewership, it is probably not a bandwidth bill. Transcode minutes are charged per publish-minute, so a source that publishes around the clock is billed around the clock whether or not anybody watches. One always-on camera is 43,200 minutes a month. Modelled at 1,000 cameras on a published price list, the difference between transcoding on and transcoding off is roughly $648,000 a month — and the thing that fixes what switching it off breaks has a price of its own that no pricing page puts next to it.
Nobody notices this line while the fleet is small. It arrives as a slope: the invoice grows, viewer numbers do not, and the growth does not match anything on the product roadmap. The instinct is to go looking at bandwidth, because bandwidth is the thing everyone knows real-time video is expensive for.
It is usually the wrong line. This article is the arithmetic that tells you which line is wrong on your invoice, what it looks like when a fleet gets large, and the two costs that only become visible once you model the remedy rather than the problem.
Which line on your invoice is actually wrong?
Start here, before any architecture discussion, because the answer takes one multiplication and it decides everything downstream.
Count your publishing sources, not your viewers. Then:
sources × 60 × hours_per_day × 30 = publish-minutes per month
publish-minutes × your per-minute transcode rate = the lineIf that product is within sight of your total bill, your bill is a transcode bill, and every hour spent on bandwidth is spent in the wrong place. On LiveKit's published rates, transcode minutes on the Scale tier are $0.015 per minute of video after 8,000 included, $0.004 for audio-only, and the Ship tier is $0.02 (livekit.com/pricing, re-read 2026-08-01 — rates and inclusions move, so run the numbers against the page rather than against this paragraph).
Three symptoms that point at this line rather than another:
- The bill tracks your source count, not your traffic. Adding cameras moves it; a quiet week does not.
- It does not fall at night. Viewer-driven costs have a daily shape. This one is flat, because publishing is flat.
- Your bandwidth number looks reasonable and your total does not. That gap is the transcoder.
Why is that line so much bigger than anyone expected?
Because of one asymmetry that no pricing page states in words: transcoding is billed per publish-minute, not per view-minute.
A meeting product publishes while meetings happen — a few hours a day, on business days, and the minutes stop when people hang up. A camera fleet publishes continuously, by design, because a camera that stops publishing is a camera that missed something. The same feature at the same rate produces a rounding error for one product and the dominant line for the other, and nothing in the configuration distinguishes them.
The unit is worth memorising: an always-on source publishes 60 × 24 × 30 = 43,200 minutes a month. At $0.015 that is $648 per source per month, before a single viewer connects.
Two configuration choices routinely make the number larger than the fleet warrants, and both survive review because they look like sensible engineering:
- The publisher is created when a source is registered, not when someone first watches it. The natural place to start an ingress is where a camera is added, which begins billing at provisioning time and never stops. Creating it lazily, on first subscriber, changes the shape of the bill without changing the product.
- Nothing shuts an idle publisher down. A stream with no subscribers is pure cost. Platforms support stopping it; that support has to actually be plumbed through to whatever runs the publisher, and it frequently is not.
What does it look like at 1,000 cameras?
Modelled, not measured — the fleet below is hypothetical and the rates are public. That is the whole point: you can rerun every line of it yourself.
A thousand always-on sources publish 43,200,000 minutes a month. Three configurations, at Scale tier rates with its $500 base:
| Transcode | Connection minutes | Base | Monthly ingest total | |
|---|---|---|---|---|
| A — ingress, transcoding on | (43.2M − 8k) × $0.015 = $647,880 | $0 — ingress is exempt | $500 | ≈ $648,380 |
| B — ingress, transcoding off | $0 | $0 — ingress is exempt | $500 | ≈ $500 |
| C — participant publisher, simulcast | $0 | (43.2M − 1.5M) × $0.0004 = $16,680 | $500 | ≈ $17,180 |
Read row A against row B and the finding states itself: one boolean is worth about $647,880 a month at this scale. Not an architecture, not a migration — a flag. That is the single most useful number in this article, and it is also the most misleading one on its own, which is what the rest of this is about.
For contrast, the same fleet transcoded audio-only is 43.2M × $0.004 ≈ $172,800 a month. Still absurd, from the same asymmetry, which is a useful check that the mechanism is the schedule and not the video.
Configuration B is not free of consequences — it is the decision covered in its own article, including the two things that stop working and the audit that tells you in advance whether your sources survive it. This piece is about what the three configurations cost; that one is about what they do.
- A · ingress, transcoding on$648k/mo
- C · participant publisher$17k/mo
- B · ingress, transcoding off$500/mo
The billing boundary nobody documents: ingress versus participant
Here is the part that is invisible until you model the remedy rather than the problem.
Configuration B breaks per-subscriber adaptation, because the server can only forward the encodings the source produced — the mechanism is here. The standard fix is configuration C: publish as a real participant that emits simulcast, so the layers exist again without a vendor transcoder making them.
That fix crosses a billing boundary, and the boundary is not an implementation detail. LiveKit's knowledge base is explicit that connection minutes count "every human or agent participant connected minute … (i.e., ingress, egress, and SIP users are not charged for connection minutes)" (LiveKit KB). An ingress is exempt. A participant is not.
So moving from B to C converts 43.2M exempt publish-minutes into 43.2M billable connection minutes: ≈ $16,680 a month that the ingress path did not pay, before a single frame is transcoded. It is not a large number next to row A, and that is exactly why it goes unnoticed — it lands in an invoice three months after an architecture decision that was made on transcoding grounds alone.
The general lesson generalises past this vendor: the categories a platform bills by are a design constraint, not an accounting detail. Two ways of putting the same media into the same server can sit on opposite sides of a price list, and nothing in the SDK tells you which side you are on.
The wall is not the invoice — it is your own compute
If configuration C were only $17,180 a month, it would be an easy decision at this scale. It is not, because the cost that matters has moved off the vendor's invoice and onto hardware you now operate.
A participant publisher decodes each source once and encodes at least one smaller layer. Benched, that path costs 0.30 cores per camera — so 1,000 cameras is 300 vCPU, and with a quarter of each box held back for everything else, about 25 sixteen-core machines. That is a fleet of servers with a procurement cycle, a failure domain and an on-call rota attached, and it is a real weight against the $17,180 it was supposed to be compared with.
How much weight depends entirely on what you encode, and this is the number people most want to be smaller. One small layer per source is the cheap end of the range. Re-encode every source in full instead and the same bench says 0.79 cores — which a slower box, a better preset or a higher input framerate pushes to a full vCPU — and 1,000 cameras becomes roughly 66 machines. That is where the familiar rule of thumb, "about a vCPU per camera", actually belongs: it describes re-encoding everything, not the simulcast publisher, and quoting it for the publisher overstates that fleet by more than three times.
Both figures are ours, from one CPU and one preset on synthetic content, so the ratio between them is what transfers to your hardware and the absolutes are not — that arithmetic has its own article. Hardware encoders change the answer again, by introducing a ceiling that is not a load at all.
So the honest ranking at this scale is not "A is expensive, C is cheap". It is: A costs money you can stop spending today, B costs you two capabilities, and C costs you a rack of compute plus a line item you did not know existed. Which is right depends on numbers only you have.
What about the viewers?
Worth putting on the table, because it is the line everyone expects to dominate and it usually does not.
Egress is billed on data transferred, and it applies to all three configurations equally. Take a modest audience: 50 concurrent viewers, 8 hours a day, 30 days, at roughly 2 Mbps. That is about 0.9 GB per viewer-hour, so ≈ 10.8 TB a month; against the Scale tier's 3 TB included at $0.10/GB, that is ≈ $780 a month.
Set that beside $648,380 and the shape of the problem is clear. At an always-on fleet's scale, the viewers are the rounding error and the publishing is the bill — which is precisely backwards from how every capacity conversation starts.
Does recording draw from the same budget?
Yes, and this is the trap that turns a merely large line into an unpredictable one, because the two things that consume it are owned by different people.
On LiveKit's pricing the included allowance is shared: the transcode-minutes pool covers stream import and recording/export together — Scale's 8,000 included minutes are described as "shared with stream import", and the same per-minute rate applies once they are gone. So the storage decision and the publishing decision are drawing on one budget, and a fleet that both publishes continuously and records continuously pays the rate twice over the same wall-clock hour.
The practical consequence is a diagnostic, not a warning. If your line is bigger than the publishing multiplication predicts, the difference is usually recording, and the split is worth establishing before anyone optimises the wrong half:
publishing: sources × 60 × hours_per_day × 30
recording: recorded_sources × 60 × recorded_hours_per_day × 30
── both × the same per-minute rate ──Two questions fall out of it immediately. Are you recording sources nobody has ever played back? And is recording running through the same paid pipeline when a local or storage-side path would do? Those are frequently a bigger and easier win than anything on the live path, precisely because nobody audits them — recording is a checkbox that gets turned on once, per source, and never revisited.
Which tier should you be on?
A tier change is the one lever that costs nothing to pull, and at a certain volume it pays for itself several times over — so it is worth checking before any engineering.
The rate itself moves between tiers: $0.02 per video minute on Ship against $0.015 on Scale, with Scale's higher base (the page says starting at $500 against $50, so treat both as floors) and much larger inclusions. At the 43.2M publish-minutes the model above uses, the rate difference alone is 43.2M × $0.005 ≈ $216,000 a month — the base fee difference is noise by comparison.
The break-even is easy to compute and worth computing rather than guessing: the $450 of extra base buys itself back at 90,000 transcoded minutes a month, which is about two always-on sources. If you are on Ship with any meaningful always-on publishing, being on Ship is itself a finding.
That is the shape of most forensic work on a bill like this: the expensive mistakes are configuration and contract, not code, and they are the ones nobody re-examines because they were correct when they were made.
What this model is, and what it is not
Stated plainly, because a number in an article gets quoted long after its caveats are forgotten.
Verified: every rate above was read off the vendor's public pricing page on 2026-08-01, and the connection-minute exemption is quoted from the vendor's own knowledge base. The multiplications are arithmetic you can redo in a spreadsheet in five minutes, and you should.
Modelled, not measured: the fleet. There is no 1,000-camera deployment behind these totals — it is a hypothetical shape chosen because it makes the ratios legible. Nothing here is an invoice, and no real deployment's numbers are being reported.
Ours, measured: the cores-per-camera figures — 0.30 for the simulcast publisher, 0.79 for a full
re-encode. A synthetic 1080p25 H.264 source through ffmpeg -benchmark on an i9-14900, 2026-08-01.
One CPU, one preset, synthetic content: the ratio between the two transfers, the absolutes do not.
Not yet verified by spike, and this is the one that would move a conclusion: that the ingress-versus-participant exemption behaves on a real invoice line exactly as documented. Two vendor pages phrase it differently — the knowledge base states it as a property of the participant type ("ingress, egress, and SIP users are not charged for connection minutes"), while the ingress documentation is quoted as saying transcode-less imports are free and consume no connection minutes. Read narrowly, the second could mean a transcoding ingress is treated differently, which would change row A. The model above takes the broader reading, because it is the one stated as a billing rule rather than as a property of one mode — but we have not watched either appear on a bill. If you are about to make a six-figure decision on it, confirm it on your own account first. That is a day of work and it is the cheapest day in this article.
These are multiplications, not an invoice
FAQ
Is this specific to one vendor? The rates are. The structure is not: any platform that offers transcoding bills it per minute of media processed, and any always-on publisher therefore pays continuously. Swap in your own rate and the shape of the answer does not change — nor does the fact that the exemptions and boundaries matter as much as the rate.
Our fleet is 20 cameras, not 1,000. Does any of this apply? The unit does — $648 per always-on source per month at the same rate, so twenty is around $13,000 a month, which is worth an afternoon. The compute wall does not: twenty cameras fit on hardware you already have, so configuration C is a much easier decision at that size than the model above makes it look.
Why not just cache or record instead of publishing continuously? Because that changes the product, not the bill. If nobody needs to watch live, this whole class of cost is avoidable by not running a live pipeline. The moment "someone might open the stream right now" is a requirement, something has to be publishing — and the interesting question becomes whether it has to be transcoding while it does.
What is the single first thing to check? Whether your publishers are created on registration or on first view, and whether an idle one ever stops. Those two account for more inflated bills than any rate negotiation will recover, and both are configuration rather than architecture.
The four things worth taking away
- Count publishers, not viewers. Transcode minutes are billed per publish-minute, so an always-on source is 43,200 minutes a month regardless of audience — and that is the multiplication that tells you whether your bill is a transcode bill.
- One boolean can be worth six figures a month. At 1,000 sources the modelled gap between transcoding on and off is about $648,000 — a flag, not a rewrite. What it costs you in capability is a separate decision, with its own article.
- The fix crosses a billing boundary. An ingress pays no connection minutes and a participant does, so the standard remedy for what switching transcoding off breaks carries ≈$16,680 a month at this scale that nothing warned you about.
- The vendor's invoice is not the ceiling — your own compute is. At a benched 0.30 cores per camera, the remedy at 1,000 sources is ~25 sixteen-core machines — and ~66 if you re-encode in full rather than publishing one small layer. That range is the number an honest capacity conversation has to open with rather than end on.
Run the first multiplication today. If the answer is a meaningful fraction of your bill, you have found the line — and the next question is not "can we negotiate the rate", it is "does this have to be transcoding at all".
Putting real numbers on this for a real fleet — which configuration your sources actually survive, what the remedies cost against what they save, and where your own compute wall sits — is what our estimator starts, and what an Architecture Sprint finishes.
How we work on this — where the money actually goes on an always-on fleet, and what the audit measures — is on real-time video for streaming platforms.
