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 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; ovphysx gives you the physics engine without the app around it; and ovstage provides a runtime scene substrate they can share under application control. ovstorage is a different shape (an API-driven service for cloud-native asset storage and sync rather than something you import into one script), but it also needs no .kit file or extension registration. Newton and Warp cover advanced multi-physics and GPU kernel work 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.
Kit extension inside Composer
Library-first renderer behind a browser
If you need a mature authoring application with deep extension integration, a viewport, and a large existing UI ecosystem, Kit is still the natural place to start. But an interactive panel is no longer, by itself, proof that you need a Kit app. The newer ovstage, ovui, ovrtx, and ovstream path makes a standalone, library-native viewer possible too. The choice is now about how much application framework you need, not whether a person will click anything.
Why this isn’t a minor change
The change goes beyond packaging in two ways.
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.
It also 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
I would bookmark NVIDIA’s running catalog at developer.nvidia.com/omniverse, since this list dates faster than the article around it. I checked the list again in August 2026, but the hub should still be treated as the current source. The public pieces I would start with are:
ovstage: a pre-release runtime scene library for shared state across standalone Omniverse libraries. It is the stage layer that my first browser-viewer build was missing.ovrtx: RTX rendering and sensor simulation. Starting with 0.4, it integrates withovstage; its older renderer-owned stage APIs are deprecated.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 next one.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 Python UI library for standalone app interfaces, including interaction tests and CI screenshot checks. Together withovstage,ovrtx, andovstream, it makes a library-native interactive viewer a real option. Kit still has the more mature authoring and extension environment.- 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. For CAD or asset pipelines, omniverse-cad-to-simready 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” 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 a full authoring application may still be the right shape for the job. Kit is simply no longer the only entry point. New headless, pipeline, and even some interactive viewer work can start from the libraries; the framework becomes a choice rather than a platform requirement.
Disclaimer: The views and opinions expressed in this account are those of my own and do not represent those of my employer, NVIDIA.