This week: NVIDIA is spotlighting four open Cosmos 3 Nano checkpoints that turn robot moves and driving controls into the next camera view — and, for cars, matching LiDAR — so Physical AI can practice in worlds that push back.

Elsewhere: How the four models split the work, what it takes to run them, the fine print on those demos, and three more things that shipped this week.

The New Prime Signal

Most robot practice rooms are polite. You move an arm, a physics engine redraws a clean scene, and nothing surprising happens unless someone coded the surprise. Real floors are less cooperative: lighting shifts, objects slide, and the next frame is rarely the one you expected. On November 5, NVIDIA and Hugging Face spotlighted four open Cosmos 3 Nano checkpoints for interactive world simulation — models that generate the next observations from actions or scene controls, chunk by chunk. The technical report is on arXiv, weights sit in the Cosmos3 examples collection, and the Cosmos Lab project page shows the demos.

What shipped: All four checkpoints are post-trained examples of Cosmos 3 Nano with about 16B trainable parameters, released under the OpenMDW1.1 license, which NVIDIA says permits commercial and non-commercial use under its terms. Cosmos3-Nano-Transfer-Auto is the offline driving workhorse: synchronized video across up to 11 camera views, including fisheyes, with optional joint RGB–LiDAR, steered by World Scenario Map controls and text prompts for weather, lighting, and time of day. Cosmos3-Nano-Sim-Auto is its causal, few-step-distilled twin for streaming those same multi-view camera and LiDAR observations as driving controls update. Cosmos3-Nano-Sim-Transfer turns a physics simulator's spatial controls — depth, segmentation, edges, or blur — plus a text prompt into photorealistic RGB while the simulator keeps ground-truth state. Cosmos3-Nano-Sim-Bimanual predicts the next video from robot or camera actions and supports interactive two-arm simulation for YAM and AgiBot embodiments. A November 2 developer blog had already walked through Framework recipes; the November 5 Hugging Face post is the open-model spotlight tying the four together.

Why it matters: Physical AI still burns real robots, real cars, and real time collecting messy data. Synthetic worlds help only if they react — if an action changes what the cameras (and LiDAR) see next. Transfer-Auto and Sim-Auto aim at that for driving: same road layout, different weather; synchronized views that agree with 3D sensing; closed-loop rollouts when a WSM renderer feeds updated controls. Sim-Transfer keeps physics in the simulator and uses the model as a photoreal renderer. Sim-Bimanual skips the middleman and predicts the visual consequences of two-arm moves directly. NVIDIA's framing is careful: shared starting points for adapting models and measuring where they support policy learning — not a claim that the virtual road replaces the real one.

The fine print: Every capability claim here comes from NVIDIA's blogs, model cards, and technical report — team-reported, not independently re-run by us. The Hugging Face write-up is blunt that the hard work is still ahead: measuring where the models support policy learning, understanding their limits, and improving where they fall short. Hardware is not a laptop story. The developer blog lists Cosmos3-Nano generation needing about 58 GiB of GPU memory in BF16 (44 GiB in FP8 with offloading on the configurations they publish), and the Bimanual vLLM-Omni setup was tested on a GB200 — not a minimum-memory claim. Closed-loop driving also needs a simulation runtime and WSM renderer; reproducing a notebook is not putting a car on a track. Read OpenMDW1.1 before shipping anything commercial, and treat generated video and LiDAR as synthetic until you have checked it.

The New Prime Signal take: We like news that admits the world pushes back. A pretty video generator is a screensaver; a world model that takes your action and returns the next observation is a practice room. Opening four complementary checkpoints — offline driving data, streaming multi-sensor sim, control-to-RGB transfer, and two-arm action-to-video — is useful because the jobs are different. Keep the humility already in the post: open weights are a shared foundation, not a finished robot brain. If your policy looks brilliant only in a generated hallway, the hallway still owes you nothing. Think of it as a practice room that redraws itself every time the robot or the car moves.

How it works: Cosmos 3 uses a Mixture-of-Transformers backbone that links text processing and visual generation. The generator predicts short video chunks from the prompt, available controls, and generated history, then updates that history for the next chunk. Training follows a four-stage recipe NVIDIA documents publicly: bidirectional adaptation on full clips, teacher forcing on recorded history, consistency distillation down to a few denoising steps, and self-forcing on the student's own generated history so compounding errors show up during training. That is why Transfer-Auto (bidirectional, offline) and Sim-Auto (causal, streaming) are a pair, and why Sim-Transfer and Sim-Bimanual answer different questions: one renders from simulator state, the other predicts from actions directly.

Try it: Start with the Hugging Face Cosmos interactive-simulation blog for the four model cards, then the Cosmos3 simulation cookbooks and the November 2 developer walkthrough for Framework commands. Developers can clone Cosmos Framework, download a checkpoint such as Transfer-Auto or Sim-Bimanual, and run the published skills — but be realistic: you need Linux, an NVIDIA GPU (often several for the multi-view Auto examples), Docker with the NVIDIA Container Toolkit for the vLLM-Omni path, and a Hugging Face token. The arXiv report and project site spell out what each embodiment and sensor setup actually supports.