Decart brings live video models and compute optimization into applications

Decart combines Lucy video editing, Oasis world simulation and compute optimization. Understand API costs, preview limits and a proposed live-video workflow.

01 / ProductThree connected offers with different buying routes

Decart develops visual models and the infrastructure used to run demanding AI workloads. Its current company site separates Lucy, for world editing, from Oasis, for world generation, and the Decart Optimization Stack, or DOS. That distinction matters: editing a camera stream, simulating a changing environment and optimizing an existing model are different engineering jobs. A team should identify which output it actually needs before treating the company as one interchangeable video service.

The API overview describes live video transformations, video jobs and image editing. Lucy can take prompts and reference images to change an incoming scene. This makes it relevant to an interactive application that already has a video source, where each new frame should reflect a chosen transformation. It is less like ordering one finished film and more like adding a generated visual layer to a continuing session.

Oasis 3 Preview has a separate developer path: a hosted world model receives driving actions and returns generated camera frames through a Python client and a stateful connection. Its public documentation is concrete enough for experimentation, but the Preview name is consequential. A plausible synthetic street is not, by itself, evidence of a physically reliable simulator for a particular safety evaluation.

DOS targets inference, training and hardware efficiency through customer-defined optimization, kernel and compiler work, and profiler or simulator licensing. Its commercial route is a scoped pilot or partnership. The practical attraction is a conversation about an identified workload and existing hardware, rather than assuming that the public Lucy API price also buys infrastructure optimization services.

02 / AudienceLive interaction is the strongest reason to evaluate Lucy

A creator platform, interactive installation or entertainment application may need the user to see a changed scene while moving and adjusting it. For those jobs, startup time, interruptions and visual continuity become product features. A team that merely needs a rendered clip for tomorrow’s campaign may be better served by evaluating an editing workspace first. The important difference is when the output must arrive, and how strongly it depends on the user’s ongoing actions.

Runway provides a useful comparison for an editorial production workflow built around creating and revising clips. fal is an adjacent comparison when the application needs a wider media-model catalog and an inference integration. Neither comparison establishes a universal winner: a live camera experience, a creative editor and a multi-model backend place different demands on the same budget.

Decart’s infrastructure offer also deserves its own evaluator. A performance team should bring representative traffic, model sizes, quality constraints and hardware configurations. A creative producer choosing prompts cannot validate compiler gains, just as a throughput benchmark cannot establish that a character transformation looks acceptable. Separate those decisions so enthusiasm for one demonstration does not become evidence for the other purchase.

03 / WorkflowA proposed camera effect tests the whole session

Consider a proposed trial for a small, consent-based interactive booth that transforms a participant’s camera view into an illustrated character. Use authorized reference artwork and volunteers, with a clear way to stop the camera. Define the acceptance criteria before experimenting: the person stays recognizable enough for the intended effect, motion remains usable, and the application makes connection failures visible. This is a proposed evaluation, not a reported deployment.

Start with one transformation and a fixed model choice. Request camera dimensions and frame rate from the model’s own configuration, as Decart’s streaming guide recommends. Compare normal movement, hands crossing the face, changing light and a participant leaving the frame. Record which conditions break the effect instead of selecting only the most flattering few seconds for review.

The client-token guide documents short-lived credentials created by the application’s backend for browser and mobile connections. Keep the permanent API key there, issue a token when connecting, and scope its models and origins appropriately. Token expiration controls starting connections; it does not end an already active session. A separate maximum-session-duration constraint is therefore relevant to the booth’s usage budget.

Keep prompt changes inside the established session where supported. The streaming documentation distinguishes updating a prompt from reconnecting to change a model, camera or speed tier. For this trial, show participants a small set of deliberate effects, and make a visual distinction between a running effect and a reconnecting stream. That avoids interpreting a frozen preview as successful live generation.

Test the exit path as carefully as the first frame. Stop the camera tracks, close the connection and confirm that the interface returns to an idle state. Repeat after denied camera permission, a network interruption and a user abandoning the page. Measure session startup, usable output duration and failed attempts separately. These measurements reveal whether the feature works as an interaction, beyond whether the model can produce an attractive frame.

04 / PricingMetered generation requires a session budget

The pricing page describes pay-as-you-go access without subscriptions or a minimum spend, and initial credits for new accounts. An illustrative one-minute standard Lucy session is 60 × USD 0.02, or USD 1.20, before any other application costs. At the published fast rate the same generation duration is USD 2.40. Those calculations describe usage arithmetic, not an estimate of how many successful customer sessions a credit balance will produce.

Budget for retries, abandoned sessions and experiments as well as accepted output. If the product earns revenue per completed interaction, dividing model spend by all connections will flatter the economics when many connections fail early. Track completed experiences and the total generation seconds required to produce them. Keep optimization engagements, support commitments and deployment requirements in a separate commercial discussion from the self-service API balance.

05 / DistinctionsA live model changes the application design

The meaningful distinction is continuous control. A prompt can alter an ongoing visual experience, so the interface needs states for connecting, generating, reconnecting and stopping. That is a different design problem from showing a job in a render queue. Decart’s documentation exposes enough of these lifecycle decisions to make a focused prototype reviewable, rather than leaving all operational behavior behind a promotional video.

The combined infrastructure and model story also creates an interesting evaluation opportunity. A company building a latency-sensitive experience can discuss both the visible model behavior and the compute constraints around it. That is an opportunity to ask sharper questions, not proof that any deployment will be cheaper. Compare complete workloads under matching quality and concurrency requirements before accepting broad efficiency claims.

06 / QuestionsSeparate convincing imagery from operational proof

The first open question is quality under the intended input distribution. Reference-driven edits can look persuasive in a staged example while failing with occlusion, unusual lighting or rapid movement. Preserve failed sessions and ask reviewers to score the specific property the application promises. For a costume effect that might be visual consistency; for a product preview it might be whether shape and branding remain faithful. These require different acceptance rules.

The second question is how an application should depend on Preview simulation. An Oasis experiment can explore action-conditioned visual behavior, but a real-world evaluation must establish what the generated environment preserves and what it invents. Decide whether the output is for brainstorming, data experimentation or a validated test process. Do not silently move evidence from the first category into the last.

Finally, confirm account limits, production support and expected model-version changes before launch. A working sample does not establish concurrency capacity for a busy event or an agreed recovery time during an outage. Pin the evaluated model where supported, retain the inputs and configuration needed to reproduce checks, and reserve room to rerun them when the service changes.

07 / DecisionChoose the specific visual or compute problem

Decart is worth evaluating when live visual response is central to the product or when a performance team has a concrete AI workload to optimize. The productive first step is a bounded session or workload with a measurable definition of success, followed by a commercial discussion that matches that exact route.