MyoSuite says Python 3.10 or later, and its manifest stops at 3.14

Two sections both called Using uv, and every command shown twice

The installation section offers four paths, and the duplication is the first thing you notice. There is a Using uv heading with a single line, `uv sync -p 3.10`. Then a Using conda section that creates a named environment and installs with pip. Then a second Using uv heading, this one marked recommended, which installs uv itself with a curl from astral.sh, creates a virtual environment, activates it with a Windows variant noted in the comment, and installs with `uv pip install -U myosuite`.

So the recommended path and the first path are two different mechanisms for the same outcome, and the page presents both without reconciling them. The conda route is the only one that uses pip rather than uv.

The rest of the page repeats the same pattern in every command block. A verification command appears twice, once as `uv run python -m myosuite.tests.test_myo` and once as `python -m myosuite.tests.test_myo`. The environment visualizer appears twice the same way. It is consistent, and it does double the length of the quick start for anyone who only needs one of the two.

The install check doubles as the environment listing

The verification step is described as returning a list of all the current environments as well as testing the installation:

uv run python -m myosuite.tests.test_myo

That makes one command serve two purposes. If it passes, the import chain works; if it prints, you also learn the suite's identifier for every task it currently ships. For a collection whose value is the number and naming of its environments, that is a sensible design, and it saves a reader from cross-referencing the task specification page before they can write a single line.

The environment identifier itself is the documentation. `myoElbowPose1D6MRandom-v0` names the body part, the task, a dimensionality marker, a muscle count, a randomization variant and a version suffix. Since the suite is used as a gym API, the identifier is the API, and it is worth reading before picking a task.

The generic loop is the standard one, with `gym.make`, a reset, a thousand steps of random actions and `mj_render` per step, then `env.close()`. The page points at Colab notebooks so the same code runs without a local install, which is how most quick evaluations happen.

On macOS the viewer has to be launched with mjpython

One platform note is specific enough to break a first run, and it concerns visualisation rather than the simulation itself. On macOS the project moved to MuJoCo's native `launch_passive`, which requires the script to be run under `mjpython` rather than `python`:

mjpython -m myosuite.utils.examine_env --env_name myoElbowPose1D6MRandom-v0

So on macOS the same command works with `python` for the test module and fails for the viewer unless you swap the interpreter. The reason is the passive viewer mechanism, which is a different display path from offscreen rendering, and the page does not explain the mechanics, only the requirement.

It also does not list which platforms the other two interpreters are for, so the reasonable reading is that Windows and Linux use `python` and macOS uses `mjpython`. Anyone cross-platform should expect one special case and no documented fallback.

This is also the kind of detail that a single line in a requirements list would have hidden. Keeping it in the installation section is the right call.

Adding a model is a prompt-driven init step, then a sim to inspect

New models enter the suite through a generator rather than by dropping a file into a directory. The page says you can take advantage of the latest MyoSkeleton once it is added, following the instructions the init command prints:

uv run myoapi_init

A module entry point exists for the other toolchain as well, `python -m myosuite_init`. So adding a model is an interactive step, which is a deliberate choice for a suite where a musculoskeletal model needs consistent muscle definitions, actuators and wrapping.

Inspecting one is a separate command that takes a path into the model tree:

uv run python -m myosuite.utils.examine_sim -s myosuite/simhive/myo_model/myoskeleton/myoskeleton.xml

The path tells you where the assets live: a simulation hive directory, a model directory per model family, and then XML. The XML extension is the practical detail, because it means models are edited as MuJoCo source rather than through a builder, and it means the version control history of a model is a diff of its XML.

That combination, a generator for the initial skeleton and XML for everything after, is the shape most biomechanics suites converge on.

The accelerated extra is marked unavailable on Windows

The optional dependency groups carry environment markers that do real work. An `examples` extra depends on Python 3.10 or later, and the `mjx` extra is more interesting: it pulls mujoco, mujoco-mjx with warp, jax and jaxlib at 0.4.20 or later, brax at 0.10.0 or later and flax at 0.8.0 or later, and every one of those entries carries `sys_platform != 'win32'`.

So the GPU-accelerated path is explicitly not available on Windows, stated in the manifest rather than in prose. That is a reasonable engineering decision, since the MJX and Warp stack is not reliably available there, but it means the accelerated route is Linux and macOS only.

The dependency sourcing is also explicit. The manifest declares a private index named `nvidia` pointing at pypi.nvidia.com with `explicit = true`, and binds `warp-lang` to it. That is how the warp dependency inside `mujoco-mjx[warp]` resolves, and it means the accelerated install reaches outside PyPI by design.

The base dependencies are modest by comparison: gymnasium capped below 1.3, MuJoCo pinned to a 3.6 minor range, h5py, numpy, Pillow at a high floor, imageio with the ffmpeg extra, click, termcolor, flatten_dict, pink-noise-rl, packaging, and gitpython. gitpython as a runtime dependency is the one that looks odd, and it is plausibly there because the model registry needs to locate the suite's own assets.

The BibTeX entry splits the first author's name

The citation block is a BibTeX entry for the arXiv preprint, with the paper title, a DOI, the repository URL and the year, and the author field is where it goes wrong. It reads `Vittorio, Caggiano AND Huawei, Wang AND Guillaume, Durandau AND Massimo, Sartori AND Vikash, Kumar`, with the first pair reversed.

BibTeX treats a comma inside an author name as a last-name and first-name separator. So the first author is parsed as last name Vittorio with first name Caggiano, which renders as Caggiano Vittorio, when the copyright header at the top of the same page lists the two authors as Vikash Kumar and Vittorio Caggiano.

The other entries use the same surname-first order and are fine, because Wang, Durandau, Sartori and Kumar really are surnames. The first entry is the only one where a first name precedes the comma.

It is a small thing in a page that otherwise documents its own versions carefully, and it is exactly the kind of error that gets copied into a bibliography and then propagated. Worth fixing before you cite it.

Three URLs for one project, and a version floor stated twice

The metadata points at a Google Sites page for the homepage, the badges and links point at a myosuite domain, and the documentation lives on readthedocs. Three addresses for one project, each plausible, none obviously canonical from a single page.

The version floor is stated with more precision than the prose. The README says Python 3.10 or later. The manifest requires `>=3.10,<3.14`, and the classifiers list 3.10 through 3.13. So 3.14 satisfies the requirement but is not classified as supported, which is a normal way to permit a version before it is declared tested.

Maintenance is steady rather than rapid. Three tags are visible, 2.11.5 from 2025-10-01, 2.11.6 from 2025-11-04 and 2.12.0 from 2026-04-23, while the last push is dated 2026-10-02 and the repository is not archived. Patch releases cluster and minor versions arrive on their own schedule, which is what a research suite with external model contributions tends to look like.

The suite also carries pre-trained policies in its agents directory for testing, Colab notebooks tied to two conference tutorials, and a task specification page, so evaluation does not have to start from a blank policy.

Editorial conclusion

MyoSuite fits a reinforcement learning researcher who needs biomechanically plausible contact-rich control tasks rather than abstract physics, and who wants the standard gym interface so existing tooling applies. Verify four things first: your Python version, because the manifest allows 3.10 up to but not including 3.14 while the classifiers stop at 3.13; whether you want the MJX path, which carries a platform marker that excludes Windows; that you use mjpython rather than python for the passive viewer on macOS; and whether you install from source, because the clone is recursive and the suite depends on that. Apache-2.0 licensed, version 2.12.0, with the last push dated 2026-10-02.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. MyoHub/myosuite on GitHub
3. Project website
4. README
5. Releases