The official training stack uses mjlab / MuJoCo Warp with PPO and exports policies to ONNX. Its documented local training path requires a CUDA GPU; training and playing a policy are different tasks.
A policy is an action rule
During inference, the policy receives observations and produces actions. During training, its parameters are adjusted through repeated experience. A reward gives the optimization process a signal about what you want. The important design problem is whether that signal represents your real goal. Rewarding one convenient measurement can accidentally encourage behavior that looks successful numerically but misses the intended task.
A useful experiment has a baseline
Choose an existing documented task before inventing a new one. Run a small check, confirm that the environment and viewer work, and record a baseline. Change one meaningful part of the setup at a time. Write down what you expect to improve and what could get worse. This gives you an explanation to test rather than a collection of settings to adjust until something looks interesting.
Why simulation is not the finish line
Real contact, delay and actuator behavior can differ from the model. Domain randomization varies conditions during training so a policy does not depend on one overly specific setup. It is a way to address uncertainty, not a guarantee that transfer succeeds. Evaluate repeated attempts and record failures rather than selecting only the best clip.
Keep export and deployment in the documented path
The official README provides the current training, viewing and export commands. Follow that exporter instead of inventing a conversion, then rehearse the result before physical testing. Keep the task, source revision and checkpoint together in your experiment notes. If you use cloud training, review its current resource and billing settings first; this website does not start jobs or claim that training is free.
Go to the source
Reviewed September 7, 2026. Prices, availability and software can change.