lucy realtime status
Live end-to-end performance of the Lucy 2.1 realtime endpoint, measured from a fleet of real browser clients across Google Cloud regions. Each chart shows one metric over time, per region - p50 solid, p95 dashed, and p99 dotted where available. Click regions in the legend to pick which to show (choose several to compare); double-click to reset to all.
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 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/p99 = tail).
How each metric is measured
- Setup Time
- Setup time:
connect()invocation until the connection resolves. - TTFF
- Time to first frame:
connect()invocation until the first non-black model-generated frame is decoded — setup included. Definition changed in probe 0.12.0: earlier points measured the warm prompt-to-frame window (setup excluded), so the series steps up at the cutover. - E2E latency
- The returned generated-frame round trip measured from LiveKit frame metadata, including the first generated frame when metadata is available.
- Set Prompt Time
- Warm-start
setPrompt()call start until the prompt ack is received. - Server Latency
- Server-side wire-to-wire window from media transport receive to paced emit, when server metrics are available.
- RTT
- WebRTC network round-trip time to the media server, read from the browser's
getStats(). - Jitter Buffer
- Delay the receiver's jitter buffer adds to smooth out that arrival variance before frames are decoded.
- Jitter
- Variance in inbound packet arrival times (
getStats()) - higher jitter means less even delivery.