Skild AI Open-Sources Steel, a Physics Solver for Robots 13x Faster Than PhysX

TL;DR

Steel is Skild AI's GPU rigid-body physics solver, built with NVIDIA for the open-source Newton physics engine, and on Nov 9 the company dropped it under Apache-2.0. Across 20 robot-learning benchmarks it delivers 3.8x PhysX's simulation throughput on geometric mean. On batches that mix different robots and tasks, the shape general-purpose robot training needs, the gap reaches 13x. You can poke the solver right now in a browser playground on your own GPU, nothing to install.

What shipped

Announced at the Conference on Robot Learning in Austin and confirmed in NVIDIA's own CoRL post, Steel (Scalable Throughput-optimized Engine for Embodied Learning) is a rigid-body dynamics solver developed directly inside Newton. It ships as newton.solvers.SolverSteel in the Newton 1.8 release candidate, is meant to slot into NVIDIA Isaac Lab, and shares Newton's model representation and collision infrastructure instead of being a rival stack.

The standalone GitHub repo is mostly a README, a poster, and a license. The working code lives in the Newton tree. That is the point of the release: Skild contributed its solver to an existing Apache-2.0 engine instead of shipping a rival one. The repo also carries one sentence that doubles as a timestamp: Skild is "actively accepting contributions from you and your agents."

The numbers, stated carefully

All figures are Skild's own benchmarks, simulation-only throughput (physics stepping, not end-to-end training), on a single RTX PRO 6000 Blackwell, with each engine run at its best measured batch size. Measured November 7-9, 2026.

• Across 20 single-task benchmarks: 3.8x PhysX geometric-mean throughput, faster on 19 of 20 tasks. PhysX keeps exactly one win, Cartpole, where Steel's sweep stopped early while its throughput was still climbing.
• Against MuJoCo Warp 3.17, which itself runs 2.9x PhysX on the same suite, Steel lands at roughly 1.3x MuJoCo Warp.
• Worst case for the incumbent: batches mixing 5, 10, 15, or 20 different task types (humanoids, quadrupeds, arms, dexterous hands) run at 9.2x to 13.0x PhysX's peak measured throughput.
• The 20-type mixture: Steel hit 3.90 million environment steps per second at 245,760 parallel environments, against 300,000 for PhysX at its best 61,440. At a matched 61,440 environments, Steel ran 12.0x PhysX while using about 62% less GPU memory, roughly 11 GiB versus 29 GiB.

The memory number matters as much as the speed one. 12x throughput at 62% less VRAM buys two options: train the same workload on a much smaller GPU, or pack several different experiments into hardware that used to hold one.

Heterogeneity is the actual idea

Most GPU physics engines are fastest when they clone one identical workload thousands of times: one robot, one scene, batch after identical batch. General-purpose manipulation needs the opposite. As Skild puts it, "clean the table" turns into a completely different action sequence when the objects, layout, or constraints change, and a parallel gripper, a dexterous hand, and a humanoid each solve a task differently.

Mix those in one batch the naive way and you pad every environment to the dimensions of the most complex one. It is a coat check that hands every guest the biggest locker because one guest brought a cello. Steel instead organizes dynamics per environment, groups articulations with similar joint counts so the GPU executes tidy bundles, and re-routes contact solving every step: environments with no contacts take a lightweight path, one small robot gets a compact local solve, cluttered scenes get the general solver.

On the 23-joint Kuka arm with an Allegro hand, exactly the articulation-heavy case that breaks padded engines, Steel ran 6.7x PhysX and about 1.8x MuJoCo Warp.

Why a robotics lab gives away its engine

Skild's stated bet is that general robot policies need experience that is broad as well as plentiful. Its S1 work scaled pretraining volume; its omni-bodied work argues one intelligence should learn across many bodies rather than one policy per robot. Real-world collection grounds the policy but cannot cover every recovery scenario, while simulation gives repeatable on-policy exploration, including the failures. In Skild's own summary, Steel "addresses one piece of making that approach practical: the cost of simulating increasingly diverse tasks and robot embodiments together."

You can also read the strategy straight off the contribution: the cheaper diverse simulation gets for everyone, the more the ecosystem standardizes on Newton, where Skild is now a core contributor. Newton also handles the deformables that rigid-only engines skip: the launch demos couple Steel with cloth, cables, MPM sand, and hydroelastic contact, plus an experimental differentiable step you can backprop through.

Try it before you trust it

• Browser first. The playground runs steel-webgpu, a WebGPU port of the solver, on your own GPU across 24 scenes. Pull objects around mid-simulation and change solver settings. Nothing is recorded.
• For real training. Install Newton 1.8 and select newton.solvers.SolverSteel. Isaac Lab 3.0, also released this week, lets you switch between PhysX and Newton backends; NVIDIA separately reports Isaac Lab 3.0 with Newton at up to 2.5x the end-to-end training throughput of Isaac Lab 2.3 with PhysX, a different measurement from Steel's sim-only numbers.
• Standalone. Isaac Lab can run on the Newton backend without a full Isaac Sim install, which puts credible parallel robot sim on a homelab GPU, no Omniverse stack required.

Caveats

• Vendor benchmarks. Every number above comes from Skild's own measurements; NVIDIA's post confirms the collaboration and the release but not the ratios. No independent replication exists yet, and the repo had roughly 115 stars the morning after launch.
• Best-batch comparisons. Peak-vs-peak ratios compare each engine at its own best batch size, which favors whichever engine scales furthest. The matched-batch figures (12.0x, 62% less memory) are the fairer read.
• The PhysX version matters. Skild compared against PhysX from Isaac Sim 6.1.0.0 and disclosed that 6.0.0.0 ran these mixtures up to about 2.7x faster than 6.1, a PhysX runtime regression Skild chose not to exploit.
• Moving target. Steel rides a Newton 1.8 release candidate, reuse_kinematics is opt-in, and the differentiable step is labeled experimental. Expect the numbers to move in both directions.

Key Takeaways

• Skild AI open-sourced Steel on Nov 9, a GPU rigid-body solver built with NVIDIA inside the Apache-2.0 Newton engine, shipping as newton.solvers.SolverSteel for Isaac Lab robot training.
• Measured claims: 3.8x PhysX geometric-mean throughput over 20 benchmarks (19 of 20 task wins, Cartpole the exception), about 1.3x MuJoCo Warp, and 9.2x to 13.0x PhysX on batches mixing 5 to 20 different robot task types.
• Peak run: 3.90 million environment steps per second at 245,760 parallel environments; at a matched 61,440 environments, 12.0x PhysX throughput on about 62% less GPU memory (roughly 11 vs 29 GiB).
• The reusable idea is heterogeneity: group articulations by joint count and route contact solving per environment per step, so mixed-robot batches stop paying the padding tax of worst-case sizing.
• All numbers are Skild's own sim-only benchmarks on one RTX PRO 6000 Blackwell, engines at best batch size, against PhysX from Isaac Sim 6.1; end-to-end training speed is a separate claim.
• You can try it now: a WebGPU playground runs 24 scenes in the browser on your own GPU, and Newton 1.8 plus Isaac Lab 3.0 brings the solver into standard RL pipelines.

Sources: Skild AI Steel announcement, Steel on GitHub, NVIDIA CoRL blog, Newton on GitHub, NVIDIA Isaac Lab, RuntimeWire