Realtime Performance

About this page

This dashboard reports the real user experience of the Lucy 2.1 realtime video model — measured end-to-end from a browser, not from server-side timers. Everything you see is what an actual client integration would observe.

How it runs

A fleet of probes runs continuously across several US Google Cloud regions. Each probe is a headless Chromium browser (driven by Playwright) running the production @decartai/sdk — the same SDK customers use. It connects to lucy-2.1 at wss://api.decart.ai over WebRTC, streams a looped synthetic camera feed, and decodes the model's returned video.

The probes execute as Google Cloud Run Jobs — one job per region, each sized at cpu=8 / 16 GiB. A central scheduler fires one region per tick on a rotation, so the load placed on production Lucy stays flat no matter how many regions are monitored. Every run opens several short back-to-back realtime sessions and aggregates them. Results are bucketed over time and plotted per region (p50 = typical, p95 = tail).

How each metric is measured

Startup Time

Time from connect() until the realtime session is ready — WebRTC signaling, SDP negotiation, and ICE connectivity.

First Frame Latency

From session-ready to the first decoded video frame produced by the model (the perceived "time to first pixels").

E2E Latency

The full round-trip a single frame takes — client → server → model inference → server → client — measured by stamping a pixel marker into each outbound frame and reading it back on the returned frame.

RTT

WebRTC network round-trip time to the media server, read from the browser's getStats().

Jitter

Variance in inbound packet arrival times (getStats()) — higher jitter means less even delivery.

Jitter Buffer

Delay the receiver's jitter buffer adds to smooth out that arrival variance before frames are decoded.