If you learned Omniverse by building a Kit extension, the ground moved under you in the last few months, and you might not have clocked it yet because nothing broke — your old extension still runs fine. If you’re picking up Omniverse for the first time now, you might not even realize there used to be only one way to build on this platform, and that the new way changes who this is actually for.
I built a Kit extension 5 months ago — a gas leak simulator, the kind of thing you build to learn the platform, not to ship. Place a leak point in a USD scene, set a flow rate and wind direction, click a button, watch an animated gas plume drift across the stage. Simple idea. To get there I had to launch a full Kit application (Composer, on a Windows EC2 box), scaffold an extension with its own extension.toml and folder structure, subclass omni.ext.IExt, register the extension in the app’s .kit file, and build the whole thing around Kit’s on_startup / on_shutdown lifecycle. All of that, for what was conceptually just “draw some spheres and move them over time.”
Why Kit was built this way to start with
That overhead wasn’t an accident or an oversight — it’s what you pay for building inside an application framework, and that framework was solving a real problem. Kit SDK exists so that USD Composer, Isaac Sim, USD Explorer, DRIVE Sim, and AODT can all share one core — the same renderer, the same physics engine, the same USD data model, the same UI toolkit — instead of each being written from scratch. Extensions are the unit of composability: fork a .kit config, swap a few extensions, and you have a new app. That’s a genuinely good model when what you’re building is an interactive tool that people click into, with panels and a viewport and live editing.
The tax is that “building on Omniverse” and “building a Kit App” used to be the same sentence. Even if all you wanted was the renderer, or just the physics engine, for a script or a service with no UI at all, you still had to bring the whole app process with you.
Where that tax actually showed up
Nothing here is theoretical — this is what the gas leak build cost me directly:
Every code change meant relaunching the full Kit app to see it take effect, and Kit’s launch isn’t instant. Hot reload works for Python extensions but not C++, so some changes still meant a rebuild. Getting the extension recognized at all required exact agreement between the folder structure, the module path in extension.toml, and the [dependencies] line in the .kit file — miss one and you get an import error with a stack trace that doesn’t point at the actual mismatch. Debugging meant grepping Kit’s console output for your own print statements, because there wasn’t a better window into what happened. And a few failures were just silent: I tried to spawn a FlowEmitter prim for a more realistic volumetric gas effect, and it never worked — no crash, just a warning about omni.flowusd failing to import buried in the launch log, and an empty prim where the gas effect should have been. I only found the warning by piping the launch output through a text filter looking for anything mentioning “flow.” None of that was a bug. It’s what the process model costs when what you’re actually doing is scripting some geometry.
What actually changed
The libraries got pulled out of Kit and made available on their own. ovrtx gives you the RTX renderer and sensor simulation directly — pip install it and it runs as a normal Python process. ovphysx gives you the same physics engine that powers omni.physx, without the app around it, the same way. ovstorage is a different shape — it’s an API-driven service for cloud-native asset storage and sync, meant to run as its own Kubernetes-ready deployment rather than something you pip install into a script — but the point holds: no .kit file, no extension registration, no app process wrapping it. Newton and Warp cover next-generation multi-physics and GPU kernel work, also as plain Python packages. None of this needs an on_startup hook or an app to launch. NVIDIA’s own Isaac Lab 3.0 Beta is doing exactly this migration — moving its foundational layer off the Kit framework onto ovphysx and ovrtx directly, specifically to get explicit execution control, independently-stepped simulation components, and headless deployment without UI dependencies.
Same job, before and after
Take the part of the gas leak build that didn’t actually need a UI panel — just placing USD geometry and animating it over time, the kind of thing you’d want to run headless in a CI job or a batch script.
Before: launch Composer through repo.bat launch, wait for the full app to come up, register a Kit extension with its own extension.toml, subclass omni.ext.IExt, write the geometry-creation code inside on_startup, wire it to UI buttons even if nothing needs clicking, and relaunch the app every time you want to see a change land.
After: pip install ovphysx (or just use pxr.UsdGeom directly if you don’t even need physics), write a plain .py file, run it with python script.py. No app, no extension manifest, no .kit file, no lifecycle hooks. The code that actually mattered — the part that builds the tank, the pipe, the plume — barely changes. Everything around it disappears.
To be clear about where the line actually sits: if you need the interactive panel — sliders someone drags in a live authoring session — you still want a Kit extension, because that UI only exists inside a Kit App. The shift doesn’t make Kit extensions pointless. It makes them optional for everything that isn’t that.
Why this isn’t a minor change
It’s tempting to read “some libraries got pip-installable” as a packaging detail. It isn’t, for two reasons.
First, it changes who can build on Omniverse at all. Before this, using the renderer or the physics engine meant learning Kit’s extension model, its dependency graph, and its app lifecycle — a real onboarding cost even if your actual goal had nothing to do with building an app. Now that cost is optional. A robotics engineer writing an RL training loop, or a platform team wiring synthetic data generation into a CI pipeline, can import a library the same way they’d import any other Python package, and never touch a .kit file.
Second, it changes what “building on Omniverse” means as a category. It used to mean one thing: build an app, or extend one. Now it means at least two different things depending on whether your deliverable has a UI a person clicks into, or is a process that runs unattended. Those are different engineering problems with different constraints, and until this shift, Omniverse only had good answers for one of them.
This isn’t just my read of some pip packages, either — NVIDIA made the same case as a headline announcement at GTC Taipei / Computex 2026, releasing a major collection of open-source physical AI skills and tools that turns Omniverse libraries, Cosmos, Isaac, and Metropolis into agent-callable tools. That’s the company saying, in public, that the library-first direction is the strategy now, not a side path.
The libraries and skills available today
NVIDIA keeps a running catalog of all of this at developer.nvidia.com/omniverse — worth bookmarking directly, since this list will be out of date faster than this article will. Everything below is accurate as of June 2026; this space is moving fast enough that I’d expect more libraries and skills to land in the months after this is published, so treat the hub link, not this list, as the source of truth going forward. Here’s what’s actually public right now, not roadmapped:
ovrtx— RTX rendering and sensor simulation.pip install ovrtx.ovphysx— the PhysX-based physics engine, standalone.pip install ovphysx.ovstream— WebRTC/RTSP/shared-memory streaming for video, audio, and input, without a Kit App behind it. GitHub andpip install ovstreamonly — I couldn’t find an NGC catalog listing for it, unlike the one below.ovstorage— cloud-native APIs to manage, store, and sync OpenUSD asset data, no app required. Also distributed via NVIDIA NGC if you’d rather pull it from there than GitHub.ovui— a newer, more scoped piece: a Python UI library for app interfaces, interaction tests, and CI screenshot checks. Worth watching, but positioned for scripted UI and testing today, not for replacing a live authoring panel like the one the gas leak simulator needed — my line above about “if you need the interactive panel, you still want Kit” still holds for now.- Warp — NVIDIA’s GPU kernel framework for Python, useful for differentiable and physics-adjacent simulation work, and one of the engines the newer physics stack builds on.
On the skills side — meaning packaged, documentation-driven workflows an agent can run, not just libraries you import — NVIDIA publishes a public catalog at github.com/nvidia/skills, also linked directly from the developer hub above. The one worth knowing about if you’re touching CAD or asset pipelines is omniverse-cad-to-simready, which coordinates the conversion → material/physics assignment → validation → packaging workflow for turning a raw CAD or source asset into something simulation-ready. It’s a coordination layer over real, separately public tooling: aif-pipeline-samples has the actual CAD-to-USD conversion scripts, scene-optimization presets, and validators, and simready-foundation defines what “SimReady” actually means as a spec, not just a marketing word. If Kit’s extension-registry overhead is the pain point you’re chasing down, the hub also lists an omniverse-usd-performance-tuning skill for profiling and tuning large scenes.
What I’d actually do about it
If you’re new to Omniverse and your actual goal is headless — training, batch data generation, a service, anything without a person clicking a panel — start with the libraries directly and skip learning the Kit extension model until something forces your hand. You’ll save yourself the exact overhead I hit building the gas leak extension, most of which had nothing to do with the actual problem I was solving.
If you already have Kit extensions in production, there’s no urgency to rip them out — they still work, and if what you’re building genuinely needs an interactive UI, Kit is still the right tool. The thing to update is just the assumption that Kit is the only entry point. New headless or pipeline work doesn’t need to go through it anymore, and treating it like it does is now a self-imposed tax, not a platform requirement.
Disclaimer: This is my own individual opinion, formed from my personal experience working with this technology. It does not represent an official NVIDIA position. I may have gotten something wrong or missed a detail — always happy to be corrected.