Choose a MolmoAct 2 checkpoint by embodiment and action schema, not by the most impressive model name. The official MolmoAct2 repository separates MolmoAct2 and MolmoAct2-Think foundation checkpoints for continued robot adaptation from fine-tuned DROID, BimanualYAM, SO100/101 and LIBERO checkpoints intended for named platforms or benchmarks.
For a new embodiment, Base is the default starting point; evaluate Think when explicit compact depth reasoning could solve a real spatial bottleneck. For a Franka DROID setup, bimanual YAM, SO-100/101 arm or LIBERO experiment, begin with the closest task-tuned model only after matching cameras, state vector and control representation. The robot foundation model guide explains why broad pretraining still needs embodiment adaptation.
Reduce the choice to embodiment, schema, task and reasoning need
Ask four questions before downloading a checkpoint: is the target a physical robot or simulation benchmark; is the embodiment a single Franka arm, bimanual YAM or SO-series arm; does the controller use joint position, end-effector pose or another action representation; and is explicit depth reasoning likely to justify additional compute and latency.
The repository calls the base models foundation checkpoints rather than one-size-fits-all deployment policies. Similar-looking arms can differ in joint order, limits, camera ordering, normalization tags and command units, so a matching parameter count or architecture does not establish an executable interface.
| Checkpoint | Official use | Closest target | Critical caveat |
|---|---|---|---|
| MolmoAct2 | Fine-tuning foundation | New embodiment or task | Requires target data and adaptation |
| MolmoAct2-Think | Depth-token reasoning foundation | Tasks where explicit 3D reasoning helps | Measure extra compute and latency |
| MolmoAct2-DROID | Inference or further fine-tuning | DROID-style Franka setup | Check absolute joint-pose schema |
| MolmoAct2-BimanualYAM | Bimanual inference or adaptation | YAM dual-arm setup | Camera order and 14-dimensional state matter |
| SO100_101 or LIBERO | Named hardware data or benchmark | SO arms or LIBERO suites | Do not confuse simulation with physical deployment |
Base is the general starting point, not a ready controller for every robot
MolmoAct2 Base is described as the post-trained model with a continuous flow-matching action expert and the default foundation checkpoint for adapting to a target robot or benchmark. It is the logical baseline when no released fine-tune matches the embodiment and task.
Connecting Base directly to a new gripper or joint layout can produce dimension, unit, normalization and safety-limit mismatches. A VLA model links vision and language to embodiment-specific action; the last part includes an exact controller interface and cannot be inferred from the model family name.
Think spends computation where depth reasoning may matter
The Ai2 launch article says MolmoAct 2-Think augments the policy with depth-perception tokens and uses an adaptive mechanism to route depth prediction when it is expected to improve the task. It is a reasonable candidate for occlusion, insertion and spatial relations where a compact 3D intermediate can change the action.
The label does not mean Think improves every task. When geometry is simple, additional depth work may add compute or latency without changing completion. Compare Base and Think with the same demonstrations, seed, hardware and control rate, and report p95 latency and recovery as well as average success.
Task-tuned checkpoints are strong only when their schemas match
DROID is fine-tuned on a filtered Franka mixture with absolute joint-pose control. BimanualYAM uses a bimanual mixture, absolute joint-pose control and annotated instructions. SO100_101 targets the SO-100 and SO-101 data, while LIBERO combines the Spatial, Object, Goal and Long training suites; Think-LIBERO adds the adaptive depth path.
Before reuse, compare joint ordering and range, state dimension and units, camera names and ordering, gripper representation, controller frequency, action horizon and normalization statistics. A near match may support conversion or further fine-tuning, but a silent mismatch can produce motion that looks numerically valid and is physically wrong.
| Compatibility layer | Items that must match | Failure if ignored |
|---|---|---|
| Embodiment | Joint count, order, limits and kinematics | Commands reach the wrong joint or pose |
| Observation | Camera count, name, order and resolution | View confusion and distribution shift |
| State | Dimension, unit, frame and normalization | Invalid conditioning values |
| Action | Joint pose, end-effector pose and gripper encoding | Controller and policy disagree |
| Time | Control frequency and action horizon | Stale actions, latency and instability |
Freeze runtime requirements before choosing hardware
The official Hugging Face model card supplies model metadata and safety boundaries, while the repository documents dependencies, checkpoint downloads, data types and example server schemas. These pages are living technical artifacts, so the exact commit and model revision should be recorded for a deployment review.
The current repository examples assume an accelerated runtime and describe substantially different memory behavior across data types and DROID or YAM setups. Do not purchase a GPU from a single headline. Measure peak memory and latency with the intended dtype, camera count, resolution, batch behavior and action horizon, including the server and preprocessing overhead.
Keep benchmark numbers inside the authors' protocol
The MolmoAct2 paper reports evaluation across seven simulation and real-world benchmarks and 13 embodied-reasoning benchmarks, along with released weights, training code and data. The Ai2 blog reports a 97.2 percent LIBERO post-training average for MolmoAct2 and 98.1 percent for Think.
These are author-reported results under the disclosed protocols, not a guarantee for another robot, camera suite, data budget or facility. Apply the robot VLA evaluation guide with fixed initial-state strata, complete trial counts, confidence intervals, failure classes, intervention and latency before making a deployment comparison.
A safe selection workflow starts with schema validation
Document the target observation, state and action schemas, then choose the closest checkpoint and validate dimensions, units and frames offline. Move to simulation with action limits and stop conditions before running a low-speed, low-force physical test in a controlled workspace. Every transformation between policy output and the robot should be explicit and versioned.
Compare Base and Think using the same data and seeds; for task-tuned models, version the adapter and normalization statistics. Follow the model card's safety direction by bounding speed, workspace, torque and contact force outside the learned policy, maintaining an emergency stop and supervising initial hardware operation.
Frequently asked questions
Should a new robot start from MolmoAct2 Base or Think?
Start with Base to establish a controlled baseline, then compare Think when depth, occlusion or spatial relations are a measured bottleneck. Both require target-robot adaptation and validation.
Can I run the DROID checkpoint directly on another robot arm?
Usually not without work. The DROID checkpoint assumes a Franka-style absolute joint-pose action and particular state and camera schemas. Check joints, frames, gripper, normalization and timing, then add an adapter or fine-tune as needed.
Does a 98.1 percent LIBERO result predict physical-robot success?
No. The figure is Ai2's reported post-training average for Think on LIBERO. A physical system adds embodiment, sensors, latency, contact, safety and recovery conditions that require a separate test.
Official sources checked
- Official Ai2 MolmoAct 2 launch article
- Official Ai2 MolmoAct2 GitHub repository
- Official Ai2 MolmoAct2 Hugging Face model card
- Official MolmoAct2 research paper
Last checked: August 7, 2026