DM0.5 Takes the Top Spot on RoboDojo, Bringing Embodied Models into a Truly “Reproducible” Phase

Yuanli Lingji’s general-purpose embodied foundation model, DM0.5, recently took first place on the RoboDojo leaderboard. It achieved an overall score of 24.90 and an average success rate of 19.34%, while covering multiple types of tasks in both real-robot and simulation environments. More importantly, this release was not simply a matter of putting out model weights: Yuanli Lingji open-sourced the model, training framework, and related reproduction materials together, further lowering the barrier for developers to verify and build on the work.

The significance of this may be greater than that of “yet another embodied model topping a leaderboard.” In the past, SOTA results in embodied intelligence were often kept inside laboratories: data-collection methods were not disclosed, hardware configurations were opaque, and training details were missing. External teams found it difficult to determine whether performance came from the model’s capabilities or from an engineering pipeline that was difficult to replicate. DM0.5 has at least pushed that door open a little.

Why RoboDojo Is Difficult

RoboDojo is not a lightweight test set suited to a promotional poster. It was initiated by the Multimedia Lab at the University of Hong Kong together with the University of California, Berkeley, Tsinghua University, and nearly 20 other academic institutions. It covers a range of embodied tasks, from navigation and grasping to whole-body control, emphasizing continuous decision-making and real-world execution capabilities in complex environments.

As of July 2026, the average success rate of the leading models on the RoboDojo simulation leaderboard was only 8.80%, while the real-robot leaderboard stood at just 12.8%. In other words, a robot completing a carefully designed demonstration in a laboratory does not mean it can continue working when the task, viewpoint, or objects change—or even after being interrupted by a person.

This is also what distinguishes RoboDojo from conventional visual question answering or single-arm-manipulator benchmarks: it does not test whether a robot “knows how to perform a particular action,” but whether it can continuously understand its state, correct errors, and finish a task over a sequence of actions. Once an embodied model leaves a fixed script, the problem changes from “recognizing an object” to “understanding the object, predicting changes, planning actions, executing them, and reviewing the results.”

DM0.5 took first place on this leaderboard with an overall score of 24.90 and an average success rate of 19.34%. This result is of course still far from meaning that “robots have become general-purpose,” but against an industry backdrop that is still broadly struggling with single-digit success rates, the improvement is real. At the very least, it shows that the generalization capabilities of embodied models do not necessarily have to be purchased through separate training for every individual scenario.

Memory, Not Parameter Count, Is the Standout Feature

DM0.5 has 4B parameters, twice the size of the previous-generation DM0. More important than its parameter count is how it handles long-term context and task states.

The model natively supports up to 60 seconds of memory, with an average memory length of around 30 seconds. For a language model, 60 seconds may represent only a short context; for a robot that needs to control a robotic arm in real time, it means the robot can retain a preceding sequence of actions, environmental changes, and task progress, rather than reassessing everything every few seconds as if it had “lost its memory.”

The Cover Blocks task in RoboDojo illustrates this particularly well. The robot must first use randomly arranged red, green, and blue blocks to cover target areas from left to right; after the colors have been completely obscured, it must uncover them in red, green, and blue order based on information observed earlier. On the surface, this is a pick-and-place task, but in practice it tests hidden-state memory, action-order retention, and state updates during execution.

If a person deliberately interrupts the robot during execution, it must reassess which step has actually been completed and then adjust its subsequent actions. A model that can only imitate local trajectories is likely to fail here: it remembers how to move for the next step but does not know whether it has actually reached that step. DM0.5’s advantage lies precisely in treating the task as a continuous process rather than as a collection of unrelated actions.

This matters greatly for real-world deployment. Tasks in warehouses, factories, and homes are rarely completed in one uninterrupted pass. Objects may be moved, a person’s hand may enter the field of view, a robotic arm may experience slight drift, and the target may temporarily change. Without short-term memory and state tracking, the so-called “general-purpose” capability will ultimately remain confined to clean demonstration videos.

From “See and Move” to Planning Before Execution

DM0.5 still follows the vision-language-action, or VLA, approach, but it does not simply turn the model into a reactive system that “takes an image as input and directly outputs joint actions.” During training, the team added embodied chain-of-thought tasks such as task planning, target localization, and future-state prediction.

This can be understood as giving the robot an intermediate process of “thinking things through before acting.” Faced with an instruction such as “organize the objects on the table into the box,” the model must first identify the targets and container, determine the grasping order, predict the spatial state after the objects are moved, and then decide on the robotic arm’s motion trajectory. During final execution, it may not necessarily output a lengthy explanation like a language model, but what it learns is a structure more closely resembling task planning.

Another key module is the trajectory-alignment layer. Traditional action learning tends to focus on several discrete key points—for example, where the robotic arm starts and where it finally stops—while overlooking the intermediate motion. The trajectory-alignment layer is more like an engineer responsible for “translation,” mapping high-level instructions onto continuous motion patterns. This allows the model not only to know that it should “pick up the cup,” but also to understand how the wrist should approach it, when the gripper should close, and how to correct for deviations.

This type of design may appear less straightforward than simply piling on more data, but it is closer to the core of embodied problems. A language model making a one-word error will not usually cause a task to fail immediately; if a robotic arm’s trajectory deviates by millimeters, it may knock an object over. Actions are not a sequence of static labels, but a continuous process subject to physical constraints.

150,000 Hours of Data—the Key Is How It Is Organized

DM0.5’s total training data amounts to approximately 150,000 hours, a 400% increase over the previous generation. This includes 50,000 hours of high-precision real-robot operation data covering more than 100 types of actions; 100,000 hours of first-person, or egocentric, data; and scene-reconstruction data for building complex indoor environments, with modeled spatial coverage reaching 1 million square meters.

The three types of data address different problems:

1. Real-robot operation data: Enables the model to learn contact, grasping, movement, and control errors in the real physical world.
2. Egocentric data: Enables the model to understand environments from a viewpoint close to that of human observation and supports the generation of millimeter-level, high-precision 3D landmarks.
3. Scene-reconstruction data: Expands the distribution of environments and spaces, helping narrow the simulation-to-reality, or Sim2Real, gap.

But data volume itself is not the answer. The embodied-intelligence industry is also pursuing millions of hours or even larger quantities of data. However, if that data merely piles together different scenes, robots, and actions, the model may acquire more isolated demonstrations rather than transferable capabilities.

DM0.5’s approach is more like placing data within a unified framework of tasks, states, and trajectories. The model must learn not only to “reach out after seeing a red block,” but also why the target changed, how far the action has progressed, and what conditions the next step must satisfy. Only when this information is aligned can data volume be converted into generalization ability.

Zero-Shot Gains Show That the Foundation Is Starting to Become Useful

According to publicly available information, compared with DM0, DM0.5 improves Zero-Shot navigation success by 31%, Few-shot success by 45%, and task success after fine-tuning by 20%. The value of Zero-Shot and Few-shot performance is that, compared with “continuing to train on the same task,” they provide a better indication of whether a model possesses foundational capabilities.

If new data collection and fine-tuning are required every time an object, position, or action changes, the model is effectively just a high-cost task-specific controller. A genuinely useful embodied foundation model should allow developers to transfer capabilities to new tasks through natural language, a small number of demonstrations, or a limited amount of data.

Yuanli Lingji also demonstrated task-learning capabilities based on human demonstrations. A human only needs to perform a demonstration once, after which the model can extract the task logic from the video and action sequence and reproduce it in a new setting. This is not an entirely new direction; the industry is broadly exploring Human-in-the-Loop approaches. When long-tail tasks in the open world cannot be covered by pretraining data, having a human teach the robot on site once is often more realistic than continuing to expand an offline dataset.

DM0.5’s long memory comes into play again here. It can retain a relatively complete demonstration, connecting the target, sequence, and actions in the video, thereby reducing the likelihood that it will remember only a local pose. For developers, this means robot training may have the opportunity to shift from “writing a control program” to “showing it how to do something once.” Naturally, demonstration quality, viewpoint changes, and task safety boundaries will still affect the final result; a single successful demonstration should not be interpreted as meaning that every scenario can be reproduced zero-shot.

Speed Determines Whether It Can Enter the Field

Embodied models cannot be judged by accuracy alone. A model that performs strongly in offline evaluations but takes hundreds of milliseconds for each inference may still be inadequate for rapid movement, flexible-object manipulation, or human-robot collaboration.

DM0.5’s overall inference efficiency has improved by approximately 25%. Its inference latency is as low as 50 ms on an H100 and approximately 90 ms on a consumer-grade RTX 4090. At 50 ms, a robot can update its actions more frequently based on new visual input; at 90 ms, developers have the opportunity to conduct real-time validation on relatively common consumer GPUs.

The term “real time” should still be understood cautiously. End-to-end control latency also includes camera capture, image preprocessing, communications, actuator response, and safety checks; model inference is only one part of the process. Nevertheless, reducing model latency to this level means that systems engineers do not necessarily have to start by tying the system to an expensive server cluster.

This is also a practical part of what it means for DM0.5 to be “useful”: generalization determines whether it can reduce the need for hand-written rules, while latency and hardware costs determine whether it can be deployed. Discussing leaderboard results without discussing operating costs can easily turn embodied models into expensive laboratory toys.

Full Open-Sourcing Lowers Reproduction Costs, Not the Costs of the Physical World

DM0.5’s full release is most directly valuable to developers because it makes verification possible. Researchers can examine how the model handles context and organizes trajectories, and can reproduce experiments on the same or similar hardware. Startups can use the model as a foundation and fine-tune it for specific robots and scenarios, rather than training a VLA from scratch.

However, it is important to make clear that “open source” does not mean embodied development has already become low-cost software engineering. Robots still require sensors, robotic arms, calibration tools, data-collection sites, and safety-testing environments. Real-robot data is particularly expensive. Publicly released weights can solve the problem of accessing the model, but not the problems of data collection and validation in the physical world.

What DM0.5 truly lowers is the barrier to reproducing the model:

• Research reproduction becomes easier: External teams have the opportunity to verify experimental conclusions based on public materials.
• Secondary training becomes more practical: Developers can focus their efforts on data cleaning, task adaptation, and hardware alignment rather than repeating pretraining.
• Ecosystem collaboration becomes smoother: Model providers, robot manufacturers, and universities can test capabilities around the same foundation.
• Problems surface faster: Failure cases involving different robots, cameras, and environments are easier to discover than in closed demonstrations.

For an industry that still lacks unified engineering standards, this openness is particularly important. The bottlenecks in embodied intelligence lie not only in model capabilities, but also in data formats, action spaces, hardware interfaces, and evaluation methods. If everyone keeps their systems closed, it will be difficult for the industry to establish comparable progress.

But It Is Still a Long Way from an “Embodied ChatGPT”

DM0.5 taking the top spot on RoboDojo does not mean that robots have already acquired general human capabilities. Translating a 19.34% average success rate into user experience still means a large number of failures. Sixty seconds of memory does not equal a long-term world model, and generalization after a single demonstration will be affected by object materials, lighting, the robot platform itself, and safety constraints.

A more realistic assessment is that DM0.5 has moved embodied models one step forward—from “single-task demonstrations” toward “multitask foundation models”—but the industry still needs to solve three problems.

First, long-term reliability. Robots need to operate continuously for tens of minutes or even hours, rather than performing well only for a single minute.

Second, failure recovery. Collisions, occlusions, and anomalies are unavoidable in the real world. Models must know when to stop and request human intervention rather than confidently continuing execution.

Third, cost and scalability. If every customer has to collect large quantities of real-robot data again, the commercial value of a general-purpose model will be offset by deployment costs. Simulation training, few-shot adaptation, and cross-embodiment transfer all need to mature further.

The developer ecosystem released by Yuanli Lingji in July is also working to fill this infrastructure gap. DFOL 2.0 attempts to move reinforcement learning into high-fidelity simulation environments with the help of the general embodied world model DW0.5. According to the company’s disclosures, the demand for real-robot training data can be reduced by 60%, while overall training costs can fall by 40%. DexOS attempts to decouple robot hardware through a software layer, allowing developers to connect robots, acquire sensory data, run model inference, and execute actions with less code. MaaS provides enterprises with one-stop embodied-model services.

Whether these products can truly work in practice remains to be seen through actual customer deployments, rather than architecture diagrams presented at product launches. But the direction is correct: models, simulation, operating systems, and service platforms must work together to reduce the cost of deployment. Releasing a single larger model cannot solve the industry’s problems.

What This Means for Developers

After DM0.5’s full open-source release, the most suitable immediate use is not to connect it directly to a production line, but to conduct three types of validation.

1. Cross-task generalization tests: Select tasks outside the training set but with similar action structures, and observe whether the model has generalized the target or merely memorized visual templates.
2. Interruption and recovery tests: Change an object’s position or interrupt an action during task execution, and check whether the model can re-estimate the state.
3. Cross-hardware tests: Transfer the model to different robotic arms, cameras, and control frequencies, and evaluate whether the trajectory-alignment layer truly reduces adaptation work.

Simply reproducing the official demo provides limited information. The truly valuable test is to place the model in an unfamiliar but sufficiently safe environment and record failure types, latency, and the number of replanning attempts. The engineering capabilities of an embodied model are often revealed in what happens after failure, not in a successful video.

Model aggregation platforms such as OpenAI Hub that are compatible with the OpenAI format primarily solve the problem of unified access to language and multimodal models; they cannot replace the control, calibration, and safety systems on the robot side. For embodied developers, a more practical combination is to use a cloud-based model for high-level task understanding or language interaction, while placing an embodied model such as DM0.5 on a local or edge device to handle low-latency action control. The interfaces, latency, and permission boundaries between the two still need to be designed by developers themselves.

Conclusion: Open Source Brings Embodied SOTA into the Verification Phase

DM0.5’s rise to the top shows that the focus of competition in embodied models is shifting from “Can it complete a polished demo?” to “Can it generalize reliably across multiple types of tasks?” Its 4B parameters, 150,000 hours of data, 60-second memory, and lower inference latency form an engineering-oriented answer; full open-sourcing brings that answer closer than ever to something developers can dissect and reproduce.

Of course, first place on RoboDojo is not the finish line, and a 19.34% average success rate is still nowhere near the level of reliability required by industry. But in a field long constrained by barriers involving data, hardware, and reproducibility, openness is progress in itself.

What is truly worth watching next is not whether DM0.5 can continue climbing leaderboards, but how many teams can use it to reproduce results across different robot platforms and environments, and feed their failure experiences back into the model and data systems. If this loop gets up and running, embodied models will have begun to move from SOTA in papers to infrastructure in developers’ hands.

References

• Zhihu: DM0.5, DexDev, and Ferrata Released Together: Can Yuanli Lingji Use a Full-Stack Approach to Make Embodied Intelligence Work in Practice?: An introduction to DM0.5, Yuanli Lingji’s models and platforms, and its industrialization strategy.
• Zhihu: Technical and Product Information Related to Yuanli Lingji’s DM0.5: Additional background on the model’s generalization capabilities, developer platform, and embodied-system architecture.