NVIDIA Open-Sources OSMO: One YAML Runs Your Whole Robot Pipeline

NVIDIA just put its robot-pipeline tool on GitHub. It is called OSMO, and it is free under the Apache 2.0 license. One YAML file now describes a whole robot pipeline: training, simulation, and testing on the real robot. OSMO runs the plan across your machines, wherever they are.

Robot teams have a problem that most people never think about. Their work needs three very different computers at once. NVIDIA calls this the Three Computer Problem. Training wants big GPU clusters. Simulation wants GPUs built for graphics. Testing on the robot wants a small, low-power chip bolted to the machine itself. Getting data and jobs to flow between the three has always meant custom scripts and rare skills. OSMO replaces that glue with one plan file.

Wait, what is OSMO exactly?

OSMO is a workflow orchestrator. It does not train anything. It does not simulate anything. It does not deploy models to robots. It tells everything else when to run and where.

You write your pipeline as tasks in one YAML file. OSMO schedules each task on the right machines, moves the outputs between them, and tracks it all in a web UI. Two parts make it work:

• OSMO Service. The control plane. It has the API, the web UI, and the scheduling brain.
• OSMO Operators. The workers. You deploy these on your compute clusters, and they register the clusters with the service.

NVIDIA built this for itself first. The README says OSMO ran workloads for Project GR00T, Isaac Lab, Isaac Sim, and Isaac ROS, moving thousands of GPU-hours a day. Now anyone can run it.

The YAML, line by line

Here is the real example from the official docs. Three tasks, three machines, one file:

workflow:
  tasks:
  - name: simulation
    image: nvcr.io/nvidia/isaac-sim
    platform: rtx-pro-6000          # Runs on NVIDIA RTX PRO 6000 GPUs

  - name: train-policy
    image: nvcr.io/nvidia/pytorch
    platform: gb200                 # Runs on NVIDIA GB200 GPUs
    resources:
      gpu: 8
    inputs:                         # Feed the output of simulation task into training
    - task: simulation

  - name: evaluate-thor
    image: my-ros-app
    platform: jetson-agx-thor       # Runs on NVIDIA Jetson AGX Thor
    inputs:
    - task: train-policy            # Feed the output of the training task into eval
    outputs:
    - url: s3://my-bucket/thor-benchmark/  # Save the benchmark to object storage

Read it top to bottom:

• platform picks a class of hardware, not a named cluster. rtx-pro-6000 for simulation, gb200 for training, jetson-agx-thor for the robot itself.
• inputs chains tasks together. Training eats the simulation output. Evaluation eats the trained policy.
• resources says how big, like 8 GPUs for training.
• outputs saves results to cloud storage.

No cluster names. No glue scripts. The same file runs on your laptop or on EKS, AKS, GKE, your own servers, or an air-gapped cluster. The docs offer a Docker and KIND quickstart to try it in minutes.

The wild part: your coding agent can drive it

OSMO ships with an agent skill. Install it with one command, npx skills add NVIDIA/osmo, and Claude Code, Cursor, or Codex can run the pipeline for you in plain English. The agent can check GPU resources, write workflows, submit them, watch progress, and fix failures.

The repo holds three skills: osmo-user for running workflows, osmo-deploy for setup, and osmo-admin for config. For big jobs, the skill spawns sub-agents that handle picking resources, writing the YAML, submitting, and retries on their own.

This is part of a bigger shift. Coding agents are quietly replacing chatbots, and multi-agent systems took off this year. NVIDIA's own Nemotron models ride the same wave at the model layer.

Should you use it? The honest limits

• You need Kubernetes somewhere. The service runs on a K8s cluster with PostgreSQL and Redis. Running workflows needs no K8s skills, but setting OSMO up means Helm and kubectl. No Kubernetes footprint means real setup work.
• The smooth path is NVIDIA end to end. The examples and containers are all NVIDIA stack. The README says it aims to be platform-agnostic and x86 and Arm GPUs work, but the tested path is NVIDIA.
• It is not an MLOps platform. No experiment dashboards. No model registry. No fleet deployment for production robots.
• The local quickstart has no login protection. The docs say it is not for production.
• Python-native workflows are coming, not here. Today, YAML is the interface.

FAQ

Is OSMO free? Yes. Apache 2.0 license, on GitHub at github.com/NVIDIA/OSMO. You can use it in commercial products.

Does OSMO replace Isaac Sim or my training stack? No. It orchestrates them. Isaac Sim still does the simulating. Your trainer still trains. OSMO just runs the whole chain in order across machines.

Can it run on machines with no internet? Yes. The docs list air-gapped clusters as supported.

Do I need one brand of hardware for all three stages? No. The platform field can point training at GB200 cloud GPUs and testing at a Jetson board on your desk. Mixed clusters are the design.

Will it work with my coding agent? If the agent supports the Agent Skills standard, yes. Claude Code, Cursor, and Codex are named in the docs.

What to do next

If your team runs Kubernetes and touches robots, spend an afternoon on the Docker quickstart. If you live in Claude Code or Cursor, install the skill and let the agent write your first workflow. And if you write glue scripts today, show them this post, because those scripts are what OSMO deletes.