MolmoAct2: Open-Source Robot Reasoning Hits 87% on Real-World Tasks

Why this moment matters

Until now, the state of the art in robot reasoning was proprietary. Boston Dynamics runs closed inference on Atlas. Figure AI's Figure-02 platform is not open. Tesla's Optimus uses a completely internal stack. The closest thing to an open-source robotics foundation model was OpenVLA — useful, but meaningfully behind the proprietary leaders in real-world generalisation. MolmoAct2 changes that calculus. An action reasoning model achieving 87.1% success on unseen real-world manipulation tasks, released with full weights, data, and code, represents a structural shift in who can build on frontier robotics AI.

This is not merely an academic milestone. The practical consequence is that a robotics startup in Bengaluru, a university lab in Bristol, or a warehouse automation team in Manchester can now build on the same class of model previously available only to companies that had spent years and tens of millions training their own stacks. The barrier was not just proprietary weights — it was the training data. Ai2 releasing the DROID training dataset alongside MolmoAct2 is the part that actually enables custom domain adaptation. That combination — frontier-class capability plus reproducible training — is genuinely new.

What MolmoAct2 actually is

MolmoAct2 is a multimodal vision-language-action (VLA) model. It takes a camera image of the robot's environment, a natural-language task instruction (for example, "pick up the red cup and place it on the tray"), and produces a motor command — a target joint configuration or end-effector pose — that the robot arm executes. That is the standard VLA loop; MolmoAct2's distinctive contribution is what happens between the image input and the motor output.

The model first generates an explicit action-reasoning step in natural language. Before committing to a motor command, it produces a chain-of-thought that describes what it sees, what the task requires, and what physical action it intends to take. This intermediate reasoning step is not shown to the user in a deployed robot — it is internal — but it is the mechanism the team attributes to the model's strong generalisation. The model "thinks aloud" before acting, and that deliberation makes it substantially more robust when it encounters objects outside its training distribution.

The architecture builds on the Molmo multimodal model family, which Ai2 previously released for vision-language tasks. Adding the action-reasoning intermediate step and training on the DROID manipulation dataset produces a model that can be grounded to a robot arm and deployed with comparatively modest engineering effort.

The numbers in context

The headline benchmark is 87.1% task success on the DROID real-world evaluation, specifically under the unseen-objects condition. That last qualifier is essential. A model that achieves high accuracy on objects it has memorised is not useful in a real deployment — your factory floor, warehouse, or lab will always contain items outside any training set. The unseen-objects condition is the one that tells you whether the model will actually generalise, and 87.1% is a genuinely strong number on that harder split.

The 2.42 times control rate speedup reflects engineering work on the inference pipeline, not a change to the model itself. Robot control loops typically need sub-50-millisecond response times to feel natural and to avoid mechanical instability. An action-reasoning model that takes 200 milliseconds per decision cycle is too slow for many real deployments regardless of its accuracy. The optimised inference stack brings MolmoAct2 within a range that makes real-time deployment feasible, not just technically possible on paper.

The third number is the one that is easy to overlook: 100% open. Not open-weight with closed data. Not open-research with a commercial restriction clause. Weights, training data, and code — all of it. That combination is what makes fine-tuning for new environments tractable rather than experimental.

How it compares: MolmoAct2 vs RT-2 vs OpenVLA

The robotics VLA landscape has three relevant reference points: Google DeepMind's RT-2, OpenVLA, and now MolmoAct2. The table below compares them on the dimensions that matter for a builder choosing a foundation for a real deployment.

The direct comparison with RT-2 is architecturally meaningful but not a clean head-to-head benchmark — Google has not published RT-2 numbers on the same DROID unseen-objects split in a directly comparable form. What the table captures is the open-versus-closed structural difference: RT-2 is a strong proprietary model you cannot fine-tune, cannot audit, and cannot deploy without a Google agreement. MolmoAct2 is a strong open model you can do all of those things with. For most builders, the comparison that matters is MolmoAct2 versus OpenVLA — the previous best open baseline — and there MolmoAct2 is a clear step forward on the dimension that counts.

The builder playbook: getting started with MolmoAct2

For a team ready to build on MolmoAct2, the path breaks into four stages: access, environment validation, fine-tuning, and deployment.

Access. The model weights are available on Hugging Face under the Ai2 organisation. The GitHub repository contains the inference code, training scripts, and data loading utilities for the DROID dataset. Start with the model card — it documents the camera parameters, robot arm configuration (Franka Panda), and coordinate conventions used in training, all of which matter before you write a single line of your own code.

Environment validation. Before fine-tuning for a new robot or environment, validate that your camera setup can produce inputs in the same format as the DROID training data. Resolution, aspect ratio, field of view, and mounting position all affect the visual features the model has learned to interpret. A calibration mismatch at this stage produces confusing fine-tuning behaviour that is difficult to diagnose.

Fine-tuning. The team's published guidance suggests roughly 500–1,000 demonstration trajectories collected via teleoperation for a new environment with similar objects and task structure. For a substantially different domain — different arm kinematics, different object classes, different lighting — expect to collect more. GPU budget for a small-domain adaptation: approximately 8 to 16 A100 GPU-hours at standard fine-tuning learning rates. If you are in India and working with cloud GPU providers (E2E Networks, Yotta, or AWS/Azure India regions), budget accordingly — the fine-tuning compute is modest by language model standards.

Deployment. The optimised inference pipeline ships with the repository. For sub-50-millisecond control loops you will need a local GPU — the current stack is not optimised for remote API calls with network latency in the loop. A single RTX 4090 or equivalent is sufficient for the optimised inference path. Budget for a workstation-class machine rather than a cloud instance unless you are comfortable with the latency implications of a remote GPU.

What this means for Indian builders

India's manufacturing sector is at an inflection point on robotics adoption. Tata Group, Mahindra, and Hero MotoCorp are all running robotics pilots in automotive assembly. The textile and garment sector — one of India's largest employers — is under persistent pressure to automate picking, folding, and sorting operations that are currently labour-intensive. Agricultural robotics, particularly for harvest assistance and drone guidance systems, is a growing area. And India's rapidly expanding e-commerce logistics infrastructure — driven by Meesho, Flipkart, and Amazon India — is actively looking for automation that can handle the long tail of SKU diversity that characterises Indian retail.

All of these applications share a common constraint: the object diversity is enormous, which is precisely the condition where a model's generalisation to unseen objects determines whether it is useful. A model that handles 87% of unseen manipulation tasks is a practical tool. A model that handles 60% of unseen tasks is a research prototype. MolmoAct2 is closer to the former.

The open training data is particularly valuable in the Indian context. Fine-tuning for Indian-manufactured goods — different packaging, different colour distributions, different material surfaces — requires domain-specific demonstration data. The DROID dataset and code provide a structured path to building that domain-specific layer without starting from scratch. For a well-resourced engineering team, this reduces the time-to-prototype for a new application domain from years to months.

For cost-sensitive deployments, the inference economics also matter. A single workstation-class GPU running the optimised MolmoAct2 pipeline is a fixed capital cost, not a per-query API bill. For high-throughput manufacturing automation that runs around the clock, the total cost of ownership comparison versus a cloud robotics inference API is strongly in favour of self-hosted open weights.

What this means for UK builders

The United Kingdom has a strong robotics research tradition. Bristol Robotics Laboratory — Europe's largest dedicated robotics research facility — has long produced work in manipulation and autonomous systems. The Cambridge Robotics initiative and Edinburgh's robotics research groups have produced commercially significant spin-outs. MolmoAct2 gives these academic groups a frontier-class open model to build on rather than a previous-generation baseline, and the implications for UK-originating spinouts are direct.

On the industrial side, UK aerospace and automotive are the obvious sectors. BAE Systems and Airbus UK run composite lay-up and precision assembly operations that involve significant manipulation complexity. Jaguar Land Rover's manufacturing programmes include assembly-line robotics that must handle variant-rich production runs — exactly the generalisation problem MolmoAct2 addresses. In logistics, Ocado's warehouse automation and Amazon's UK fulfilment network are both technically sophisticated but operate in highly structured environments. The near-term opportunity is in less-structured logistics contexts — returns processing, small-item picking, cross-docking — where object diversity is high and current automation approaches struggle.

There is also a regulatory angle. The UK's evolving approach to industrial AI safety means that explainability — the ability to audit why a robot took a particular action — is a growing concern. MolmoAct2's explicit action-reasoning step produces a natural-language chain-of-thought before each motor command. In practice, that means an audit trail of the model's reasoning for each action, which is a meaningful advantage in regulated or safety-critical deployment contexts compared to a purely implicit action head.

Where MolmoAct2 falls short

Being honest about the model's limits is as important as covering what it does well. There are three significant gaps to understand before building on it.

Benchmark environment versus the real world. The DROID benchmark is a tabletop manipulation setup with a Franka Panda arm, controlled lighting, and a specific camera configuration. That is a useful and practically relevant setting, but it is not a factory floor, a hospital ward, an outdoor agricultural environment, or a logistics dock. Any deployment outside the DROID environment family needs careful domain evaluation before production use. The 87.1% number tells you the model has strong generalisation within the DROID distribution; it does not tell you how it will perform in your specific environment without your own evaluation data.

Control rate is good, not free. The 2.42× speedup is meaningful and the result is genuinely better suited to real-time control than the unoptimised baseline. But the absolute control rate still needs to be validated against your specific hardware and control loop requirements. If your application needs sub-20-millisecond response times, you will need to benchmark on your actual hardware before committing to the architecture.

Mobile and high-speed applications are not covered. MolmoAct2 was designed for tabletop manipulation — a stationary arm picking and placing objects. Mobile robots, legged robots, drones, and high-speed industrial machinery all involve substantially different dynamics and sensing requirements. The model's architecture does not preclude fine-tuning for these domains, but the base weights do not provide a meaningful starting point. For those applications, the previous-generation open options remain the relevant baseline.

For practical guidance on inference economics and the broader infrastructure landscape, our piece on AI inference costs in 2026 and the Nvidia B300 inference economics breakdown are relevant background. For the broader context of open-source models competing with proprietary stacks, see the agent SDK landscape analysis.

The research paper, model weights, and DROID training data are available via the Ai2 GitHub organisation and the Hugging Face model hub. The recommended entry point is the model card on Hugging Face, which documents the camera parameters, coordinate conventions, and evaluation protocol in detail before you commit to a hardware setup.

For the broader open-source research context, see our coverage of Gemma 4's configurable reasoning and the AlphaEvolve algorithm discovery system from DeepMind. Related profiles of Builders working on agentic and embodied AI are in the Builder directory; if you are working on physical AI and want to be found by companies hiring, add your profile.