Lucy 2.5 Realtime Video: latenza, costi e configurazione API

$0,02 al secondo sembra una tariffa contenuta. Ma per uno stream di quattro ore il conto arriva a $288. Lucy 2.5 di Decart è una delle API oggi disponibili per trasformare video live con l'AI, ma i 1080p del materiale di lancio non coincidono con la risoluzione indicata nella documentazione API; inoltre, la latenza da titolo riguarda il modello, non l'intero percorso dalla videocamera allo schermo. Vediamo cosa è marketing, cosa è documentato, quanto costa davvero su base oraria e come si accede al servizio.

Cos'è davvero Lucy 2.5 realtime video

Lucy 2.5 è il modello di video-to-video editing in tempo reale di Decart, presentato il 16 luglio 2026 con "Raising the Bar for Live AI". Il video arriva tramite connessione WebRTC, mentre prompt testuali e immagini di riferimento opzionali guidano la trasformazione; i frame elaborati vengono restituiti a 30 fps dichiarati. Il punto centrale è proprio la trasformazione: Lucy interviene su un flusso live già esistente, cambiando stile, sostituendo, aggiungendo o rimuovendo elementi, anziché generare clip finite dal nulla. Tim Simmons di Theoretically Media chiarisce bene la differenza: parliamo di effetti live e compositing applicati a uno stream, non di montaggio non lineare. Per ora è disponibile solo via API: "There's no app version yet," e il prodotto tenuto in mano nel video di lancio Decart "is not an available product."

La documentazione API supporta input sia live sia registrati; la pagina del modello su fal indica inoltre che l'uso commerciale è consentito secondo i relativi termini. Decart ha raccolto oltre $450M, incluso un round da $300M guidato da Radical Ventures nel maggio 2026.

I 1080p non sono la specifica API da usare

Il materiale di lancio e la pagina del modello fal promuovono Lucy 2.5 a 30 fps e 1080p. La documentazione API di Decart, invece, indica un output di 1280 × 720, nei formati orizzontale 16:9 o verticale 9:16. Finché non verrà documentato pubblicamente un endpoint a 1080p, conviene pianificare sul 720p: è quanto prevede il contratto API ed è anche la risoluzione su cui si basano gli esempi di prezzo.

La stessa cautela vale per il frame rate. Il riferimento a "30 FPS" compare nel marketing senza una metodologia di misurazione pubblicata; Decart non ha divulgato né l'hardware di serving, né la dimensione del modello, né un test dalla cattura alla riproduzione. Un riferimento esterno utile è SANA-Streaming, preprint di ricerca del maggio 2026: riporta 24 fps end-to-end a 1280 × 704 su una singola RTX 5090, mentre il suo core diffusion-transformer raggiunge 58 fps. Non è un benchmark di Lucy, ma mostra perché un semplice "30 FPS", senza un punto di misurazione definito, dica poco da solo.

Latenza: cosa include il «near-zero» e cosa resta fuori

Per Lucy 2.5 circolano tre valori di latenza, ma non misurano la stessa cosa. Il post di Decart sull'infrastruttura DOS 2.0, pubblicato insieme al round da $300M, parla di una risposta del modello inferiore a 30 ms; l'approfondimento della community su Hugging Face attribuisce allo stack di inferenza Decart un'inferenza sotto i 40 ms a 720p (quantizzazione MXFP8/NVFP4, dynamic sparse attention, deep kernel fusion e un'accelerazione dichiarata di 4× limitata alle operazioni compute-bound). Nessuna delle fonti pubblica però il ritardo end-to-end, dalla cattura della videocamera ai pixel sullo schermo dello spettatore. A questo percorso si aggiungono trasporto WebRTC, codifica e player, con risultati variabili in base alla rete. Per stimarlo nel proprio deployment, basta registrare un timestamp visibile nel feed della camera e confrontarlo con l'output visualizzato sulla rete e nel player target.

Controllo dell'editing: otto modalità e i limiti di Self-Anchoring

La superficie di editing documentata per Lucy 2.5 comprende otto operazioni, tutte controllabili con prompt testuali, immagini di riferimento o entrambi:

Due aspetti contano più dell'elenco delle modalità. Il primo è Self-Anchoring: il meccanismo rimanda al modello il suo output recente come riferimento, così da evitare derive dell'identità negli stream lunghi. È attivo per impostazione predefinita e può essere modificato solo al momento della connessione. La documentazione Decart avverte di disabilitarlo in caso di taglio netto della camera, ingresso di una nuova persona nell'inquadratura o cambiamento sostanziale della scena: in questi casi, l'ancora fa riferimento a un mondo che non esiste più. Serve quindi una riconnessione, un fattore da prevedere nelle configurazioni multicamera.

Il secondo riguarda le immagini di riferimento, per le quali esistono requisiti precisi: devono essere nitide, ben illuminate, senza ostacoli, avere almeno 512 × 512 pixel e un'inquadratura coerente con il video sorgente. Un riferimento scuro o non allineato alla ripresa può far fallire del tutto la sostituzione.

Realtime o generazione offline: quale strada scegliere

I generatori offline, come Runway, Pika e gli strumenti della classe Sora, risolvono problemi diversi da Lucy 2.5. Alla domanda su quale sia migliore non esiste una risposta universale: dipende dal flusso di lavoro. A decidere sono soprattutto quattro fattori:

1. Interazione. Se pubblico o videocamera devono influire sul video mentre sta accadendo, il realtime è l'unica strada; gli strumenti offline seguono un ciclo prompt, attesa e rendering.
2. Durata. Gli strumenti offline lavorano in genere su clip da 5–60 secondi, con tempi di rendering da secondi a minuti per prodotti della classe Runway e Pika, secondo il confronto di Hugging Face. Lucy trasmette invece in modo continuo; fal dichiara esecuzioni di più ore senza collasso dell'identità, anche se non è stato pubblicato uno stress test su sessioni lunghe.
3. Soglia qualitativa. Per consegne finali a 1080p o superiori, oggi il rendering offline resta preferibile, visto l'output API documentato a 720p. Un workflow ibrido pratico, proposto da Tim Simmons, è il previs live: si riprende con uno smartphone, si applica il trattamento in diretta con Lucy per valutare l'inquadratura, quindi si esegue il passaggio finale con un modello video-to-video offline di qualità superiore.
4. Struttura dei costi. Gli strumenti offline fatturano per clip generata; Lucy per ogni secondo di stream attivo, con un effetto cumulativo su base oraria, come vedremo nella prossima sezione.

Cosa attira davvero l'attenzione degli utenti? Su r/generativeAI, u/TastyFooting ha riassunto il fascino principale in modo diretto:

"Generazione video-to-video in tempo reale con prompt testuale. Niente più tempi di rendering." (fonte)

Nelle discussioni della community emergono due interrogativi aperti: il "Is there any use for this kind of model? VTubing?" di u/ai_art_is_art e il dubbio di un creator su r/AINewsAndTrends, ovvero "if it works as well outside of demos." La direzione documentata arriva dalla pagina del modello fal: live shopping e virtual try-on, product placement in tempo reale, stream interattivi, trasformazione delle scene nelle app, gaming e virtual staging durante walkthrough live. L'approfondimento di Hugging Face aggiunge flussi di lavoro per VTubing e variazioni pubblicitarie. Per uno sguardo più ampio su come la generazione realtime stia cambiando il panorama delle video API, leggi la nostra copertura di SeedRealtime.

Il costo reale di uno stream: $0,02/sec non è il dato decisivo

Le due opzioni pubblicate hanno prezzi diversi:

Gli esempi di prezzo Decart fissano il riferimento per le sessioni brevi: 30 secondi in realtime costano $0,60, mentre un editing offline di 5 secondi a 720p costa $0,20. Entrambe le piattaforme fatturano i secondi di generazione attiva, non il tempo di visualizzazione, secondo le rispettive pagine prezzi. Il calcolo che incide sulle decisioni è però quello all'altro estremo:

Con quattro ore attive per ogni giorno lavorativo, fal fattura circa $576 al giorno, ovvero approssimativamente $12.700 in un mese di 22 giorni lavorativi, prima dei costi di networking e moderazione. La generazione continua trasforma un prezzo unitario basso in un problema di concorrenza oraria: in un'app in cui ogni utente apre uno stream Lucy indipendente, il costo orario si moltiplica per il numero di stream simultanei. Se stai confrontando questa soluzione con altre API di generazione, le differenze tra fatturazione al secondo, per clip e per token sono trattate nella nostra guida ai prezzi e alle dimensioni di fatturazione delle video generation API.

Due mitigazioni sono strutturali. I momenti in cui la videocamera è inattiva non devono necessariamente diventare secondi di generazione attiva: conviene abilitare lo stream solo quando c'è contenuto effettivo. E la scelta del canale dimezza il conto: a parità di output documentato a 720p, l'API diretta Decart costa la metà di fal, mentre fal include playground, termini commerciali ed ecosistema. La scelta dipende da ciò che serve attorno al modello, non dal modello in sé.

Come accedere: API Decart, playground e fal

Il modo più rapido per vedere come Lucy 2.5 reagisce al proprio volto è l'esperienza browser di Decart su lucy.decart.ai o il playground demo su demos.decart.ai. I nuovi account ricevono crediti di test, che potrebbero bastare per una prima sessione. È il posto giusto per provare immagini di riferimento e formulazioni dei prompt prima di scrivere codice.

Secondo la documentazione realtime di Lucy 2.5, il percorso con API diretta Decart segue il normale flusso WebRTC:

1. Ottieni le credenziali API e crea una sessione realtime per il modello lucy-2.5
2. Stabilisci la connessione WebRTC, configurando Self-Anchoring e prompt enhancement al momento della connessione; per modificare Self-Anchoring in seguito serve una riconnessione
3. Collega alla sessione il media di input live o registrato
4. Invia prompt testuali e immagini di riferimento sulla connessione attiva; i riferimenti possono essere aggiornati durante la sessione
5. Consuma la traccia di output elaborata e affidati all'auto-reconnect integrato, con backoff esponenziale fino a 5 tentativi, in caso di sessione interrotta

Per integrare Lucy tramite fal, il percorso è in cinque passaggi:

1. npm install --save @fal-ai/client
2. Crea un account fal e ottieni una API key dalla dashboard
3. Apri una connessione WebRTC a decart/lucy-2-5/realtime
4. Distribuisci JWT di breve durata dal backend tramite un tokenProvider; l'esempio fal usa una scadenza del token di 10 secondi. Non è quindi una configurazione solo browser con chiave esposta nel frontend
5. Gestisci risultati ed errori tramite onResult/onError, quindi invia i prompt sulla connessione live

La pagina del modello fal indica JavaScript, Python e REST puro come percorsi client supportati. Per OBS, va separato il prototipo dalla produzione: acquisire la finestra o usare una browser source dell'esperienza Decart va bene per testare un look, ma una pipeline di produzione dovrebbe acquisire l'output WebRTC della propria integrazione API. L'approfondimento di Hugging Face segnala l'uso di OBS via WebRTC senza modificare la configurazione broadcast esistente; è comunque opportuno validare ingest, latenza e comportamento di riconnessione nel proprio stack. Lo stesso approfondimento riporta SDK Android e iOS per app mobili. Lucy 2.1 resta disponibile su fal se vuoi confrontare il comportamento tra versioni. Per una valutazione più ampia di fal come piattaforma, consulta la nostra recensione di fal.ai.

Prima di andare live: gli obblighi di disclosure esistono già

Un modello capace di modificare in diretta persone, abiti e ambienti rende la compliance un requisito ingegneristico, non una nota marginale di policy. La acceptable-use policy di Decart, aggiornata il 12 febbraio 2026, vieta di impersonare una persona reale senza disclosure chiara e ben visibile e senza consenso verificabile. Richiede inoltre a chi distribuisce il servizio di segnalare contenuti generati o manipolati dall'AI, applicare una moderazione adeguata e conservare marcatori machine-readable quando tecnicamente possibile. Separatamente, gli obblighi UE di trasparenza, in vigore dal 2 agosto 2026, richiedono marcatura machine-readable per contenuti AI rilevabili e disclosure del deployer per utilizzi assimilabili ai deepfake. Per deployment rivolti all'UE, gli obblighi applicabili su trasparenza e provenienza vanno verificati prima del lancio, non dopo.

Conviene sviluppare su Lucy 2.5 oggi?

Il compromesso da tenere d'occhio è semplice: se Decart lancerà una route pubblica a 1080p, il divario qualitativo tra offline e realtime si ridurrà in modo significativo. Fino ad allora, considera il 720p come il contratto e il numero superiore come un'intenzione.

FAQ su Lucy 2.5 realtime video

Lucy 2.5 è davvero in tempo reale?

È realtime nel senso che applica modifiche a uno stream WebRTC live a 30 fps dichiarati, con una latenza lato modello indicata sotto 30–40 ms. Non è stata pubblicata una misurazione indipendente end-to-end, dalla cattura alla riproduzione: per ora, quindi, «in tempo reale» significa verificato nelle demo, non convalidato da benchmark.

Quale risoluzione produce l'API di Lucy 2.5?

L'API documenta output a 1280 × 720 nei formati 16:9 o 9:16. Il materiale di lancio promuove i 1080p, ma alla fine di agosto 2026 non risulta documentato alcun endpoint pubblico a 1080p.

Quanto costa Lucy 2.5 all'ora?

L'API diretta Decart fattura $0,02 per secondo attivo a 720p: $72 per ora attiva. Su fal, lo stesso modello costa $0,04 al secondo, ovvero $144 per ora attiva. Entrambe conteggiano il tempo di generazione attiva, non il tempo di visualizzazione.

Lucy 2.5 funziona con OBS?

Sì, per la prototipazione: l'esperienza browser può essere usata in OBS tramite browser source o acquisizione finestra. In produzione, testa un flusso di ingest WebRTC nel tuo stack broadcast prima di impegnarti.

Lucy 2.5 o Lucy 2.1?

Secondo il confronto tra versioni di fal, Lucy 2.5 amplia le possibilità di editing, includendo oggetti, abiti, personaggi, attributi, sfondi, stile e VFX, e dichiara migliore aderenza ai prompt, isolamento delle modifiche e fedeltà ai riferimenti. Lucy 2.1 resta disponibile su fal come endpoint realtime precedente se ti serve una base dal comportamento già noto: prova entrambi sui tuoi filmati.