MyoSuite: Musculoskeletal Motor Control Environments on MuJoCo
MyoSuite is a collection of environments/tasks to be solved by musculoskeletal models simulated with the MuJoCo physics engine and wrapped in the OpenAI gym API.
At a glance
- What is it?
- MyoSuite wraps biomechanical models of the human arm and hand in the OpenAI gym API so reinforcement learning agents can be trained on physiologically structured motor tasks. The catch is that the simulation fidelity is the point, and that fidelity costs compute.
- Who is it for?
- Adopt MyoSuite if your research question is about motor control under musculotendon dynamics and you can absorb the simulation cost, for example training on myoElbowPose1D6MRandom-v0 before scaling to hand tasks. Do not adopt it if you need a fast generic locomotion benchmark or a rigid-body contact stack, since the musculoskeletal model is the whole value proposition.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap MyoSuite Fills Between Rigid-Body RL and Biomechanics
Most reinforcement learning benchmarks for control treat the agent as a set of rigid links driven by idealised torque actuators. That abstraction is useful for locomotion and manipulation, but it removes the thing biomechanics researchers actually care about: muscle activation dynamics, tendon compliance, and the redundancy that comes from having more muscles than degrees of freedom. MyoSuite is aimed at that gap. The README describes it as a collection of musculoskeletal environments and tasks simulated with MuJoCo and wrapped in the OpenAI gym API, with the stated purpose of enabling machine learning on biomechanic control problems. The audience is therefore narrow and specific: motor control researchers, biomechanists, and RL practitioners who need their agent to output muscle excitations rather than joint torques. If you are building a warehouse robot, this is the wrong repository. If you are studying how the nervous system might solve the redundancy problem in the arm, the model structure is the entire reason to be here.
How the MuJoCo Model, the Gym Wrapper and the Task Registry Fit Together
The architecture has three layers. At the bottom is MuJoCo, which does the physics. Above that sit the musculoskeletal models, and the repository layout shows these live under myosuite/simhive/myo_model, with the myoskeleton model referenced at myosuite/simhive/myo_model/myoskeleton/myoskeleton.xml. Above the models sit the task definitions, which are exposed as gym environments with registered names such as myoElbowPose1D6MRandom-v0. The interface layer is a re-exported gym module: the README example imports gym from myosuite.utils rather than from gym directly, which means the environment construction path is mediated by the project. Data flow is conventional for a gym environment. You call gym.make with a registered task name, call reset, then loop over step with actions sampled from the action space. The README example uses env.action_space.sample() to drive the loop, and calls env.mj_render() each iteration to visualise. Because the action space is defined by the musculoskeletal model, the actions are muscle-level rather than joint-level, which is the practical difference from a standard MuJoCo gym task. The naming convention in myoElbowPose1D6MRandom-v0 is worth reading: the suffix indicates a pose task with a randomised target, which is a standard technique for preventing an agent from memorising a single goal.
Installing MyoSuite with uv, conda, and the mjpython Constraint on macOS
The README requires Python 3.10 or later. Two package managers are documented. With uv, the project supports a lockfile-style sync: uv sync -p 3.10. With conda, the documented path is conda create --name myosuite python=3.10, then conda activate myosuite, then pip install -U myosuite. The README also gives a plain uv path using uv venv and uv pip install -U myosuite, and marks that section as recommended for faster installation, which is slightly confusing because the uv sync path appears first. For source installs, the command is git clone --recursive https://github.com/myohub/myosuite.git followed by uv pip install -e . The --recursive flag matters because the simulation assets are a submodule; a non-recursive clone will leave simhive empty and the models will not resolve. Verification is a single command: python -m myosuite.tests.test_myo, or uv run python -m myosuite.tests.test_myo. The README states this also prints the list of current environments, which makes it the fastest way to confirm your install before writing training code. Visualisation uses python -m myosuite.utils.examine_env --env_name myoElbowPose1D6MRandom-v0. On macOS the README notes the project moved to MuJoCo's native launch_passive, which requires the script to run under mjpython instead of python. That is a real friction point for anyone scripting around the viewer. There is also an optional myoskeleton model: after running uv run myoapi_init or python -m myosuite_init and following the prompts, you can inspect it with python -m myosuite.utils.examine_sim -s myosuite/simhive/myo_model/myoskeleton/myoskeleton.xml.
Where MyoSuite Gets Expensive and Where It Is the Wrong Tool
The limitation follows directly from the design. Musculotendon models add state and stiffness that rigid-body models do not have, so each simulation step is more expensive, and the action space is higher dimensional because you are commanding muscles rather than joints. The README does not publish step-rate numbers, and I have not run the suite, so I cannot give you a throughput figure; treat any claim about steps per second as something you must measure on your own hardware before committing to a training budget. The second limitation is scope. The task list is musculoskeletal motor control, and the environments named in the README are arm and hand tasks such as myoElbowPose1D6MRandom-v0. If your problem is legged locomotion, whole-body manipulation with rigid contacts, or anything that benefits from a simplified actuator model, the musculoskeletal layer is pure overhead. There is no reason to pay for tendon dynamics if your research question does not involve them. A third practical issue is the macOS viewer constraint: requiring mjpython means notebook-based or scripted visualisation on a Mac needs a different entry point than on Linux, and the Colab notebooks linked from the README sidestep this by running on Linux hosts.
How MyoSuite Differs from Gymnasium and MuJoCo Menagerie
The obvious alternative for a gym-style MuJoCo environment is Gymnasium with its own MuJoCo environments, or a rigid-body model collection such as MuJoCo Menagerie. The difference is not the API, since MyoSuite deliberately mimics the gym interface, but the model. Gymnasium's MuJoCo tasks use simplified bodies with torque or position actuators; MyoSuite uses musculoskeletal models with muscle actuators. That changes the action semantics, the observation content, and the control problem itself. A policy trained on a Gymnasium Hopper task learns to output joint torques; a policy trained on a MyoSuite arm task learns to output muscle excitations, and that policy is not transferable to the other setting. The second difference is asset provenance. MyoSuite ships its own model hive under simhive, and the optional myoskeleton model is delivered through a separate initialisation step (myoapi_init or python -m myosuite_init) rather than being present in a default clone. If you need a large library of rigid-body robots for manipulation research, Menagerie is the more direct fit. If you need muscle-level control with a gym-shaped API, MyoSuite is addressing a smaller and more specialised problem.
Release Cadence, Submodule Assets and Maintenance Cost
The release history shows v2.11.5 in October 2025, v2.11.6 in November 2025, and v2.12.0 in April 2026, with the last push to the default branch in September 2026. That is a steady minor-version cadence rather than a frozen project, but it also means version pins matter: a minor bump in a suite like this can change environment registration names, model files, or default parameters. For reproducible research you should pin the version in your environment file rather than tracking main. The submodule arrangement is the main maintenance cost. Because the simulation assets live in a separate repository pulled with git clone --recursive, updating MyoSuite without updating the submodule can leave you with code expecting models that are not present, and the myoskeleton model adds a second out-of-band step through myoapi_init. Budget for re-running python -m myosuite.tests.test_myo after every upgrade to confirm the environment list still matches what your training scripts reference. On licensing, MyoSuite is Apache-2.0, which is a permissive licence that permits commercial use and modification with attribution and notice requirements. That covers the code in this repository. It does not automatically tell you the provenance or terms of every model asset in the submodule, and I have no material here describing those terms, so if you intend to redistribute the models or ship them inside a product, check the submodule's own licensing before you do. Nothing here is legal advice.
Who Should Install MyoSuite and What to Check Before Training
The decision comes down to whether muscle-level control is your research question or an incidental detail. If it is your question, MyoSuite gives you a gym-shaped interface over musculoskeletal MuJoCo models, a documented install path through uv or conda, a verification command that also enumerates environments, and a viewer utility for inspecting a single task. The Colab tutorials linked from the README cover loading models, training, and visualising outcomes, and the myosuite/agents directory holds baseline policies you can compare against. If muscle-level control is not your question, the added simulation cost and higher-dimensional action space are a tax with no return, and a rigid-body benchmark will get you to a result faster. Before you commit compute, do four things: confirm Python is 3.10 or later, clone with --recursive so simhive is populated, run python -m myosuite.tests.test_myo and check the printed environment list against the task names in your scripts, and measure your own step throughput on the specific environment you plan to train on, because the README does not give you one. If you are on macOS and plan to watch rollouts, confirm mjpython works in your environment first, since that is a different entry point from the one used on Linux.
Editorial conclusion
Adopt MyoSuite if your research question is about motor control under musculotendon dynamics and you can absorb the simulation cost, for example training on myoElbowPose1D6MRandom-v0 before scaling to hand tasks. Do not adopt it if you need a fast generic locomotion benchmark or a rigid-body contact stack, since the musculoskeletal model is the whole value proposition. Verify first that your Python is 3.10 or later, that the recursive clone pulled the simhive submodule, and that python -m myosuite.tests.test_myo lists the environments you intend to use before you write any training code.
Community notes