Xiaomi-Robotics-1 claims four simulation wins and ships three checkpoints

The largest benchmark gain ships no checkpoint

Four simulation benchmarks are reported, and three of them come with a fine-tuned checkpoint and an evaluation guide inside this repository: RoboCasa points at `eval_robocasa/README.md`, RoboCasa365 at `eval_robocasa365/README.md` and VLABench at `eval_vlabench/README.md`, each paired with a named checkpoint on Hugging Face. The fourth row is different. For RoboDojo the checkpoint cell is empty and the guide column points outward to the benchmark's own documentation instead, and there is no `eval_robodojo` directory in the repository root.

That row is the headline number. RoboDojo shows 13.93 percent against 8.80 percent for the runner-up, a relative gain of 58.3 percent, more than twice the next largest relative figure in the table. So the single result that carries the most rhetorical weight, the one a reader is most likely to quote, is also the one that cannot be reproduced from what is published here. The three reproducible benchmarks are the three with the smaller relative gains: RoboCasa365 at 23.2 percent, VLABench at 11.1 percent and RoboCasa at 2.6 percent. Nothing in the README says why RoboDojo was left out, and a missing row in a table of otherwise uniform rows is the kind of gap that deserves an explicit sentence rather than a dash.

One adaptation row drops as demonstrations increase

The real world table compares XR-1 against a named baseline, π0.5, across four tasks at two demonstration budgets. Overall, XR-1 records 75 percent against 40 percent under ten hours per task, and 85 percent against 53 percent under forty hours. Two cells are worth reading closely. Printer Refilling goes from 70 percent for XR-1 at under ten hours down to 60 percent at under forty hours, the only row where more demonstration data produces a lower success rate, and π0.5 sits at 20 percent in both columns. Box Packing reaches 100 percent for XR-1 at under forty hours and π0.5 also reaches 100 percent there, so the claim of substantially outperforming the baseline holds in aggregate but not in every cell.

The baseline disclosure also changes shape between the two tables. Here the comparison model is named, π0.5, and the demonstration budget is stated per cell. In the simulation table the comparison column is only labelled second best, so a reader cannot tell which model set that bar, and no trial counts appear anywhere in either table. Success rates without a denominator are the weakest part of this evidence, and the printer row shows that the denominators were not always favourable.

The leaderboard claim predates the public code release

The page states that as of July 15, 2026 the model ranks first on both the RoboCasa365 and RoboDojo leaderboards. The updates section records two events: a technical report on 2026-07-16, and code plus checkpoints for post-training, inference and benchmark evaluation on 2026-08-03. The leaderboard position therefore predates the code release by roughly three weeks, which means the ranking was established with weights nobody outside the project could obtain at the time.

The update log also fixes what exists. Code and checkpoints for post-training, inference and benchmark evaluation were released on 2026-08-03, and nothing later appears in that list, even though the repository's last push is dated 2026-09-09. So the published surface is three weeks old at the time of the last commit, and the repository has no GitHub releases at all, meaning version numbers, if any, live on the Hugging Face side rather than here. The technical report sits at arXiv 2607.15330, and the pages carry badges for a Papers With Code leaderboard entry, a Hugging Face collection, a ModelScope collection and a project page hosted at robotics.xiaomi.com.

The relative gain column reorders the table

Each benchmark row gives XR-1, the second best score and a relative gain, and the third column is computed against the second, not in points. The arithmetic checks out on all four rows: 1.9 points over 72.6 percent is 2.6 percent, 10.8 points over 46.6 percent is 23.2 percent, 5.9 points over 53.2 percent is 11.1 percent, and 5.13 points over 8.80 percent is 58.3 percent.

That choice changes the ranking. By absolute points the order is RoboCasa365 at 10.8, RoboDojo at 5.13, VLABench at 5.9 and RoboCasa at 1.9, so RoboDojo is second and VLABench is third. By the relative column printed in the table, RoboDojo is first and VLABench falls behind RoboCasa365. Both readings are defensible, and both belong in a table about ranking a first place on two leaderboards. A column of absolute point differences next to the relative one would let a reader see that the strongest result on RoboCasa is also the narrowest margin in the table, at 1.9 points over the field.

All four benchmarks are simulated, so nothing in this table speaks to the physical robot. The claim that pre-training on embodiment-free data transfers to real performance rests entirely on the four task table and the two demonstration budgets, which is a much thinner base than four simulation benchmarks suggest.

MoT matches the VLM layer count and shrinks the hidden size

The architecture is described in three sentences. A pre-trained vision-language model, Qwen3-VL, is coupled to a Diffusion-Transformer through a Mixture-of-Transformers arrangement. The DiT matches the VLM in layer count but uses a smaller hidden size, which is presented as the reason inference stays fast. That combination is the interesting part: depth is held constant across the two halves of the model while width is traded away on the action side, so the action head is as deep as the language model without paying its per-layer cost.

Two deployment details follow from it. Execution is described as asynchronous, to reduce inference latency, and the implementation is built on the Hugging Face transformers ecosystem with the dependency pinned to version 4.57.1 and the model optimised for consumer GPUs. A hard pin at that patch level is a deliberate choice that tells you the latency work depends on a specific release.

The published weights carry a size in the name, Xiaomi-Robotics-1-5B, while no parameter count appears anywhere in the README text. A 5B label on a model built from a Mixture-of-Transformers does not tell you how the budget splits between the language half and the action half, and that split is the number a reader with a memory budget actually needs.

Four root directories, and no dependency manifest

The repository root holds a README, a LICENSE and seven directories: deploy, docs, eval_robocasa, eval_robocasa365, eval_vlabench, scripts and xr1. Four of them are described somewhere on the page and three are not. The evaluation directories are linked as guides, and xr1 is named as the home of the post-training and deployment code with its own README covering environment setup, checkpoint conversion, data formats, training and deployment. deploy, docs and scripts appear in no link and no sentence.

That matters most for deploy, because a reader who wants deployment details is pointed at xr1/README.md while a separate top level deploy directory sits unexplained next to it. Whether that directory holds a different deployment path, a leftover, or a second copy is not answerable from the root listing.

There is also no dependency manifest at the top level. The project is primarily Python, the README pins transformers to 4.57.1, and there is no requirements file, no pyproject and no setup script in the root, so the environment a reader builds is defined somewhere inside xr1/ rather than at the front door. The README carries no install command and no run command of any kind; the only fenced block on the page is a BibTeX citation. Everything a new user needs to execute has to come from xr1/README.md, which the page does summarise but does not reproduce.

Embodiment-free pre-training is the whole argument

The two-stage structure is the substance of the release. Stage one is pre-training for breadth, on embodiment-free UMI trajectories, so the data does not come from the robot that will run the policy. The pipeline that makes this affordable is automatic: a VLM-powered auto-labeling step segments long trajectories into fixed-length clips and writes descriptions of the state transitions inside them, and the model is trained to generate the actions that carry a scene from its current state to the described target state. The stated payoff is that large scale annotation becomes practical and manual labelling, which is expensive enough to have capped policy-model scaling, is no longer the binding constraint.

Stage two is post-training for alignment, on more than 10K hours of cross-embodiment data after the 100K hours of pre-training. That data mixes in-house real robot recordings, filtered open source robot data and manually annotated UMI data, and alignment runs along two axes: embodiment alignment maps general action generation onto physical robots, and instruction alignment moves the model from acting on scene transition descriptions to following natural language instructions directly.

The corpus is described as spanning 1,700 or more scenarios across household, commercial, industrial and outdoor environments, and adaptation to a new task is claimed from a few hours of demonstrations. Stage one is therefore the scalable half and stage two is the expensive half, and only the second one has released code attached to it.

The saturation claim arrives without a scaling curve

The README states that pre-training scaling behaviour transfers through post-training to real world robot performance, with no signs of saturation. It is a strong statement about a trend, and the page offers no figure that shows the trend. There is no loss curve against hours of data, no table of model sizes, no ablation separating the contribution of each data source in stage two, and no scaling axis anywhere in the two tables that do exist.

What the page does offer is a single point on the data axis, 100K hours of embodiment-free UMI trajectories before post-training and 10K hours of cross-embodiment data after it, plus an adaptation table that moves along demonstration budget rather than pre-training scale. A claim about saturation needs at least two points on the pre-training axis, and only one is published.

The evidence for transfer to real hardware is thinner still. Four tasks, two demonstration budgets, one named baseline, no trial counts and no robot hardware identified. The adaptation results argue that post-training transfers what pre-training learned, since the same checkpoint family improves from 75 to 85 percent overall as demonstrations rise, but they cannot show that the pre-training axis itself has not plateaued.

Editorial conclusion

Read the two tables as different kinds of evidence. The simulation numbers come with fine-tuned checkpoints and evaluation guides for three of four benchmarks, so they can be rerun; the real world numbers come with no trial counts, no named robot hardware and one row that falls as demonstrations increase, so they cannot. Before building on this, check the three things the repository leaves open: whether the RoboDojo result matters to you given that no checkpoint accompanies it, what hardware the real world tasks ran on, and whether a transformers pin of 4.57.1 still matches your environment. The model itself is open, the architecture is described precisely enough to reason about, and the training recipe is documented in xr1/README.md. What is not open is the evidence behind the two strongest claims on the page.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. XiaomiRobotics/Xiaomi-Robotics-1 on GitHub