Decart's Lucy 2.6 Stops AI Video Faces and Clothes From Drifting

Decart has released Lucy 2.6 , its latest model for editing live camera feeds and prerecorded video from prompts, reference images, or both. The update focuses on keeping generated characters, clothing, accessories, and products consistent with a supplied image across consecutive frames.

Version 2.5 introduced prompt-driven editing for continuous streams. Lucy 2.6 keeps the existing real-time and batch interfaces while targeting a persistent production problem: visual details can drift as a subject moves, turns, speaks, or passes behind another object.

Reference fidelity gets the work

Decart says the model improves three areas that commonly expose live generative video systems:

• Characters: Faces, body proportions, materials, lighting, lip movements, and motion stay closer to the reference across photorealistic and animated styles.
• Clothing: Garments retain their shape, fit, texture, and placement as the wearer moves.
• Objects: Accessories and products preserve more of the reference image’s geometry, surface detail, and material.

These are qualitative claims from Decart’s release materials. The company has not published a numerical benchmark for identity consistency, garment stability, or object tracking, so teams evaluating the upgrade will need to test it against their own footage and prompts.

Endpoints stay stable

The model surfaces documented in the SDK pull request retain the resolution and frame rates associated with Lucy 2.5:

The lucy-latest alias now resolves to version 2.6, which also becomes the default real-time editing model. Version 2.5 remains available by its explicit identifier, giving existing integrations a rollback path.

Usage remains priced by the second

Decart lists the following 720p rates in its pricing documentation :

Fast mode doubles the listed real-time rate. Longer interactive sessions therefore need duration limits, usage monitoring, and clear handling for abandoned or disconnected streams.

Connecting through the SDK

The browser demo provides a quick test surface. A Python integration can select Lucy 2.6 explicitly and pass an application-provided media stream to the real-time client:

Production deployments benefit from pinning lucy-2.6 . Using lucy-latest allows a future default-model change to alter output without an application release.

Continuous generation compounds errors

Many generative video systems process a finite clip and refine the result offline. Lucy generates a continuous stream autoregressively, meaning each new frame depends on earlier output. That design supports interactive camera feeds, but errors in identity, texture, lighting, or object position can accumulate over time without a later cleanup pass.

Lucy 2.6 concentrates on reducing that accumulated drift. Its frame rates and resolution remain unchanged, and Decart has not described the release as a new architecture. Developers should treat it as a fidelity upgrade and measure end-to-end latency separately, since a 30 fps model target does not guarantee 30 fps delivery through capture, networking, inference, and playback.

Best fits and hard edges

The feature set maps most directly to applications that combine a live performer with a stable visual reference:

• Virtual try-on streams that cycle through catalog garments.
• Live commerce with generated costumes, accessories, or products.
• Viewer-directed effects applied during an active broadcast.
• Character streams that preserve a performer’s motion and expression.
• Virtual set changes that add or replace branded elements.

The main constraints remain concrete: real-time output is capped at 720p, fast mode costs twice the standard rate, and single-pass generation can struggle with rapid camera movement, occlusion, small moving objects, and scenes that require planning across many frames. Evaluation footage should include those conditions alongside ordinary front-facing demonstrations.

Ship with a rollback

Existing Lucy integrations can adopt version 2.6 by changing the model identifier while retaining 2.5 as a fallback. Before deployment, teams should compare both versions on identical prompts and references, test long sessions for cumulative drift, measure delivered frame rate and latency, verify reconnect behavior, and calculate costs at expected session lengths.