MindAct: a training and evaluation toolkit for embodied policies on LeRobot and LIBERO

What MindAct is for, and what it is not

MindAct targets a narrow problem: keeping imitation-learning experiments on desktop manipulation tasks reproducible. The README describes it as "a reproducible training and evaluation framework for imitation learning policies on desktop manipulation tasks" that integrates LeRobot datasets and policies with LIBERO simulation benchmarks, plus experiment provenance tracking and standardized evaluation protocols. The intended user is a researcher or engineer who already works with those two ecosystems and wants the glue, the config format and the artifact layout handled for them.

The repository history matters here, because the name is misleading. This project was originally MindNLP, a MindSpore-based NLP library. The README states that MindAct "represents a complete pivot to embodied AI with PyTorch and Hugging Face as the native stack", and that the legacy codebase is preserved on the legacy branch. Anyone arriving from an old MindNLP link, or from a search for MindSpore NLP tooling, will not find that library on master. The version string in pyproject.toml is 0.1.0, and the README calls this "the initial skeleton release".

Protocols, lazy extras and a manifest-tracked config

The architecture is built on three adapter interfaces, one each for datasets, policies and environments. The README calls this a "protocol-based architecture" with "minimal adapter interfaces", and the pyproject classifiers mark the project as Alpha. The concrete dependencies are deliberately thin: numpy and pyyaml are the only required packages. Everything heavier arrives through extras, so importing the config layer does not drag torch in.

Configuration is a single YAML document per experiment. The README's example config carries a name, a seed, an output_dir, and then dataset, policy, environment, training and evaluation blocks. The dataset block points at a Hugging Face repo id such as lerobot/aloha_sim_insertion_human with an optional revision and a split. The environment block names a task_suite such as libero_spatial and an optional list of task_ids. Training and evaluation hold plain scalars: steps, batch_size, learning_rate, log_every, checkpoint_every, episodes, max_steps, record_video.

Provenance is the part worth noting. The README says configurations are tracked with manifests, and that artifacts land in a conventional directory structure for checkpoints, logs and results. That is a design decision with a cost: the config is the unit of record, so anything you change outside the YAML after a run is not captured. The README does not document a rollback path for a manifest, and it does not describe how manifests are compared across runs.

Installing MindAct and running the fake-runner smoke path

Installation is editable-only in the README's examples, and Python must be 3.12 or newer per pyproject.toml. The base install gives you the configuration system and the CLI and nothing else. Pick the extras that match what you actually need:

pip install -e .
pip install -e ".[torch]"
pip install -e ".[lerobot]"
pip install -e ".[libero]"
pip install -e ".[torch,lerobot,libero]"

The first thing to run is not training but validation. The README ships a baseline config at configs/experiments/libero-baseline.yaml, and config-check parses and validates it without touching a dataset or a simulator:

mindact config-check configs/experiments/libero-baseline.yaml

If the YAML is well formed you get a clean exit and no adapter is loaded. The second command exercises the whole evaluation lifecycle using built-in test doubles rather than real models:

mindact eval configs/experiments/libero-baseline.yaml \
  --runner fake \
  --run-id smoke-run \
  --output-dir outputs \
  --episodes 2

Read the README's own warning before you interpret the output. It states that the fake runner "is a contract smoke test, not a benchmark result", and that real LeRobot policies and LIBERO environments "arrive with their adapter implementations". So a successful run tells you the config, the CLI wiring and the artifact directory work. It tells you nothing about policy quality. The mindact entry point itself is declared in pyproject.toml as mindact.cli.main:main.

Where MindAct will let you down

The largest limitation is stated plainly in the README: the real adapters are not there yet. There is no documented path in the README for pointing the eval command at an actual LeRobot policy or an actual LIBERO environment. If your goal is to train an ACT policy on a LeRobot dataset and measure it in LIBERO this week, this repository does not yet do that for you, and the fake runner will not close the gap.

The second limitation is version discipline. The extras pin torch to >=2.7,<2.12, lerobot to >=0.6.1,<0.7 and libero to >=0.1.1,<0.2. Those upper bounds are tight for a fast-moving field, and nothing in the README explains how they are revised. numpy is capped below 2.3 as well. A pre-existing environment that already resolved a newer torch will not install cleanly alongside these extras.

The third is scope. This is a desktop manipulation framework. It assumes LIBERO task suites and LeRobot-format data. If you work on language modelling, vision-language models or diffusion training, the repository's topics list will bring you here and the code will not help you; the pivot away from that territory is the whole point of the rewrite. The README also does not document rollback, resume-from-checkpoint behaviour, or what happens when an evaluation run is interrupted mid-episode.

MindAct against a plain LeRobot plus LIBERO setup

The obvious alternative is to use LeRobot and LIBERO directly, wiring them together in your own scripts. That is what most people do today, and it is not unreasonable: both projects already ship their own training entry points and evaluation harnesses, and neither requires a third layer.

The difference is in what MindAct adds on top. Direct integration means your experiment definition lives in Python code, and reproducing a run six weeks later means recovering the exact script plus the exact environment. MindAct moves that definition into a YAML file with a fixed schema and attaches a manifest to each run. The trade is real: you give up the freedom to express an unusual training loop in ordinary Python, and you take on a dependency whose adapter layer is still a skeleton. In exchange you get a config that can be validated before anything heavy loads, and an artifact directory convention that checkpoints, logs and results all follow.

For a single exploratory experiment, the direct route is faster. For a lab that needs to compare many policy and task-suite combinations under a consistent protocol, the config-plus-manifest model is the reason to accept the immaturity.

Maintenance, releases and the Apache-2.0 terms

The last push to the default branch was on 2026-09-01, so the repository is not dormant, though the release cadence is slow: v0.5.1 on 2025-11-05, v0.5.0 two days earlier, and v0.4.1 back on 2025-04-10. Note the mismatch worth checking before you pin anything: the release tags are in the 0.5.x line while pyproject.toml on master declares version 0.1.0. The README's "Project Status" section describes v0.1 as the initial skeleton and places unified reproducible training and evaluation in "Phase B (current)", with trajectory quality diagnostics in "Phase A (future)". Those labels do not match the release numbering, and the README does not explain the discrepancy.

Upgrade cost is mostly the extras. Because torch, lerobot and libero are bounded above, moving to a newer release of any of them may require a MindAct release that widens the constraint, and the README does not describe a compatibility policy. The base install, which is numpy plus pyyaml, is close to free to upgrade.

Licensing is Apache-2.0, declared both in the README and in pyproject.toml via license = "Apache-2.0" with license-files = ["LICENSE", "NOTICE"]. The presence of a NOTICE file means there are attribution obligations to carry forward if you redistribute. That is a statement about what the repository declares, not legal advice; read LICENSE and NOTICE yourself.

Editorial conclusion

Adopt MindAct only if you are comfortable working against a v0.1 skeleton whose real LeRobot and LIBERO adapters are still listed as future work, and if your Python is 3.12 or 3.13. Do not adopt it if you need a working imitation-learning pipeline today, or if you are looking for the MindSpore NLP library this repository used to be; that code sits on the legacy branch. Before committing, run mindact config-check against your own YAML, then mindact eval --runner fake to confirm the lifecycle wiring, and read src/ and docs/ to see whether the adapter interfaces match the policy and environment you actually intend to plug in.

Frequently asked questions

Official sources

1. candle-org/MindAct on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases