Protoface Session Warm-Up vs On-Demand Start: Which Pattern Fits Realtime Avatars?
Protoface realtime avatars: compare warm-up vs on-demand sessions for latency, cost, concurrency, and WebRTC startup behavior.
Introduction
Realtime avatars are a stateful systems problem, not just a rendering problem. Once you put a talking face in the loop, you inherit the same constraints as voice agents: session setup latency, media negotiation, network jitter, resource cleanup, and cost control. The practical question is whether you should keep an avatar session warm and ready to attach, or create it only when a user actually needs it.
This post walks through the two patterns, what changes operationally when you add WebRTC-style realtime media, and how to choose a default strategy for your app. By the end, you should be able to reason about latency, concurrency, and billing for avatar sessions instead of treating them like a black box.
What “warm-up” and “on-demand” actually mean
For realtime avatars, “session warm-up” means creating or pre-initializing the avatar runtime before a user reaches the point of interaction. In practice, that usually means reserving capacity, establishing any backend session objects, and making sure the avatar can be attached to a media pipeline quickly. The goal is to reduce perceived startup time when a call begins.
“On-demand start” means you create the avatar session only when the interaction is real: the user joins, the agent is selected, or the app transitions into a conversational state. This minimizes idle resources, but the user may pay the full startup cost at the moment they expect instant responsiveness.
For realtime avatars, the startup path often includes:
allocating a session and any associated model/runtime resources,
negotiating media transport, usually over WebRTC or a similar streaming path,
starting audio input and video output tracks,
connecting the avatar to the agent so speech, lip sync, and expression remain aligned.
That means the right pattern is usually determined by latency budget, traffic shape, and how expensive it is to hold resources open while nobody is talking.
When warm-up helps
Warm-up is useful when the user experience is extremely sensitive to first-frame latency. Common examples are inbound sales calls, concierge-style assistants, or voice agents embedded in a product flow where the user expects instant response after clicking “start.” If the avatar takes a few seconds to initialize, the experience feels broken even if the system is otherwise correct.
Warm-up also helps when your agent startup path is expensive or variable. If you need to fetch configuration, load a persona, set up tool state, or coordinate across services, pre-creating the avatar session can smooth out tail latency. In systems terms, you are trading idle spend for lower p95 and p99 startup time.
The downside is straightforward: every warm session consumes capacity. If your demand is bursty or unpredictable, pre-warming too many sessions can become the most expensive part of the stack. You also need a policy for session expiration, because any warmed-up resource that sits unused long enough becomes waste.
When on-demand is the better default
On-demand start is usually the right baseline for most developer integrations. If the avatar is triggered by explicit user action, or if your app can tolerate a short setup delay, on-demand keeps the system simpler and cheaper. You only pay when there is an actual interaction.
It is especially attractive when:
traffic is sporadic or long-tail,
you have many avatars but only a few active at once,
sessions are short and you care more about utilization than startup latency,
the avatar is not the primary UI element, so a brief “connecting” state is acceptable.
The trade-off is user-perceived delay. Even if session creation is fast, the combination of auth, orchestration, media negotiation, and first audio/video frames can add up. If your product promise is “instant conversation,” on-demand can feel slow unless you hide the setup behind a loading transition or preflight step.
A practical decision model
Use this rule of thumb:
Start on-demand unless startup latency is directly hurting conversion or session quality.
Add warm-up when you can predict demand well enough to keep utilization high.
Warm only the expensive part of the path if possible. Pre-create the session or reserve capacity, but defer any user-specific attachment until the interaction is confirmed.
That last point matters. In realtime systems, “warm” does not have to mean “fully active and billing.” Sometimes the better design is to keep an avatar session ready to attach while leaving the actual media connection and agent turn-taking until the user is present. That reduces the startup path without turning every warm session into a live call.
Two other constraints are worth checking early:
Concurrency ceiling. If you can only run a limited number of active avatars, warm-up must be bounded and schedulable.
Failure recovery. If a warmed session goes stale, your app needs to detect it and fall back to a fresh on-demand start.
Implementation patterns that matter in practice
For voice-agent integrations, the avatar is typically one more stream in an already stateful pipeline. If your agent is running inside a voice stack, the avatar should be attached late enough that the audio path is stable, but early enough that the user sees a synchronized face as soon as speech begins. That is why the integration point matters more than the avatar itself.
With a LiveKit-based agent, for example, the avatar plugin drops the video face into the agent pipeline so the agent’s speech is mirrored visually. The key design choice is still session timing: do you attach the avatar before the room is live, or only when the user is connected?
That small piece of code hides an important architectural point: the avatar object is not the same as the user session. You can often instantiate the configuration earlier than the live media path, but you should only fully activate the realtime session when you know the call is real.
Warm-up with the REST API: create early, attach late
If your backend owns orchestration, the cleanest pattern is usually to create the avatar session before the user actually joins, then attach it when the interaction begins. That gives you the latency benefit of warm-up without exposing unnecessary state to the client.
Use the exact request shape from the docs, but the design principle is the same: session creation is a backend concern, and the browser or client should only receive the minimum needed to join the media flow. That keeps credentials off the edge and lets you enforce your own warm-up policy centrally.
If you are building a web app, this is usually the point where you decide whether to surface a “preparing your avatar” state. For high-value interactions, that state is often better than letting the user stare at a blank panel while the session spins up. For casual or exploratory use, on-demand startup plus a small spinner is probably enough.
How to think about billing and resource hygiene
Because usage is billed by quality tier, warm-up decisions should always be measured against cost. A warmed session that never gets used is pure overhead. A session that reduces abandonment or improves answer completion can justify the spend, but only if you can see the effect in metrics.
Track at least four numbers:
time to first frame for video avatar startup,
time to first audio for the conversational path,
session attach rate for warmed sessions,
idle expiry rate for sessions that were created but never used.
If you cannot measure those, you are optimizing in the dark. In most teams, the first pass should be simple: start on-demand, instrument the latency, and only introduce warm-up once you have evidence that the startup path is the bottleneck.
Where Protoface fits
Protoface supports both patterns, but the useful distinction is where you want to own the orchestration. If your app already has a backend that coordinates calls, the REST API and Python SDK are the right place to implement warm-up and attach-late behavior. If you are integrating a voice agent stack, the LiveKit plugin lets you keep the avatar close to the media pipeline rather than bolting it on as a separate service. The public docs at docs.protoface.com are the place to check exact request fields, session lifecycles, and current best practices.
For developers working from Python, the SDK is a good fit when you want to wrap startup policy in application code instead of scattering it across jobs and handlers. For developers wiring an existing agent, the plugin approach usually reduces integration risk because the avatar lifecycle stays aligned with the voice agent lifecycle.
Conclusion
Warm-up and on-demand are not competing features; they are two points on the same latency-versus-utilization curve. Start on-demand when you want simplicity and cost efficiency. Add warm-up when startup latency is visibly hurting the experience, and keep the warmed portion of the system as small and measurable as you can.
If you are implementing this today, start with the docs, instrument startup latency, and choose the smallest pattern that meets your UX target. The examples and quickstarts in the Protoface docs and GitHub org are the fastest way to validate the integration path for your stack.