Decart’s Oasis 3 turns synthetic driving into an API product — but the hard parts are still ahead

Decart is trying to do for driving worlds what cloud APIs did for software: turn something expensive, bespoke, and hard to operationalize into a programmable service.

With Oasis 3, the company is exposing a real-time, photorealistic driving world model through an API and charging $0.02 per second for usage. The initial pitch is straightforward enough for autonomous-vehicle teams: simulate rare scenarios without waiting for rare events. The broader wager is more ambitious. Decart says the product is meant to seed an ecosystem of developers who will build on world models the way they built on language models.

That matters because Oasis 3 is not being framed as a demo or a one-off research artifact. It is positioned as an API-first platform built on Decart’s DOS optimization stack, which suggests the company wants the technical stack and the distribution model to reinforce each other. If the runtime can keep latency low enough and fidelity high enough, Decart gets a chance to make the world model itself a software layer that other teams can call, test against, and eventually integrate into production pipelines.

A world model that developers can actually call

The most important detail in the launch is not just that Oasis 3 generates driving environments in real time. It is that developers can program against it from day one.

That API-first choice changes the product shape. Instead of selling a closed simulation environment or a bespoke services engagement, Decart is offering something that looks closer to infrastructure. In practice, that means AV engineering teams can wire the model into existing test harnesses, automate scenario generation, and explore edge cases without building a custom simulator stack from scratch. It also makes the system legible to robotics teams, which often need synthetic environments that can stress perception and planning systems before hardware time is spent.

The appeal is obvious. Rare driving events are expensive precisely because they are rare. A world model that can generate hours of photorealistic driving on demand gives teams a way to create repeatable experiments around long-tail behavior: unusual merges, difficult weather, unexpected pedestrian motion, or corner cases that are hard to capture in logged data alone.

But API access cuts both ways. Once a model is exposed as a service, the questions shift from “Can it generate compelling video?” to “How deterministic is the output across runs? How much state can a caller control? How quickly does it respond under load? What happens when the scene drifts?” Those are engineering questions, not marketing questions, and they will determine how widely the system gets used.

DOS, latency, and the practical shape of the stack

Decart says Oasis 3 runs on its DOS stack, which is important because world models are only useful if the runtime can keep up with interaction. A driving environment that looks good in a rendered clip but lags the moment an agent takes an action is not much help for planning or control research.

That makes latency a first-order constraint. Real-time generation is not just a product feature; it is part of the model’s utility. If the response time is too slow, then AV teams may still use the system for offline scenario creation, but not for interactive testing. If the fidelity is high but the motion artifacts are inconsistent, the model may be useful for qualitative review while remaining fragile for automated evaluation. And if both latency and fidelity vary materially with workload, developers will have to build around those limitations rather than through them.

The DOS stack likely matters here because the compute path is part of the product, not an afterthought. For developers, that means the evaluation should not stop at the model output. It should include how the stack handles throughput, session length, state persistence, and failure modes. For hardware teams, the key issue is whether the service maps cleanly to their own accelerators, bandwidth constraints, and deployment environments. For operators, the question is whether the stack can be integrated into CI-like workflows without creating a fragile dependency on a remote service.

The business logic is platform, not project

Decart is making a platform bet, and it looks familiar.

The company has said it already has a community of more than 100,000 developers around Lucy, its real-time video model used in areas like e-commerce and live streaming. Oasis 3 appears to be a push from that base into physical AI, with AV simulation as the first target and robotics as the longer-term opportunity. That sequencing suggests a classic ecosystem strategy: attract developers early, encourage experimentation at low friction, and expand the surface area of the product before competitors define the category.

The OpenAI comparison is not perfect, but it is directionally useful. In both cases, the company is trying to make the model itself an operating environment that others build around. The value is not only in the immediate capabilities; it is in the accumulation of integrations, tooling, and habits that make switching costs higher over time.

That is also where pricing becomes strategic. At $0.02 per second, Oasis 3 is making a clear signal about accessibility, but it is not a trivial cost once usage scales. A single hour of simulation works out to $72, which is manageable for experimentation and targeted validation, but it starts to matter quickly if teams are running many parallel scenarios, long-duration tests, or continuous pipelines.

For AV companies, the economic comparison will not be against a single GPU hour in isolation. It will be against the cost of existing simulators, engineering time, scenario coverage, and the value of reducing real-world test miles. For robotics teams, the calculus is even more dependent on integration work: if the model accelerates research but cannot be wired into current toolchains cleanly, the effective cost may be higher than the sticker price suggests.

The caveats are the story, not the footnotes

The launch is compelling precisely because it is plausible, but the caveats are the point.

Real-time photorealism is a moving target. A system can be useful without being perfect, but teams will need to know where approximation begins. Does the model preserve geometry consistently? Does the scene remain coherent over longer horizons? How does it handle rare objects, unusual lighting, or abrupt interactions between agents? Those details matter when the output is being used as input to downstream testing or planning systems.

Cost is the second constraint. API-based usage is easy to adopt and easy to expand, which means bills can grow faster than pilot budgets. Teams will need usage controls, scenario curation, and clear rules for what belongs in synthetic simulation versus what still demands live-road or closed-course validation.

The third constraint is integration. Existing AV and robotics toolchains are already full of data pipelines, evaluation frameworks, and safety checks. A useful world model has to fit into that stack without forcing a rewrite. It also has to survive the scrutiny that comes with safety-adjacent workflows. Even if a synthetic environment is valuable for testing, it does not change the underlying regulatory or validation burden.

That leaves vendor lock-in as the strategic risk lurking beneath the technical one. If Oasis 3 becomes the first broadly usable world model that developers build around, Decart will own an important layer of the stack. But if the ecosystem grows before the interface conventions settle, early adopters may find themselves tied to a single runtime and pricing model before the market matures.

What teams should test first

For engineering leaders evaluating Oasis 3, the right first move is not broad adoption. It is a constrained pilot.

Start with one or two scenario classes where rare-event coverage is currently weak. Measure whether the model can generate useful variation without losing coherence across time. Benchmark latency against the specific workflow you care about, not an abstract benchmark. If the target is interactive testing, the service must stay responsive in-session. If the target is offline scenario generation, throughput and consistency may matter more than sub-second reaction time.

Next, run the economics. Model expected spend under realistic usage, not demo usage. Include long-running simulations, parallel jobs, retries, and integration overhead. Then map where the API fits in the existing AV or robotics pipeline: data ingestion, scenario generation, evaluation, logging, and any safety review gates.

Finally, inspect the stack fit. The key technical question is not whether Oasis 3 can generate impressive scenes. It is whether Decart’s DOS-backed runtime can slot into the systems developers already use without creating a new island of infrastructure. If it can, the product has a shot at becoming a serious tool in synthetic driving workflows. If it cannot, it may remain an impressive but expensive layer that teams use selectively rather than structurally.

That is the tension around Oasis 3 in one sentence: Decart is offering a programmable driving world, but the market will decide whether it is a platform, a product, or just a very expensive preview of what world models might become.