LimX Dynamics' Open-Source FluxVLA Engine Update Connects the Entire Embodied Intelligence Pipeline from Data and Training to Evaluation and Deployment

A full interpretation of the technical report on the open-source engineering foundation FluxVLA Engine.

English text is being prepared.

English text is being prepared.

01

New models, please register first. Whether an engineering foundation is truly useful first depends on whether it can accept different models. For embodied intelligence, models iterate the fastest. Today one VLA architecture is used, tomorrow another action generation method may be tried; the same team may also study multiple policy models at the same time. If every model switch requires reorganizing data, writing evaluation code, and modifying deployment interfaces, then the engineering experience accumulated previously will be hard to keep delivering value. Models can keep changing, but the engineering capabilities built around data, evaluation, and deployment should not have to start over every time. FluxVLA Engine's approach is to use unified configuration and a component registration mechanism to converge, as much as possible, the differences that must be handled when integrating different models into the R&D process into explicit interfaces. It can be understood as a unified experiment manifest plus a catalog of callable components. The configuration file declares what model an experiment needs, how to process data, how to carry out evaluation, and through what interface to deploy. The registration mechanism organizes visual backbones, action heads, training runners, and robot-related operation components separately. Developers can combine already-adapted components as needed, without having to rebuild the entire engineering pipeline for every model. This does not mean any model can run directly without adaptation. Different architectures may still need their own adapters, action space conversions, and normalization processing. The real value lies in putting the unavoidable differences into a manageable component layer, so that the common pipelines already connected can continue to be reused. According to the technical report, FluxVLA has already brought policies with clearly different architectures into the same R&D and evaluation system, including OpenVLA, which adopts an autoregressive route, π0.5, which adopts a flow-matching route, and models on different technical routes such as DiT4DiT and GR00T. This means that a unified engineering framework need not come at the cost of model diversity. FluxVLA's model integration is not limited to models with open weights. GPT-6 Astra had previously been integrated purely via API; with the same closed-loop evaluation, no weights provided and no training involved, the evaluator still runs the pipeline as usual and keeps the evidence. Just two days after the latest technical report was released, MiniMax-M3.1-Flash became the second checkpoint-free pure-API inference policy after GPT-6 Astra, ready out of the box to run evaluations on LIBERO and RoboCasa GR1. The data level follows the same logic. Trajectory data generated by different robots and different simulation environments is uniformly converted into a standard format, and can then be mixed for training in the same pipeline, or grouped to retain their respective normalization conventions. A dataset prepared for one model today can still be used tomorrow when switching to another model. Engineering accumulation does not reset to zero when the technical route switches—this is the precondition for the industry's R&D results to keep compounding rather than canceling each other out. After all, data is the most expensive asset in embodied intelligence, and being able to make this asset depreciate less and be reused more is itself an industry-level cost reduction.

02

English text is being prepared.

03

Bringing real interaction experience into the training loop. Once the model is put on a real robot, what then? In the mainstream development paradigm of embodied intelligence, the usual process is: collect human demonstration data, train the model, test, collect again, and so on. This approach has already advanced many robot manipulation capabilities, but the situations that demonstration data can cover are ultimately limited; factors such as object positions, lighting, and the robot's initial state in real environments keep changing, and the model may encounter situations not sufficiently covered by the training data. If every time a problem is found, one can only rely on manually supplementing demonstration data, the speed of model improvement will be constrained by data collection and the training process. In this update, FluxVLA introduces online reinforcement learning post-training, directly addressing this problem. From an engineering design perspective, this solution is quite restrained. FluxVLA did not choose to implement RL itself, but instead interfaces with the RLinf system, which specializes in large-scale RL training, with each doing what it does best: FluxVLA retains the layer of model construction, observation processing, and action conversion, while RLinf handles rollout collection, optimization algorithms, and weight synchronization. The two are connected through interfaces; the same model does not need to be modified, and once connected to the RLinf frontend it can enter the online RL training loop. This division of labor leaves the existing supervised training process completely unaffected; RL is an optional incremental capability rather than a replacement for the existing workflow. In open-source projects, taking on everything is the norm; handing off what one is not good at is instead rare. FluxVLA's willingness to leave interfaces at the boundary and collaborate with external systems shows that it is very clear about its positioning and has no intention of building an all-encompassing one-stop solution. However, online reinforcement learning does not mean the robot can automatically understand every failure, nor does it guarantee that the longer the training, the stronger the model will necessarily become. It provides a path to optimize the policy using interaction data, and the final effect still depends on reward design, training settings, and task conditions. The technical report gives a set of paired experiment results: SmolVLA on LIBERO-10 improved its success rate from a baseline of 66.2% to 76.2%, an increase of 10 percentage points; on the 10 tasks of the RoboTwin Clean setting, it rose from 45.9% to 61.3%, an increase of 15.4 percentage points. The RoboTwin experiment also recorded that after training, 231 previously failed episodes turned into successes, but 77 originally successful episodes regressed. This means that although the overall performance of the policy improved, it did not achieve simultaneous optimization for all cases. The report also notes that as training continued, the success rate on LIBERO-10 slightly declined from its peak. This set of experiments also validated an important direction: when policy interaction, data collection, and training optimization can form an engineering closed loop, the experience gained during real execution has the opportunity to be used for subsequent model improvement, rather than remaining merely a one-off test result. For the entire industry, this means the R&D process can expand from the one-way "collect demonstrations—train—test" further toward "execute—collect experience—optimize policy—execute again."

04

Coverage is the real hard metric. Whether an engineering system can deliver value also depends on how broadly it has been validated. If it supports only a few models, or can run on only a single robot, its reusability remains limited. Conversely, if multiple heterogeneous policies can enter the same evaluation system and complete the corresponding tests on different robot platforms, there is a better chance to prove that this engineering framework has a degree of generality. The evaluation results in the FluxVLA technical report provide several aspects worth observing. On the simulation side, as already mentioned in the first part, policies with vastly different internal structures can share the same data pipeline and evaluator. In terms of specific numbers, the technical report integrated a total of 14 policies on LIBERO, and of the 13 local checkpoints, 11 achieved an average success rate above 95%. Two details were not expanded on previously. The first is difficulty stratification. LIBERO tests short, tabletop-level tasks, and part of the reason for the high scores comes from the task characteristics of the benchmark itself. When the same policies are switched to the more difficult RoboCasa GR-1, which is closer to real household manipulation, the average success rate drops to between 8.75% and 57.25%. It should be noted that this gap comes from differences in task difficulty, not from issues with the evaluation criteria. The report also clearly states that the two sets of results come from different model architectures, data budgets, and training pipelines, and do not constitute a controlled comparison. Validating policies on tasks of different difficulty is not just about obtaining a success rate number; more importantly, it helps developers judge what a model can currently accomplish and on which tasks there is still room for improvement. The unified evaluation process provided by FluxVLA allows this kind of capability validation to be carried out continuously on the corresponding benchmarks. The second is generalization. In RoboDojo's 42 tasks and 2,100 trials per model, most models can complete part of the tasks, but the proportion that can complete all of them from start to finish is much lower; when the task layout is changed from fixed to random, the success rate of the top-ranked π0.5 drops from 16% to 2.33%, and the highest among the remaining seven models is only 0.67%. From this set of numbers, it is not hard to see the common predicament all current mainstream policies face when confronted with unseen scenarios. On the real-robot side, the platform has been expanded to four: the ALOHA dual-arm system (6 tasks, 7 policy configurations), LimX Dynamics' self-developed full-size humanoid robot Oli, Rebot, and the dual-arm Franka. Policies trained and validated in simulation went directly onto four platforms of different forms through the same deployment path, and all completed closed-loop testing. What is very interesting is a set of details on Oli: in the four-stage box-carrying task, the completion rates of GR00T N1.5 and π0.5 in the first three stages were almost the same (60% vs. 61.67%), yet the full-task completion rates were only 6.7% and 33.33%. The success rate of long-horizon tasks is multiplicative, not additive; the tiny deviations accumulated in the earlier stages are amplified step by step later on. We have heard about this problem many times in conversations with industry insiders, but could only remain at the level of understanding and imagination. This time, FluxVLA's evaluation design of recording completion by stage allowed us to see this point clearly. What best demonstrates the value of the closed loop is the data from towel folding with ALOHA. First, traditional behavior cloning was used for training, that is, letting the model copy the actions of human demonstrations, and the success rate was only 62.1%. With a different approach, a reward model was first trained to let the system learn to judge how well each action was performed, and then this judgment was used in turn to guide policy training, raising the success rate to 99.4%. From collecting data on the real robot and training the reward model to retraining the policy and deploying it back to the real robot, the entire process was completed on a single foundation, FluxVLA Engine. Taken together, the evaluation results of FluxVLA provide two different types of evidence. One is engineering capability: multiple heterogeneous policies were incorporated into a unified evaluation system, and multiple real-robot platforms completed the corresponding closed-loop validation, showing that it has already demonstrated the ability to organize R&D processes across models and platforms. The other is the verifiability of model capabilities: the performance differences under different benchmarks, the changes in success rate brought by random layouts, and the stage-by-stage losses in long-horizon tasks all provide a more concrete basis for observing the boundaries of model capabilities. The engineering foundation does not replace optimization of the models themselves, nor does it mean that all policies can automatically acquire excellent generalization ability; what it provides is a relatively unified validation path that allows developers to more reliably assess existing capabilities, identify problems, and continue improving in subsequent R&D.

05

An army perishes without supplies. In 2026, the focus of competition in embodied intelligence is gradually shifting from whose model is more impressive to who has more and more diverse data, whose body is more durable, and whose commercialization path is clearer. Firepower is contested at the front, while provisions are contested in the rear; a complete engineering ecosystem is like a reliable supply line, and the later the stage of the battle, the more its value shows. The value of FluxVLA does not lie in solving all the engineering challenges of embodied intelligence, but in attempting to turn some of the recurring problems into reusable engineering mechanisms. Model registration and unified configuration reduce the need to repeatedly build R&D pipelines; inference optimization, RTC, and trajectory post-processing break some real-robot execution obstacles into processable steps; online RL integration provides an engineering interface for interaction data to enter policy optimization; and cross-model and cross-platform evaluation allows different policies to be validated under the corresponding conditions. Together, these capabilities point to one goal: enabling R&D teams to devote more energy to the models, data, and tasks themselves, rather than repeatedly dealing with the same basic engineering problems in every experiment. More importantly, the unification of engineering processes not only serves R&D efficiency but also gives the validation and iteration of model capabilities a more stable foundation. Developers can compare different approaches within a relatively consistent process, observe how policies perform on different tasks and platforms, and then bring the problems they find back to the data, training, and deployment stages. In addition, FluxVLA makes a choice that is easy to overlook but, in our view, crucial: it does not pursue unconditional compatibility of all components. Differences in data structures, action semantics, and interfaces among different models, datasets, and robot bodies objectively exist, and no one can erase them. With standard interfaces and modular design, FluxVLA concentrates these differences into links that can be checked and adapted—when something goes wrong in a combination, people can know exactly where it is. In terms of engineering reliability, this posture of letting problems surface is more valuable than pretending that everything is compatible. As an embodied intelligence OEM, LimX Dynamics could have treated the pitfalls it encountered and the processes it validated in robot bodies, algorithm R&D, and real-robot operation as a moat serving its own products, but it chose to turn frontline experience into an open, standardized engineering foundation, providing external developers, algorithm teams, and other robot platforms with more possibilities for use and collaboration through enterprise-level resources. Of course, this does not mean that the open-source project has naturally formed a mature industry ecosystem. A true ecosystem still requires external teams to continue using it, contribute adaptations, provide feedback on problems, and validate its value in different scenarios. But open interfaces and reusable tools at least provide a foundation for such collaboration. FluxVLA Engine code repository: https://github.com/FluxVLA/FluxVLA Technical report: https://arxiv.org/abs/2609.17210Hugging Face: https://huggingface.co/limxdynamics/FluxVLAEngine