Newton review: check the hardware path before evaluating scale
Newton's GPU requirements depend on the Warp wheel you install. That distinction matters before a robotics team invests time importing assets or comparing solvers. Our recorded setup run provides limited installation evidence; it does not show how fast or accurately Newton simulates a robot.
The Newton README describes a physics simulation engine built on NVIDIA Warp, with MuJoCo Warp as its primary backend. It targets roboticists and simulation researchers and emphasizes OpenUSD, differentiability, and extensibility. The project also extends Warp's deprecated warp.sim module. These descriptions explain its intended role, but they are not findings from our sandbox.
What our October 9 run recorded
Our recorded run began at 2026-10-09T03:37:49.168Z and used commit f6b5f4f2c2816cf609172cb53b43254b2dc51baf. The sandbox configuration specified 3 CPUs, 8 GB of memory, and image ghcr.io/astral-sh/uv:python3.12-bookworm. The retained install output identifies Python 3.12.12.
The harness marked its install step successful in 49 seconds and its build step successful in 4 seconds. Its dependency summary recorded 133 packages and 2,172 MB. The supplied record does not identify the full commands or selected extras, so that footprint cannot be described as Newton's base-package requirement. An empty retained build tail also limits what we can conclude about the work performed by that step.
Tests were skipped with reason "no script". This describes the harness's detection result, not an absence of project tests or a failed test suite. The compatibility guide separately describes upstream testing. No supplied workload output establishes a successful package import, installed executable, CUDA initialization, rendered scene, robot trajectory, or throughput result.
The checkout summary recorded 1,388 files, approximately 634,775 source lines, 36.4 MB, and 18 CI workflows. Its detector reported no Dockerfile, Compose file, or root tests directory. These are recorded parser summaries, not an exhaustive inventory of project coverage.
Pip-audit's recorded advisory total was 0. Audit coverage is unknown: the supplied record does not establish which dependencies were inspected. Neither that total nor successful setup steps prove that the software is safe or that a simulation is correct.
Fresh installs and the CUDA 12 path have different requirements
The current installation guide says fresh installs select Warp 1.18. Its standard wheel uses CUDA 13.4 and requires an NVIDIA Turing GPU with compute capability 7.5 or newer and an R580-or-newer driver. A local CUDA Toolkit is not needed for standard Warp wheels. macOS runs on CPU only.
The guide documents warp-lang==1.17.0 as a separate path for R545-R579 drivers or older supported GPUs. On x86-64, the standard Warp 1.17 wheel supports compute capability 5.2 or newer. Linux ARM64 has a narrower boundary: that wheel omits sm_52, sm_60, sm_61, and sm_70 targets, so the pin alone does not enable those GPUs. They require a Warp wheel built with an earlier CUDA 12 toolkit.
The compatibility guide describes CUDA 12 support as deprecated in Newton 1.7, while retaining it throughout the 1.7 release line with a CUDA 12-built Warp wheel. This is current documentation, not proof of the dependency versions or GPU behavior in our October 9 run. Keep the evaluated Warp pin in application requirements or constraints rather than assuming a later install will resolve identically.
Choose extras for the workload
Newton's only mandatory dependency is NVIDIA Warp. The documented base command remains pip install newton. The sim extra adds simulation dependencies including MuJoCo; importers adds asset and mesh-processing dependencies; onnx supports neural actuators and policy examples. The examples extra includes simulation, importers, ONNX, and visualization dependencies. PyTorch, notebooks, development, remeshing, and documentation have separate extras.
The installation guide requires Python 3.10 or newer, recommends 3.11 or newer, and warns that Python 3.10 users may encounter imgui_bundle installation issues. On Linux, importers and remesh extras, including extras that pull them in, require GLIBC 2.35 or newer. This restriction is not limited to ARM64. ARM64 examples also require the documented X11 and OpenGL development libraries to build imgui_bundle from source.
The guide includes a base-dependency sphere example and a separate MuJoCo solver workflow that replicates a robot template across 1,024 worlds. That is a documented usage example, not a workload we ran or a measured scaling result. Choose the required solver and asset format first, then install the matching extras.
Plan for minor-release changes
The compatibility policy allows deprecations, breaking changes, and removals in minor releases. Deprecated features remain for at least one full minor release cycle. Only the newest minor release line is actively maintained, and fixes are not backported by default. Experimental features may change API, behavior, defaults, or supported use cases without prior notice.
The retained v1.5.0 release provides a concrete migration example: it removed joint_target_pos and joint_target_vel aliases and directs users to joint_target_q and joint_target_qd. It also labels vectorized joint control and Kamino DVI dynamics experimental. This historical release is not presented as the current supported line or the version established by our run.
How the ratings work
These are editorial evidence ratings, not benchmark results. The scale is 1 for a documented serious obstacle, 2 for substantial documented constraints, 3 for a usable evaluation path with material unknowns, 4 for clear supporting evidence within the assessed scope, and 5 for broad corroboration with few material unknowns. Each category uses different evidence: setup considers our recorded steps and documented requirements; documentation considers the supplied guides; community considers visible contribution and support routes; maturity considers compatibility and maintenance commitments. Unknown adoption and compatibility do not earn a high score.
Setup receives 3/5 because the harness recorded successful steps but did not retain enough command detail to establish the installed feature set or runtime behavior. Documentation receives 4/5 for explicit wheel requirements, extras, platform restrictions, and migration policy. Community receives 3/5 because the README documents contribution and discussion routes, while the supplied evidence does not establish response quality or adoption. Maturity receives 3/5 because the compatibility policy defines maintenance and deprecation rules while permitting minor-release breaks and experimental behavior changes.
Evaluate one robot before increasing world count
Start with a known asset and observable outcomes. Check imported masses, joint limits, collision filtering, actuator behavior, and resets against a reference you trust. Run the project's documented development tests separately from that workload. Then evaluate the intended GPU and world count, recording the installed Newton and Warp versions, driver, solver settings, timings, and tolerances.
MuJoCo is a relevant direct-engine alternative: its primary source documents articulated-structure simulation, a C API, Python bindings, and native visualization. Warp is a lower-level option for developers who want to write CPU or GPU kernels themselves; it is also Newton's foundation. Neither alternative was benchmarked in our run.
Choose Newton when its documented abstractions fit the research task and your own validation supports the decision. The available record supports a limited setup observation, not a claim of simulation speed, accuracy, or security.