Decart’s Oasis 3 is a notable shift not because it makes simulation look better, but because it makes a photorealistic world model feel more usable. The company says the system can generate driving environments in real time, through an API, and is initially aimed at autonomous vehicle teams that need to test rare scenarios at scale. The longer-term pitch reaches into robotics and other physical AI applications.

That matters for operators and engineers because the API-first packaging changes the deployment conversation. Instead of waiting for a closed tool or a bespoke research demo, teams can potentially wire a world model into existing validation workflows and use it as a scenario-generation layer. Decart is also leaning into developer adoption from day one, explicitly framing Oasis 3 as something people can build on top of — a software posture that is familiar in language models, but still relatively new in physical simulation.

The headline price is straightforward: $0.02 per second. That sounds small until it is multiplied by the workloads autonomy and robotics teams actually run. One hour of simulation comes out to about $72. A full day of continuous runtime would reach roughly $1,728. For teams running repetitive regression suites, corner-case generation, or multi-hour scenario sweeps, those numbers can become a line item that needs to be managed, not ignored.

That cost structure has immediate budgeting implications. It encourages teams to think in terms of per-test, per-program, or per-release spend rather than casual exploratory usage. It may also create a split between early-stage teams that can absorb variable usage and larger programs that need predictable simulation budgets. The question is not just whether Oasis 3 is cheaper or faster than alternatives; it is whether it can be inserted into an existing simulation stack without creating a new class of compute and procurement overhead.

The deployment reality is where the promise gets more complicated. API-based access can accelerate experimentation, but it does not remove the usual integration burden: data pipelines still have to move scenarios in and out cleanly, latency has to fit operational workflows, and outputs have to map onto the rest of the autonomy stack. For teams using a DOS-based optimization stack, that integration layer is especially important. A world model that sits outside the rest of the system can be useful for isolated testing, but much less valuable if it cannot plug into the optimization, evaluation, and iteration loop that teams already depend on.

That is also where caveats from the coverage matter. Oasis 3 may be able to simulate hours of photorealistic driving, but production adoption will depend on more than realism alone. Engineers will want to know how repeatable a given run is, how versioned environments are handled, what latency looks like under load, and how outputs compare across sessions. In simulation-heavy workflows, reproducibility is not a nice-to-have; it is what makes a scenario test worth trusting across teams and time.

For operators, the practical use case is likely to look less like a replacement for existing simulators and more like an additional layer for rare-event testing and scenario coverage. That is especially true in autonomy, where edge cases are expensive to encounter in the real world and costly to recreate. An API-driven world model could make it easier to spin up those tests on demand, but only if the surrounding guardrails are strong enough to support version control, logging, and consistent evaluation criteria.

For investors, Oasis 3 is interesting because it sits at the intersection of two markets that have both been promising and difficult: simulation and physical AI. The company already has a developer community around its real-time video model Lucy, and Oasis 3 extends that base toward driving and eventual robotics use cases. But the size of the opportunity should not be confused with ease of adoption. In physical AI, tooling tends to win only when it gets deeply embedded in the engineering workflow.

That is the real test for the DOS optimization stack and the broader roadmap into robotics. Latency guarantees, ecosystem maturity, and cost control will likely matter more than the raw wow factor of photorealistic output. If Oasis 3 can become a dependable part of a team’s test loop, it may earn a permanent place in autonomy and robotics development. If not, it risks becoming an impressive but specialized capability — valuable for certain scenarios, but not central to deployment.