Runway can stream a digital character at 24 fps. How long does it take to answer?

When a customer finishes asking a question, an animated character has a short window in which to acknowledge it. The video may be technically smooth after playback begins, yet the gap before the first reply can still feel like a broken call. A new paper from Runway provides enough timing detail to see where that gap comes from.

Runway launched Characters on March 9, 2026. Its November 3 preprint describes the system behind a conversational avatar that generates video as it speaks. This is a technical account of an existing product. Runway's authors report results from their own system, including how the video runs on four NVIDIA H100 GPUs. The authors' numbers give teams concrete questions to ask in a pilot. Results on a different device, connection, or application would have to be measured there.

A server used to test H100 hardware, the GPU type used in Runway’s paper. Context still by 极客湾Geekerwan, resized, CC BY 3.0. Image source · License.

A 167-millisecond deadline for each batch of frames

Generate live video. Original illustration by Telli.sh.

At 24 frames per second, a batch of four frames needs to be ready about every 167 milliseconds. If batches arrive more slowly than the player consumes them, the system needs more buffering, a different quality setting, or some other change to keep motion continuous. A batch can take almost the entire 167 milliseconds even when the video plays smoothly.

Runway's authors describe a roughly 57-billion-parameter system producing 704 by 1,088 frames. They report median diffusion-step timings of 240.9 milliseconds in the reference configuration, 159.3 milliseconds in one optimized configuration and 147.4 milliseconds after further fusion. One denoised latent corresponds to four frames, and the decoder overlaps separately. The step timings have a different measurement scope from user-facing response time.

A second distinction is that video generation can run at an adequate rate after the first batch starts. The paper reports a 0.49-second video pipeline and about 2.1 seconds for the median full turn under its measurement conditions. Speech processing, dialogue generation, speech synthesis, transport, and the first useful playback event all matter in a conversation. The individual stages may overlap, so subtracting the video number from the total does not identify the cost of any single stage.

Where a moving character earns its place

One plausible pilot is a product-training station for a museum or showroom. A visitor asks what a control does, the application chooses a short answer from approved materials, and the character responds while an on-screen diagram remains visible. A walk-up visitor may benefit from a clear face, eye direction, or turn-taking cue. The system can hand off to a written explanation if the connection becomes unstable.

A second scenario is employee role-play. A trainee rehearses how to respond to a frustrated customer, then receives feedback from the training application. This is a more demanding timing problem than a scripted greeting. The character needs to pause on a partial sentence, handle interruptions, and recover from a misunderstood phrase. A useful trial records whether participants repeat themselves or talk over the character, along with the ordinary latency measurements.

Consent and representation come into play when an avatar uses a real person's image or voice. An organization can establish who may create a character, where the likeness may appear, and how removal works. For an experiment, a clearly synthetic persona or a performer with documented permission makes it easier to separate interface findings from later licensing questions.

What the production result leaves open

Measure the full turn. Original illustration by Telli.sh.

The authors report that 99.5% of sessions lasting at least one second averaged more than 23.5 frames per second. That denominator and averaging window matter. A session can pass an average frame-rate threshold while still having a visible stall. A response can also arrive promptly and then fail to stay smooth. The paper does not give every buyer the distribution of first response times at the buyer's expected concurrency.

A small pilot should include an ordinary office connection, a constrained mobile connection, and the device classes visitors actually use. Begin with a voice and transcript baseline, then test the same prompts with the character. Compare completion, abandonment, and interruption rates. Keep the scripted answers and underlying dialogue policy stable so differences can be attributed to the interface. Record slow responses along with successful examples.

A hardware configuration from the paper does not tell a buyer what a conversation costs. Useful cost units include a completed training exchange or a visitor question answered correctly. The number of generated minutes matters only once the team understands how many of those minutes were useful. A video demo can show appearance and motion. An instrumented conversation can show whether the application is ready for its audience.

Watch one conversation frame by frame

The paper reports a more specific pair of latency distributions. In 43 marked turns, the median time from the end of the user’s speech to client avatar audio was 2.13 seconds, with 10th and 90th percentiles of 1.45 and 3.00 seconds. For first agent audio to first speaking frame as captured by LiveKit, the median was 493 milliseconds, with 10th and 90th percentiles of 421 and 562 milliseconds. That first number is the pause before an audible response under the test conditions. The second concerns the start of speaking video. A visitor can perceive the timing of both.

The frame-rate measurement comes from a different data collection. The authors say they logged worker telemetry over seven weeks. They also define which sessions entered the metric. A pilot at a busy venue could supplement the paper’s result by watching for playback gaps immediately after an interruption or during a burst of concurrent visitors. Record audio and video from the actual client so the measurement includes network and playback behavior.

To measure a conversation fairly, mark the moment the person finishes speaking, the moment the agent begins to respond and the first visible speaking frame. Use repeated questions where the expected answer is known. A tester can then distinguish an accurate answer that arrived slowly from a quick answer that missed the request. Include a few interruptions whose timing is consistent across the two interfaces.

Compare cost using a finished session

Runway’s help center describes a charge of 2 credits upfront and another 2 credits per 6 seconds of active session time. At the stated price of $0.01 per credit before tax, a 60-second active session illustrates 22 credits, or $0.22, at those rates. This is an example for the published charging model. Usage totals depend on the account, active time, current price and any separately billed parts of the application.

A team comparing the interface with a voice baseline can track cost per finished exchange. Some people will abandon the session before the avatar finishes. Others will need a second conversation when they encounter a network issue or when the answer is unclear. Those sessions use resources even when a visitor did not complete the original task. Keep abandoned sessions in the denominator when measuring completion, and keep their charges in the spend.

The cost of moderation and content review can also change. A company might need to check whether generated speech follows policy, whether a synthetic presenter can appear in the intended region, and how a visitor can reach an employee when the system has no answer. Test those paths with the same care as the rendering system. A well-designed fallback can make a slow connection less disruptive for a visitor.

Run an instrumented comparison

1. Choose one approved interaction whose correct answer and successful outcome are clear.
2. Try a text or voice baseline and the avatar version using the same answer source and the same dialogue policy.
3. Repeat each prompt on the devices and connections visitors use. Include a long reply, a deliberate interruption and a brief connection drop.
4. Log response onset, speaking-video onset, playback gaps, successful interruptions and whether the visitor completes the task.
5. Review failures with the playback evidence. Decide whether the issue came from speech recognition, answer generation, timing, the network or the interface itself.
6. Compare completed sessions and total cost across both versions before expanding to longer or higher-traffic uses.

This test can show where the extra visual channel actually helps. A character can make turn-taking clearer for one audience and create an unnecessary delay for another. The result of the pilot belongs with the interaction, network and devices that produced it.

Look at the capacity change behind the timing

The authors describe the system moving from eight H100 GPUs to four for an individual real-time session. Their reported four-GPU setup without the later fusion optimization reaches 24.5 frames per second. That shows a specific hardware and software configuration meeting the target on the reported workload. It does not give a concurrency guarantee for a different workload or describe hardware allocated by a customer account.

A buyer can ask the vendor which part of the service starts first, what happens when capacity is constrained and how a session recovers. A showroom may tolerate a short visual interruption if audio continues and the question receives an answer. A synchronized training application may have to pause, show a clear recovery state and restart at a known point. Replay the same action after an interruption and see whether the application knows which part the person already heard.

The trade-off matters when someone interrupts in the middle of a sentence. A system can accumulate generated audio or video to preserve smooth playback. A buffer that is too large can make a character keep talking after the user tries to take the floor. A smaller buffer can become more sensitive to a variable connection. Time the actual stop and the next audible response separately.

Try a recovery that a user would understand

A small visitor pilot can switch a connection from a normal profile to a slower one while an answer is playing. Record whether audio stops, whether the video freezes and what the interface tells the user. Then restore normal connectivity and check whether the character resumes the same response, asks the user to repeat the question or transfers to an alternate channel. Each outcome has different consequences for a person standing in front of a kiosk.

When the system cannot recover, give the visitor a transcript, an accessible written route or a human handoff if the application can support it. A short task might still finish even if the video fails. A long exercise may need to return to a checkpoint. The right behavior depends on how much of the exchange is already complete.

A regular load test can start with three different arrival patterns. Compare one long session, several independent short sessions and a group arriving at once. Watch the first response and the slow tail in each case. A steady stream that meets the target once playback starts can still be a poor experience if a visitor waits much longer to begin during a burst.

Sources

• Runway Characters usage and credit pricing

• Runway technical preprint, November 3, 2026

• Runway Characters launch, March 9, 2026

• Official Characters demos

---

For a searchable record of the conversations and decisions behind your work, Create a Telli.sh account.