What happened
Skild AI's blog listing for November 2026 features an announcement titled “Steel: Scaling Simulation Across Robots, Tasks, and Worlds.” Attributed to the Skild Team, the listing says Skild AI and NVIDIA are introducing Steel, a GPU-accelerated rigid-body dynamics solver for Newton. Newton is described in the announcement as an open-source physics engine.
The headline claim is performance. Skild AI says Steel delivers 3.8 times PhysX's simulation performance. The listing places that claim in the context of scaling simulation across robots, tasks, and worlds. It therefore presents Steel as a component for running physical simulations rather than as a robot model, a simulation-generating model, or a complete robotics application. The named comparison point is PhysX, NVIDIA's physics simulation technology.
A rigid-body dynamics solver is the component that computes the motion and interaction of bodies in a simulated scene. In a robotics workflow, that can include the motion of a robot and the contacts it makes with its surroundings. GPU acceleration matters because large training or evaluation runs can require many simulated environments. If a solver completes comparable workloads more quickly, a team may be able to run additional trials within a fixed computing budget. That is an implication of the type of system Skild AI describes, rather than a performance guarantee from the announcement.
Skild AI's public listing supplies only a high-level description. It does not identify the hardware behind the 3.8 times comparison, the robots or environments used, the number of simultaneous simulations, the measurement definition, or the physics settings. It does not state whether the result measures throughput, elapsed runtime, or another metric. Nor does the listing name a Newton version, installation method, supported GPU range, access date, price, or license terms. The public page dates the item only to November 2026. Builders can establish that Steel is being announced as a GPU solver for Newton, but cannot yet use the listed figure to estimate savings in a specific training stack.
What the archive adds
New Runtime's earlier coverage examined NVIDIA's four open-weight Cosmos 3 Nano checkpoints for interactive driving and robotics simulations on 2026-11-05 (New NVIDIA Cosmos 3 Open Models for Interactive World Simulation). It also covered Standard Physics' open-source Reynolds agent for running OpenFOAM simulations on 2026-11-06 (Standard Physics launches Archimedes and open-sources Reynolds CFD agent). Steel is a new event on the same broad simulation stack: it concerns rigid-body physics inside Newton rather than world-generation checkpoints or a CFD-running agent.
Trend signal
This directionally supports Generative media becomes application infrastructure. The relevant signal is not that Steel is generative media; it is that simulation capabilities are being framed as components that can sit inside a larger robotics workflow rather than as one-off demonstrations. The fit remains limited: Skild AI's announcement does not describe an application interface, integration method, or deployment workflow.
Why now
The announcement is dated November 2026 and is framed around simulation across multiple robots, tasks, and worlds. Skild AI does not explain the timing or tie Steel to a named customer deployment, research result, or Newton release. The available timing signal is therefore simply that the company is positioning simulation performance as a current part of its robotics platform work.
Connections to other events
New Runtime's earlier coverage of Reynolds described an agent that runs OpenFOAM simulations and returns figures, numerical results, and rerunnable cases. Steel addresses a different simulation domain: rigid-body dynamics rather than computational fluid dynamics. Together, the two events point to a broader engineering workflow in which agents, models, and specialized simulators can each occupy distinct roles, though neither announcement establishes an integration between the projects.
Why it matters
Robotics teams commonly need simulated experience before they can safely or economically collect enough physical-world data. The simulator is therefore part of the iteration loop: it affects how many environments, task variants, and policy evaluations a team can afford. A genuine speed improvement at the solver layer can shorten that loop or enable larger experiments without increasing GPU spend.
That potential is especially relevant for teams using Newton or considering it as their physics engine. But the public claim is not enough to select infrastructure. Simulation speed alone does not tell a team whether the contact behavior, stability, determinism, and interfaces are suitable for its robot. A faster system can be a poor trade if it changes the physical signals on which a policy depends. The immediate consequence is not “replace PhysX”; it is “identify whether the stated comparison applies to the workload that matters.”
Limits and uncertainty
Skild AI's blog listing does not disclose the methodology behind its 3.8 times PhysX performance claim. There is no stated hardware configuration, benchmark workload, batch size, robot set, scene configuration, metric definition, or accuracy criterion. The result has not been independently checked here.
The listing also does not specify Steel's release status, installation path, compatibility with particular Newton versions, supported operating systems or GPUs, licensing terms, pricing, or production limits. It is consequently unclear whether developers can test Steel now, how broadly it applies across robot morphologies, or whether the reported result persists in contact-heavy tasks. The announcement establishes the product direction, not a validated purchasing or migration case.
Skill to build now
If your team trains robotics policies in simulation, create a small repeatable benchmark before changing solvers. Use one representative robot, one contact-heavy task, a fixed GPU configuration, and a fixed set of evaluation seeds. Record simulation steps per second alongside policy outcomes and failure modes. That makes it possible to test a future Steel release against the conditions that actually determine training quality, rather than comparing an external headline number with an unrelated workload.
Reader takeaway
Steel is a notable infrastructure announcement for robotics simulation: Skild AI and NVIDIA are presenting a GPU-accelerated rigid-body solver for Newton and reporting a 3.8 times performance result against PhysX. Its practical value remains unproven for any individual team until access, compatibility, benchmark conditions, and simulation fidelity can be tested on representative workloads.
Open question
What hardware, workload, and metric produced Skild AI's 3.8 times comparison with PhysX, and when will developers be able to evaluate Steel in Newton?