Newton is a robotics engine built above Warp and MuJoCo Warp
Newton provides the model, solver, collision, import, and viewing layers needed to build physics simulations from Python. NVIDIA Warp supplies the CPU and GPU kernel foundation, while MuJoCo Warp is the primary backend. OpenUSD, URDF, and MJCF support make it relevant to teams whose assets already live in robotics and digital-content pipelines.
Its closest fit is repeated simulation rather than a single rigid-body demo. The installation guide shows a robot template replicated across 1,024 worlds and stepped together. That design serves reinforcement learning, batched control, and parameter studies where parallel worlds can keep a GPU busy. A basic sphere and ground-plane example still runs with required dependencies only, so researchers can learn the model and stepping API before adding MuJoCo, importers, viewers, or policy runtimes.
The base install used 520 MB before optional extras
Our sandbox cloned commit 41a5392 into a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. Installing 36 Python packages took 36 seconds and used 520 MB. The build completed in 5 seconds. Pip-audit reported 0 known vulnerabilities in the installed dependencies. This is a manageable setup result for scientific software, but the disk footprint is already substantial before the examples, PyTorch, ONNX, USD import, and visualization extras enter the environment.
The 31.9 MB checkout contained 1,181 files and roughly 538,429 source lines. We found 18 CI workflow files, no Dockerfile, and no tests directory at the repository root. Those numbers describe a large project with visible automation, but they do not prove that a particular solver works on a buyer's device. Physics correctness depends on the model, time step, contact settings, precision, and backend as well as repository hygiene.
What happened when we ran it
Our run installed Newton in 36 seconds and built it successfully in 5 seconds. The harness found no test script or target, so it skipped tests. We did not execute a pendulum, initialize CUDA, import a robot, compare trajectories, or render a scene. Calling this a passing test run would be inaccurate; the confirmed result is limited to dependency resolution, package build, disk use, and the 0-vulnerability audit.
The distinction matters because Newton does have CI and public coverage signals, yet our generic command could not reach them through a declared target. A local evaluation should run the project's supported development command, then add a small scenario from the intended workload. Record whether contacts remain stable, resets reproduce expected state, imported masses and joints match the source asset, and CPU and GPU paths agree within tolerances chosen by the team.
GPU acceleration requires NVIDIA hardware and current drivers
Newton supports Linux on x86-64 and ARM64, Windows on x86-64, and macOS on CPU. The accelerated path requires an NVIDIA GPU with compute capability 5.0 or newer, which includes Maxwell-generation cards, plus driver 545 or later for CUDA 12. Driver 550 or later and CUDA 12.4 or newer are recommended in the installation guide. Warp bundles its runtime, so users do not need a separate local CUDA Toolkit.
Mac owners can still run Newton, but the documentation promises no macOS GPU acceleration. Linux ARM64 has another boundary: the importer extra depends on usd-exchange wheels requiring GLIBC 2.35 or newer. RHEL 9 with GLIBC 2.34 can install the base package but not those published extras. On Jetson Thor and DGX Spark, the examples extra also needs 6 named X11 and OpenGL development packages to build its viewer dependency.
Optional extras keep the base small while multiplying compatibility paths
Only Warp is mandatory. The sim extra adds MuJoCo, importers covers assets and mesh processing, onnx supports neural actuators and policies, and examples pulls simulation, import, visualization, and ONNX pieces together. Separate CUDA 12 and CUDA 13 PyTorch extras serve workflows that need Torch policies or training. This organization lets a headless solver avoid notebook and viewer dependencies.
It also means pip install newton is not the whole setup for most research projects. Choose the solver and asset format first, then install the narrowest extra that supports them. Confirm wheel availability for the actual Python and architecture. Python 3.10 is accepted, but the docs recommend 3.11 or newer and warn that imgui_bundle can cause example-install problems on 3.10.
Minor releases may break code, and experimental solvers may change sooner
Newton uses major, minor, and micro versions, but its compatibility guide explicitly allows deprecations, breaking changes, and removals in minor releases. A deprecated feature remains for at least one full minor cycle. Only the latest minor release line receives active maintenance, and fixes are not normally backported. Version v1.5.0, published August 11, 2026, removed earlier aliases and helpers while adding new deprecations and upgrade instructions.
The same release labels vectorized joint control and Kamino DVI dynamics experimental. Its policy says experimental APIs, behavior, defaults, and supported cases may change without notice. GitHub showed 399 combined open issues and pull requests and a last push on August 26, including active work on contacts, solver updates, viewers, and USD behavior. Pinning v1.5 is necessary, but validation against the next minor release is part of owning this dependency.
The right decision comes from one representative robot
Newton combines credible institutional backing, Apache-2.0 licensing, extensive examples, and active engineering around difficult simulation problems. Those are good reasons to test it. They do not answer whether a particular gripper, cable, terrain, or contact-rich robot behaves well enough for training or control. The 5-second build is only the entrance to that evaluation.
Use a known asset and one task with observable outcomes. Compare imported joint limits, mass, collision filtering, actuator behavior, and reset determinism with a trusted reference. Then scale world count and move to the intended GPU. If Newton's parallelism and extensibility reduce real experiment time, its 520 MB base environment is easy to justify. If the workload is CPU-only or already stable in MuJoCo, the extra abstraction may buy little.

