Estimating Server and Bandwidth Costs for Realtime Talking Avatars in a TypeScript Stack
Estimate realtime talking avatar costs in TypeScript: session minutes, concurrency, bandwidth, quality tiers, and server orchestration.
Introduction
When you add a realtime talking avatar to a product, the hard part is usually not “can it work?” but “what will it cost at production scale?” With a voice agent, every session has at least two resource dimensions: compute on the server side and bytes on the wire. The video face itself is typically a low-latency streaming workload, so your bill is driven by session count, concurrency, video quality tier, and how long users stay connected.
This matters more in a TypeScript stack than it first appears. In practice, your frontend may be simple WebRTC or iframe plumbing, but your backend still has to manage sessions, auth, rate limits, and observability. By the end of this post, you should be able to estimate per-session and monthly cost envelopes, identify the main cost drivers, and choose an integration shape that matches your budget instead of fighting it later.
Start with the cost model, not the implementation
For realtime avatars, separate cost into four buckets:
Session runtime: how many minutes each avatar session stays active.
Concurrency: how many sessions run at the same time, which affects server capacity and any burst headroom.
Bandwidth: primarily outbound video/audio to clients, plus any signaling overhead.
Quality tier: higher visual quality generally means more bytes, more GPU/CPU work, or both.
For rough planning, use a simple formula:
That formula is intentionally boring, because “boring” is what you want in budgeting. The details that matter are in the multipliers. If your product has short, frequent interactions, signaling and setup overhead matter less than average session length. If your product has long-lived agents, concurrency and steady-state bandwidth dominate.
For a voice agent with a synced face, the avatar stream is usually the larger bandwidth consumer than text or signaling, but the exact footprint depends on frame rate, resolution, codec, and how aggressively the service adapts to network conditions. Don’t assume “video” means “huge”; a well-tuned realtime stream can be much cheaper than a naïve screen share, but it is still materially more expensive than text.
Estimate bandwidth from real session shape
The fastest way to get a credible estimate is to model the user experience you are actually shipping. Ask these questions:
How many active sessions do you expect per day?
What is the average session length?
What percentage of sessions reach video, versus being abandoned early?
Do users spend most of the session talking, waiting, or idle?
Is the avatar visible continuously, or only during agent responses?
Suppose you expect 50,000 monthly sessions, with an average duration of 3 minutes. That is 150,000 session-minutes per month. If the avatar stream averages 0.6 Mbps outbound during active playback, the rough bandwidth math is:
At 50,000 sessions, that is about 675 GB of outbound traffic per month before you account for signaling and retries. If your stream averages half that bitrate, the bandwidth line item halves too. If your session duration doubles, bandwidth roughly doubles.
The important part is not the exact number from this example; it is the relationship. Bandwidth scales linearly with time and quality, so if your usage distribution is skewed toward a small number of long conversations, your tail sessions can dominate the bill.
Server cost is mostly about concurrency and orchestration
Realtime avatars add server-side responsibilities beyond “run an API.” You need to manage session creation, authentication, lifecycle cleanup, rate limiting, and often some amount of media orchestration. In a TypeScript app, that usually means a backend service that talks to the avatar provider, your auth system, and your voice stack.
For planning, treat server cost as two separate things:
Control plane cost: API requests, session metadata, auth checks, and dashboard-grade operations.
Media plane cost: the realtime workload that moves audio/video frames and reacts to network conditions.
Control-plane traffic is cheap and easy to scale. Media-plane traffic is where you pay for latency and concurrency. If you host any part of the media path yourself, you need enough headroom to handle peak simultaneous sessions, not just daily averages. A service that is cheap at 10 concurrent sessions can become expensive fast at 500 concurrent sessions, especially if each session needs a long-lived worker or relay process.
One subtle but common mistake is to budget based on requests per second instead of active session minutes. For conversational avatars, active sessions are the real unit of work. A single user can keep a session hot for many minutes while generating very few API calls. That means CPU, memory, and network reservations should be sized around concurrency and session duration, not endpoint throughput alone.
How to make the estimate less hand-wavy
Use a staged approach:
Measure one representative session. Capture average duration, reconnect rate, and bytes sent during a typical conversation.
Segment by quality tier. If you offer multiple avatar qualities, treat them as separate products. Higher tier should have its own cost curve.
Add a failure factor. Retries, renegotiation, and short reconnects add real traffic.
Model the peak. Average usage is useful for finance; peak concurrency is useful for operations.
If you are already shipping a TypeScript app, instrument the backend that creates sessions. You do not need deep media telemetry to get started. Log session start/end, selected quality tier, and approximate duration. If your provider exposes usage details, ingest those into your analytics pipeline. The goal is to observe actual cost drivers instead of guessing from product intuition.
Another useful rule: if you cannot explain your avatar cost in terms of “minutes at tier X” and “GB out,” you probably have too many hidden abstractions. Simplify your system until those numbers are obvious.
Integrating from TypeScript without leaking secrets
There are two common integration patterns in a TypeScript stack. The first is a backend service that creates and manages sessions. The second is a customer-managed embed that moves most of the session plumbing out of your app entirely.
For a backend-managed flow, your server can create sessions via the REST API using an API key stored only on the server. The shape of the request depends on the exact resource fields in the docs, but the basic pattern is standard: send an authenticated POST, return the session payload to your frontend, and connect the client to the returned session.
In a Node backend, keep the secret on the server and expose only the ephemeral session data your client needs. That keeps your browser code simple and avoids the common anti-pattern of shipping long-lived credentials into the frontend.
If you are using a voice-agent framework, the LiveKit plugin path is often the cleanest fit. The plugin drops a synced talking face into your existing agent flow, which means your backend still owns the voice logic while the avatar layer stays aligned with the agent turn-taking. That is operationally nice because you are not building a separate media pipeline just to get a face on the agent.
If you want a managed integration guide for a voice-agent stack, the Pipecat adapter docs are also worth a look: Pipecat Protoface integration. For people wiring this into a Python service directly, the Python SDK repo is a useful reference: protoface-sdk-python.
Where Protoface changes the economics
This is where Protoface is useful in practice: it gives you a developer-facing avatar API and a few integration surfaces so you can choose the cost envelope you want. If you need a server-controlled flow, use the REST API and keep billing-sensitive logic on your backend. If you are already running LiveKit agents, the plugin approach keeps the avatar attached to the voice agent instead of adding another custom media service. If you want to avoid backend work entirely, the customer-managed iframe embed shifts the complexity into a controlled browser integration with origin allowlisting, per-embed instructions, and rate limits.
From a cost perspective, the main value is that the quality tier is explicit and session-oriented. That makes budgeting easier because you can map product tiers to infrastructure tiers. A low-friction playground and dashboard are also helpful because they let you test session behavior before committing to production traffic patterns. For implementation details and the current request/response shapes, use the docs at docs.protoface.com.
Conclusion
To estimate server and bandwidth costs for realtime talking avatars, think in session minutes, concurrency, outbound bytes, and quality tier. Measure one representative conversation, extrapolate from actual duration and bitrate, and then add a safety margin for retries and peak load. Avoid planning around generic request volume; avatar workloads are media workloads, and media workloads bill by time and throughput.
If you are integrating in TypeScript, keep API keys server-side, model sessions explicitly, and choose the integration surface that matches your operational budget. For most teams, the next step is to prototype one real session path, capture the numbers, and compare them against your expected usage curve. The docs at docs.protoface.com are the right place to start, and the quickstarts linked from the repository README can help you validate assumptions quickly.