Generated video that answers back: making a live avatar interactive, not just alive

There is a version of a live avatar that is not very interesting: a character who performs on a loop, at you, forever. It looks alive. Nothing you do changes it. We shipped that first — a resting loop is what an avatar falls back to between turns — then spent the real effort on what happens after somebody asks it for something else.

Why a live avatar stream is a scheduling problem

Continuously generated video arrives in segments: render a few seconds, play them, render the next few. That length is the most consequential number in the system, and it pulls in two directions.

Long segments amortise fixed per-render latency — a submit, a queue, a warm-up. Measured on our lane at 480P, a fifteen-second segment renders in five to eight seconds and a five-second one in about three, so three short renders spend roughly twice the wall time for the same footage. They also look better: the model has room to finish a movement rather than lurching. But a long segment is also the slowest thing to get on screen — and a viewer who has just redirected the character is waiting on exactly that.

Make the segment short exactly when someone is waiting

Our stream runs fifteen-second segments while ambient — nobody has asked for anything, the character is simply present — and drops to five seconds for the first segment after a new direction. Responsiveness is bought exactly where someone is waiting for it, and the long segment is kept for everywhere else, which is most of the time.

Two mechanisms make that land. The answer segment interrupts — it cuts into whatever is playing rather than queueing behind it. We learned that the hard way: making a viewer sit out the rest of a fifteen-second clip is up to fifteen seconds of nothing happening, and it was reported to us as the direction being ignored. Superseded segments are discarded rather than played out.

What a viewer waits on, then, is not playback but the pipeline: a three-second scheduling tick plus the render. A handful of seconds, not fifteen. And note the number to be careful with — five seconds is the length of the answer segment, not its time to screen.

Per-second pricing is what permits the trick

Charge per render and the shortened segment costs the same as the long one, so the responsive path is three times the price per second of video — you would be taxed hardest for the one behaviour that makes the product feel awake. Any sane operator would pick a single segment length and live with the latency.

We run the stream on MiniMax h3-max at 480P, priced at five cents per rendered second, and bill on exactly that basis: a private stream settles a fifteen-second ambient segment at about $0.75 and a five-second answer at about $0.25. The cost is strictly linear, with no per-render term — three five-second segments and one fifteen-second segment cost the same to the credit. Segment length stops being a billing decision and becomes a scheduling one.

The model choice was the same unglamorous arithmetic: at 768P, h3-max is half plain h3’s price — eight cents a second against sixteen — for a near-identical first-frame/last-frame interface.

Two lanes, two different caps

A stream that renders whether or not anyone is watching is a bill with a character attached. Ours is watcher-gated: viewers hold a lease that expires twenty seconds after their last heartbeat, and when the last lease lapses the scheduler stops. Nobody watching, nothing rendered.

Beyond that the lanes are bounded differently, and the difference is structural. A private stream is keyed to a workspace wallet, so the wallet is the cap — an insufficient balance stops it by construction, with no second budget to drift out of agreement with the first. A shared live room is house-funded and has no wallet, so it is rationed instead: one new ambient clip every two minutes, replaying its bank in between, under a ceiling of sixty renders per room per hour. Decide which you are building before you write the scheduler.

What it does not buy

This is not real-time generation in the sense a live call is. Our conversational sessions are audio-clocked, with sub-second time to first frame; this stream schedules seconds of video ahead of the viewer. Two different clocks, and the interaction design that follows from each is not the same.

We also have not measured whether any of it holds attention longer. What we tuned was time-to-visible-response. Engagement is a real question and that experiment has not been run; we would rather ship the honest claim than the flattering one.

How to ship it

Start with the segment schedule, not the model: pick your ambient and post-redirect lengths before choosing a provider, because that tells you which pricing shapes are survivable. Make the answer segment interrupt playback rather than queue behind it. Gate rendering on presence with a short lease and a heartbeat, so an abandoned tab stops costing money without needing a disconnect event you will not reliably get.

And pin every segment’s first and last frame to the same portrait, so each begins and ends on the same image and any one splices into any other with no cut. Chaining off the previous segment’s output instead would mean decoding video you cannot decode in a worker, and would compound identity drift without bound.

The character is the easy part. The schedule is the product.