Skild AI Open-Sources Steel Solver in Newton Physics Engine

Skild AI open-sourced Steel, a GPU rigid-body solver built with NVIDIA and wired into the Newton physics engine, in November 2026. Skild's blogs index highlights "Steel: Scaling Simulation Across Robots, Tasks, and Worlds" and its teaser cites 3.8× PhysX simulation throughput.

For embodied-AI builders, the release is infrastructure, not a new policy model. It attacks the bill for simulation-heavy training that Skild S1, NVIDIA Isaac Lab 3.0, and LeRobot streaming rollouts all assume you can afford.

TL;DR

What Skild and NVIDIA announced

Skild's November 2026 featured post, "Steel: Scaling Simulation Across Robots, Tasks, and Worlds," frames Steel as unlocking scalable simulation for manipulation for everyone. The Skild blogs index lists the article as co-introduced with NVIDIA.

Third-party summaries on November 9 sometimes quote higher throughput figures than Skild's own blogs teaser. explainx.ai did not re-run benchmarks. Use Skild's 3.8× line to prioritize a trial, not to skip your own profiling.

Steel targets articulated robots: arms and humanoids with joints, contacts, and friction patches—the workloads that dominate warehouse and home manipulation research.

Newton v1.8 and SolverSteel features

Stacked chip layers illustrating multi-level physics simulation workloads

The Newton v1.8.0rc1 release on GitHub documents SolverSteel as experimental:

• Featherstone articulated-body dynamics with a projected Gauss-Seidel contact solve and coupled Coulomb friction
• Friction patches, loop-closing and mimic joints, joint friction
• Optional run-to-run determinism, passive-island sleeping, CUDA graph capture
• Use inside coupled solvers

Newton's release notes also list faster cold loads, cheaper BVH builds on large replicated worlds, and broader collision performance work—useful when you scale from one robot to thousands of parallel envs like NVIDIA's COSMOS and G1 demos.

Solver choice is not ideology. Newton's docs compare MuJoCo, Featherstone, XPBD, and now Steel on coordinates, deformables, and differentiability. Steel is aimed at GPU rigid articulation when PhysX historically owned NVIDIA sim stacks in Isaac Sim workflows.

Why simulation speed changes model training

Robot gripper mirroring a human demonstration in a simulation-style scene

Robot foundation models need diversity and volume of interaction. Figure's Index dataset and open human-scale teleop releases exist because real-world hours are scarce.

When simulation is slow, teams shrink parallel env count or shorten episode length, which biases policies toward short-horizon tricks. Skild's S1 pitch—10-minute tasks from one video—assumes you can still afford heavy post-training in sim after deployment gaps.

A 10× sim speedup does not automatically yield 10× real robot success. Sim-to-real gap remains, as Berkeley–NVIDIA CORL coverage stresses. It does let you search more hypotheses before touching hardware.

Comparison frame: PhysX, MuJoCo, Isaac

None of these rows are benchmarks we ran. They map decision axes for teams picking sim back ends this quarter.

How to evaluate Steel on your robot

1. Pick one env that matches production contacts (boxes, tools, cables).
2. Profile baseline steps/sec on your current PhysX or MuJoCo config at fixed GPU.
3. Port to SolverSteel on Newton 1.8 rc with identical reward and observation code.
4. Track memory and determinism flags if you rely on replay buffers.
5. Only then scale env count.

If you train through Hugging Face LeRobot, watch integration glue—solver swaps rarely drop in without scene retuning.

Industry context November 2026

November is dense for physical AI: CoreWeave–Wayve Blackwell training deals, CrossnoKaye physical AI on Bedrock AgentCore, and HandShake RL data labs. Steel sits in the open tooling lane that keeps smaller labs competitive on data volume, not just frontier model APIs.

Skild also acquired Zebra's robotics arm earlier in 2026 per its blog history—Steel may support warehouse-scale sim if Skild aligns it with omni-bodied Skild Brain deployments.

Limits and honesty

• 3.8× is Skild-reported in the public blogs teaser; benchmark tables were not published when we filed.
• SolverSteel is experimental in Newton rc; APIs may move before 1.8 final.
• Open source does not mean free compute; you still pay for GPUs.
• Faster rigid-body sim does not solve deformable manipulation alone; Newton's XPBD/VBD paths remain separate.

Newton solver lineup: where Steel fits

Newton documents multiple backends. Teams already on SolverMuJoCo may stay put for research reproducibility. Teams hitting GPU memory walls on PhysX-heavy Isaac scenes are Steel's pitch.

Steel does not replace deformable manipulation (cables, cloth) where SolverVBD or Style3D matter. Warehouse pick-and-place with rigid totes is the sweet spot.

Coupled solvers and contact graphs

Newton v1.8 release notes emphasize coupled solvers and deterministic contact processing. For RL, determinism trades with throughput. Steel exposes opt-in run-to-run determinism—enable it when debugging policy collapse; disable it when sweeping hyperparameters at scale.

Contact graph performance work in the same release (hydroelastic, SDF, pyramid contacts) suggests NVIDIA and contributors are pushing GPU collision broadly. Steel is one slice; your bottleneck may still be mesh preprocessing or USD import, not integration steps.

Integration with Isaac and Omniverse assets

Many teams import OpenUSD scenes from SimReady libraries. Solver swaps rarely keep identical contact manifolds. Budget a regression week re-tuning friction and solver iterations when moving PhysX scenes to Steel.

Skild's partnership branding with NVIDIA implies future reference envs, but none were bundled in the November 9 blog excerpt we read. Watch Skild and Newton repos for sample scenes.

Memory claims and batch training

Validate on your asset counts: dense mesh hands and multi-body grippers inflate contact buffers. Profile peak VRAM not just average step time. Skild's public blogs teaser when we filed did not state a GPU memory ratio.

Open source economics for robotics startups

Steel's release follows a year of big robotics fundraising and lab acquisitions in Skild's blog archive. Open sim infra lowers the capital needed to iterate before touching hardware—a mirror of how open LeRobot policies lower integration tax.

Startups competing with Skild on policies can still adopt Steel on Newton without adopting Skild Brain models. Conversely, Skild customers may fear vendor coupling if solver improvements lag the open repo. Watch commit velocity on newton-physics/newton after November 9.

Safety and sim fidelity warnings

Faster sim can overfit to simulator quirks. Keep real robot eval cadence fixed while increasing sim steps. Unitree G1 Cosmos demos show sim success rates above 97% on some LIBERO tasks—real warehouses remain harsher.

Document sim version in dataset cards when publishing policies trained on Steel-backed envs.

Policy training and sim-heavy RL

Reinforcement-learning stacks on robots spend billions of environment steps cheaply in sim. Steel targets that variable cost. If you use human-in-the-loop corrections like Skild S1, faster sim frees budget for more real-world eval episodes, which still gate deployment.

Document whether policies were trained on Steel vs PhysX when publishing sim-to-real numbers so reviewers can reproduce contact dynamics.

Hardware notes for benchmarking Steel

Skild's throughput claims assume modern NVIDIA GPUs with enough VRAM for parallel envs. On L40S or A100 class cards, measure:

• Steps per second at fixed num_envs.
• Wall time per million steps including USD load and reset.
• Numerical drift against a PhysX golden trace on the same seed.

If you only have consumer GPUs, expect smaller env batches and measure VRAM before assuming datacenter-class headroom. Publish hardware tables with any blog post or paper claiming sim speedups.

When to stay on PhysX or MuJoCo

Stay put if:

• Your factory already certified PhysX contact tuning for a deployment-bound policy.
• You need differentiable sim paths Newton documents elsewhere, not Steel's rigid focus.
• Your robot stack is ROS + Isaac with no Newton import path yet.

Migrate when sim cost blocks experiment count, not when a headline promises 3.8× without your URDF attached. File a GitHub issue on Newton if your robot description fails to import; rc releases need community signal on real articulations. Pin Newton commit hashes in paper appendices when reporting sim numbers. Cite whether Steel or PhysX produced each learning curve. Reviewers will ask which solver generated every reward plot in robotics submissions this year. Answer in the methods section, not the appendix alone. Two sentences there prevent reviewer churn.

Related reading

• Skild S1 one-video learning
• Agentic robotics at CORL with Isaac Lab 3.0
• LeRobot 0.7 streaming rollouts
• NVIDIA SimReady and Isaac workflows
• Open HumanScale teleop data

Sources: Skild AI blogs · Newton v1.8.0rc1 release notes