# MuJoCo: A Physics Engine for Articulated Structures, and How to Run It

> MuJoCo is a C physics engine for robotics, biomechanics and machine-learning research, maintained by Google DeepMind under Apache-2.0. This review covers what it solves, how to install it, and where it stops being the right tool.

**google-deepmind/mujoco** — Multi-Joint dynamics with Contact. A general purpose physics simulator.

- Repository: https://github.com/google-deepmind/mujoco
- Website: https://mujoco.org
- Stars: 15,360 · Forks: 1,787
- Language: C++
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-deepmind-mujoco

## What MuJoCo solves, and who it is built for

MuJoCo stands for Multi-Joint dynamics with Contact. That expansion is the whole design brief: simulate articulated bodies, the joints that connect them, and the contacts between them, quickly and accurately enough that a control or learning loop can run on top. The README names robotics, biomechanics, graphics and animation, and machine learning as the target areas, and describes the project as maintained by Google DeepMind.

The audience is researchers and developers, not end users. The README states that MuJoCo has a C API and that the runtime simulation module operates on low-level data structures preallocated by the built-in XML compiler. That sentence tells you what kind of tool this is. Models are described in XML, compiled once into a fixed memory layout, and then stepped repeatedly without allocation in the hot path. If you want a drag-and-drop scene editor, this is not it. If you want a stepper that a controller can call thousands of times per second, the preallocation is the point.

The repository also ships more than a core library. There are Python bindings, a Unity plug-in, JavaScript bindings with WebAssembly support, and MJX, a JAX branch of MuJoCo. The top-level layout reflects that: python/, mjx/, unity/, wasm/, plugin/, simulate/, sample/. The C library is the centre; everything else is an interface to it.

## How the XML compiler and the runtime step fit together

The data flow has two phases, and the split matters for performance. In the first phase, the built-in XML compiler reads a model file and produces preallocated low-level data structures. In the second, the runtime simulation module steps those structures forward. The README describes the runtime module as tuned to maximize performance, which is only possible because the first phase has already fixed the sizes of everything.

The practical consequence is that model structure is not something you mutate mid-simulation. Changing the kinematic tree means recompiling the model. The repository addresses this with a procedural path: the Model Editing tutorial shows how to create and edit models through the Python mjspec module, and dm_control includes PyMJCF for procedural manipulation of MuJoCo models. So the workflow is compile, step, and if the structure must change, rebuild the model rather than poke at the compiled data.

Around the simulator, the library exposes what the README calls a large number of utility functions for computing physics-related quantities. Interactive visualization is included as a native GUI rendered in OpenGL, which is what the simulate binary is. The Python side adds a multithreaded rollout module for running many trajectories, a nonlinear least-squares solver, and, through MJX, analytical gradients derived from the physics step for differentiable simulation.

## Installing MuJoCo and running a first simulation

The README gives two entry points. The recommended one for most users is the precompiled binaries from the GitHub releases page, built for Linux (x86-64 and AArch64), Windows (x86-64 only), and macOS (universal). Python users have a shorter path: the native bindings come pre-packaged with a copy of MuJoCo, so the library and the bindings arrive together.

Python must be 3.10 or newer. The install is a single command:

```bash
pip install mujoco
```

The README notes that pre-built Linux wheels target manylinux2014, so check your distribution against that baseline before assuming the wheel will load. Once installed, the README's own starting points are the tutorial notebooks, which run on Google Colab: the introductory tutorial teaches MuJoCo basics, and the Model Editing tutorial shows how to create and edit models procedurally. The LQR tutorial synthesizes a linear-quadratic controller balancing a humanoid on one leg, which is a useful health check because it fails loudly if the installation is wrong.

If you prefer a GUI over a notebook, the README points to the simulate binary, MuJoCo's native interactive viewer, with a linked screen capture and a Getting Started section of the documentation covering how to get it running. The remaining notebooks are rollout, which covers the multithreaded rollout module, least-squares, MJX, and differentiable physics.

## Where MuJoCo is the wrong choice

The README is explicit that the commit at the tip of the main branch may be unstable. That is an unusual admission to put in a README, and it should shape how you consume the project. If your workflow is to clone main and build, you have opted into a moving target. The versioning document notes that releases are intended for the first week of each month and that versioning standards changed to modified Semantic Versioning in 3.5.0, so the safe posture is to pin a numbered release rather than track the branch.

Platform coverage is narrower than the phrase prebuilt binaries suggests. Linux covers x86-64 and AArch64, macOS is universal, but Windows is x86-64 only. If you are on Windows on ARM, the releases page will not help you and you are in build-from-source territory, where the documentation is the only guide.

There is also a category mismatch worth naming. MuJoCo is a physics engine, not a task environment, not a training framework, and not a robot middleware layer. The README lists dm_control as a related environment stack rather than as part of MuJoCo, which is the honest framing: if you want ready-made benchmark tasks with reward functions, you are looking at the layer above this one. And if your requirement is a vendor SLA, a support phone number, or an indemnity clause, an Apache-2.0 research simulator maintained as an open repository is not that product, regardless of how good the contact solver is.

## How MJX differs from the C simulator, and what that means for GPU work

MJX is the most consequential fork in the project's own architecture. The README describes it as a branch of MuJoCo written in JAX, living in the mjx/ directory, with its own tutorial notebook. The C library steps preallocated structures on the CPU. MJX expresses the same physics in JAX, which means it can be vectorized across many environments and differentiated.

The differentiable physics tutorial is the clearest statement of why that matters: it trains locomotion policies using analytical gradients automatically derived from MuJoCo's physics step. In the C runtime, gradients are not part of the contract. In MJX they are, which changes what kinds of optimization you can run without finite differences.

The trade-off is that MJX is a separate code path with its own constraints, and the README presents it as a tutorial-level entry point rather than as a drop-in replacement for the C library. If your work is single-trajectory control at high rate, the C runtime and its preallocated structures are the natural fit. If your work is batched policy training, MJX is where the gradient lives. Choosing between them is a decision about your optimization loop, not about which is newer.

## Alternatives and the actual difference in approach

The related-searches data shows people comparing MuJoCo with Isaac Sim, so that comparison is worth stating precisely. Isaac Sim is built around GPU-accelerated simulation for robotics and synthetic data generation, with a USD-based scene description and a rendering pipeline aimed at photorealistic perception data. MuJoCo's scene description is XML compiled into preallocated structures, and its stated focus is fast, accurate simulation of articulated structures interacting with their environment, with visualization as a native OpenGL GUI. One is a platform for building simulated worlds and datasets; the other is a physics runtime you embed in a control or learning loop. If your problem is perception training data, the difference is decisive. If your problem is contact-rich articulated dynamics at high step rates, the XML compiler and preallocation are the reason to stay.

Within the same ecosystem, dm_control is the other comparison worth making, and the README is clear that it is a related environment stack rather than a competitor to the engine. It wraps MuJoCo with task environments and includes PyMJCF for procedural model manipulation. If you find yourself writing reward functions and episode resets around raw mj_step calls, that is the signal that you want the layer above, not a different simulator.

## Licence, release cadence and what upgrades cost

MuJoCo is licensed under Apache-2.0, and the repository carries a LICENSE file at the top level alongside SECURITY.md, CONTRIBUTING.md and STYLEGUIDE.md. Apache-2.0 is a permissive licence with an explicit patent grant and a notice requirement, which is the practical thing to plan for: if you redistribute MuJoCo or a derivative, you carry the licence and notice obligations with it. That is a statement about the licence text, not legal advice, and any product that embeds the engine should have counsel read the terms rather than a review.

The cadence is stated plainly in the README: releases are intended for the first week of each month. The recent release history is consistent with that, with 3.11.0, 3.12.0 and 3.13.0 arriving roughly a month apart. For an adopter, a monthly release train is a double-edged arrangement. Fixes and features arrive quickly, and the changelog in the latest branch gives visibility into what is coming. It also means that pinning is not optional if you value reproducibility, because the surface you build against moves on a schedule you do not control. The versioning document exists precisely because the project changed its standards at 3.5.0, which is a hint that version-to-version compatibility deserves a read before you upgrade a production dependency.

The last push to the repository was on 2026-09-21, so the codebase is being changed, not frozen. The upgrade cost to budget for is not the pip install; it is the revalidation of your models and controllers against each new release, plus the build-from-source path if you are on a platform the prebuilt binaries do not cover.

## Conclusion

MuJoCo fits teams that need fast, accurate simulation of articulated structures with contact, and Python users who want to start in minutes with pip install mujoco. It is the wrong tool if you need a closed-source commercial support contract, or if you refuse to pin a version, since the README warns that the tip of main may be unstable. Before adopting, verify three things: that the prebuilt binaries cover your platform (Linux x86-64 and AArch64, Windows x86-64 only, macOS universal), that your Python is 3.10 or newer, and that your deployment can carry the Apache-2.0 notice. Then pin a release from the releases page rather than tracking main.

## FAQ

### What is MuJoCo used for?

MuJoCo is a general purpose physics engine for fast and accurate simulation of articulated structures interacting with their environment. The README names robotics, biomechanics, graphics and animation, and machine learning as the areas it targets.

### Is MuJoCo free?

The repository is published under the Apache-2.0 licence, with a LICENSE file at the top level. That is a permissive open source licence, though anyone embedding it in a product should read the terms rather than rely on a summary.

### What language does MuJoCo use?

The primary language is C++, and the README states that MuJoCo has a C API intended for researchers and developers. Python bindings, JavaScript and WebAssembly bindings, a C# Unity plug-in, and the JAX-based MJX branch are also provided.

### How do you install MuJoCo with Python?

The native Python bindings come pre-packaged with a copy of MuJoCo and install from PyPI with pip install mujoco. Python 3.10 or newer is required, and pre-built Linux wheels target manylinux2014.

### How do you install the MuJoCo viewer?

The README points to the simulate binary, MuJoCo's native interactive viewer, and directs readers to the Getting Started section of the documentation for the steps. It also links a screen capture of simulate running.

## Sources

- [google-deepmind/mujoco on GitHub](https://github.com/google-deepmind/mujoco)
- [License: Apache-2.0](https://github.com/google-deepmind/mujoco/blob/main/LICENSE)
- [Project website](https://mujoco.org)
- [README](https://github.com/google-deepmind/mujoco/blob/main/README.md)
- [Releases](https://github.com/google-deepmind/mujoco/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-deepmind-mujoco