molmoact2-so100-101: MolmoAct2-SO100_101, the SO-100 and SO-101 robot checkpoint from Ai2, documented as a metered action lane

MolmoAct2-SO100_101 is the SO-100 and SO-101 member of the MolmoAct2 family from the Allen Institute for AI, or Ai2. The family is an open set of robot action models. This member is tuned for the two low cost arms that hobby labs and classrooms actually own. It reads two camera views and a plain instruction, and it returns a chunk of joint commands for the arm to run. The checkpoint is real, public, and Apache-2.0 licensed today. The metered lane's row on this platform sits behind the public list. Nothing serves under this name today. This page carries the facts a buyer needs: which checkpoint to take, what it expects from your robot, what the numbers honestly say, and the exact call shape the lane documents.

Last verified: 2026-10-05

What it is

MolmoAct2 is an action reasoning model for robot control. The official SO100_101 model card describes the build: the model starts from Molmo2-ER, an embodied-reasoning vision-language backbone, and attaches a flow-matching action expert. The expert connects to the backbone through each layer's key-value cache. In plain words: one network reads the cameras and the words, and a second head turns that reading into smooth joint motion. It does not output text. It outputs joint targets for the arm.

The family shipped May 5, 2026, with a code and data release on May 28. The launch post reports more than 400,000 downloads in the first weeks, and the full release is unusually deep: weights, fine-tuning scripts, every training dataset, evaluation rollouts, and the action tokenizer recipe. Full detail sits in the paper.

The identity facts, each with its owner:

The name map, and the model it is not

One family, several spellings. The repository and the model pages write MolmoAct2. Ai2's launch blog writes MolmoAct 2 in prose headings. A spaced form, molmoact 2, shows up in search suggestions, and so does molmoact 2 research kit, a hardware kit name from a third party. All of these name the same model family. This page is about the SO100_101 fine-tune, the checkpoint for SO-100 and SO-101 arms.

Do not confuse it with MolmoAct, the 2025 model. That earlier project sits in a separate Ai2 repository and has its own checkpoints. The two names differ by one character and about nine months of research. The year and the 2 decide which one you are reading about.

The checkpoint family, and which one is a product

The official repository splits the family into two groups. Base checkpoints exist for further training. Fine-tuned checkpoints exist to run. The base model card says it plainly: the base is "intended as a foundation checkpoint for further robot fine-tuning rather than as a ready-to-run policy." The fine-tunes are the ones that move an arm out of the box.

One base row deserves its own note. MolmoAct2-Pretrain, read October 5, 2026 on its own model page, is the pre-trained backbone before the flow-matching action expert is attached: a 5B checkpoint that encodes robot state as discrete tokens and emits actions as discrete OpenFAST tokens over one-second spans. Its own words: intended for further post-training or fine-tuning, not direct continuous-control inference.

The task range matters. The repository carries a direct warning: out-of-the-box use is for simple tasks inside the training mix, such as pick and place, and the team verified behavior on the SO-100 and Franka DROID setups only. Results on other arms are not promised.

The posture on this platform, stated plainly: the row exists in the platform's model data with its rate set, and this page's search listing carries that rate. It is not on the public list, and nothing answers under the name today. The models index is the live catalog. For the model class and the call pattern in general terms, the VLA category page is the explainer.

Use cases

Zero-shot pick and place on an SO-100 or SO-101. Give it two views of the table and an instruction such as "Move the arm towards the lemon, grasp it, lift it up, and drop it into the red bowl." The model outputs joint targets that run directly. The official card ships exactly this lemon task as its sample. Start with a dry run that prints actions without moving the arm, a habit the deepest community guide shares.

A starting point for your own fine-tune. Record a few hundred episodes on your arm and tune from this checkpoint. The LeRobot docs recommend low-rank adapter tuning first for small datasets, and note the action expert stays fully trainable in every mode. Results transfer because you start from a checkpoint that already knows these arms.

A teaching and evaluation platform. The family pairs with public datasets, so a class can record, train, and grade on cheap hardware. The LIBERO fine-tune gives a simulation path with published, repeatable numbers.

The camera and state contract

This checkpoint wants two camera views and six numbers. The card's sample uses a top RealSense view and a side view; a wrist camera plus an overhead view also works. Camera order, the card states, does not need to be fixed for this checkpoint. The LeRobot-format port maps the two views to fixed keys, cam0 and cam1, primary and secondary. That is the mapping to keep straight when you bridge the port to your own rig.

The state is the raw joint state of the arm: six numbers, one per motor, in degrees. Actions come back in the same robot scale. The action chunk holds 30 targets. Per the paper: one chunk equals one second of robot motion, so the chunk length follows the control rate of the training data, 30 Hz on these arms.

The norm stats contract

Every MolmoAct2 checkpoint ships a file called norm_stats.json. For this one, the tag is so100_so101_molmoact2. The file holds the action range the training data covered, the 30-step horizon, and the setup text that gets inserted into the model's prompt, such as "single so100/so101 robotic arm". Pass the tag and the mapping applies for you. Skip it and the model output will not match your joint scale. This is the single most common way a first run goes wrong, on this model and on the whole model class.

The lane's contract here carries these statistics in the response itself. Every answer returns the normalization block it applied, byte for byte, so a caller can check the mapping without downloading anything.

The joint transform trap

The training data used an older joint-angle convention than current LeRobot releases record. The fix is a fixed transform: joint_signs of 1, -1, 1, 1, 1, 1, and joint_offsets of 0, 90, 90, 0, 0, 0 degrees. In the converted port checkpoint, lerobot/MolmoAct2-SO100_101-LeRobot, the transform is already baked in. Build your own path from the raw weights and you must apply it yourself. A community guide for this exact arm, read October 5, 2026, warns that skipping it makes "the arm slam hard into the table on startup", and calls that the most common failure mode. Run dry, check the first targets, then let the arm move.

Run the weights yourself, or wait for a lane

Self-hosting is open today and, for this checkpoint, it is the only option today. The license permits commercial use. For planning: the download is 21.8 GB in float32. The card says a float32 run wants roughly 24 to 26 GB of GPU memory, while a bfloat16 run stayed under 16 GB in their tests and, in their words, usually does not hurt performance much. A 24 GB gaming card runs it in bfloat16. The port also needs a current transformers release; one widely used community setup, checked October 5, 2026, names 4.52 or newer.

The contract has a shape too. The lane meters by the call against a prepaid wallet, and the rate already sits in this page's search listing. The pricing page carries the full rate cards for the rows it lists. If you want the how-to depth, recording, calibration, and fine-tune recipes, the platform's molmoact2 guide covers that side; this page stays on the facts of the checkpoint itself.

API usage

The designed contract is the platform's action route: POST /v1/action, one call per action chunk. The body is multipart form data. You send the model name, a plain instruction, the joint state as a JSON array of numbers, and one or more camera images. You get back an action chunk, the normalization block, and the call's own cost.

The response carries three parts. actions is the chunk, an array of joint-target arrays, in the artifact's own shape. normalization is the per-embodiment statistics the lane applied, passed through unchanged. usage holds the call count and the cost of the call, so every answer prices itself.

Metering, as the lane is designed:

The dash is deliberate. The rate publishes with the row, not before it. The rate is set in the platform's model data, and this page's search listing carries it today. The pricing page renders full rate cards for the rows it lists. One served call bills one call. A refused request bills nothing.

Two honesty lines. Calls to this alias answer a plain 404 today, and the client can be written and tested against the shape now. And if the lane is busy when a call lands, the answer is a named 429 with a retry hint, never a silent failure; that turn bills nothing.

curl

curl -X POST "https://api.ironstratum.com/v1/action" \
  -H "Authorization: Bearer $KEY" \
  -F "model=molmoact2-so100-101" \
  -F "instruction=pick up the lemon and drop it in the red bowl" \
  -F 'state=[-0.53, 189.14, 181.41, 60.64, -3.60, 1.10]' \
  -F "image=@cam0.jpg" \
  -F "image=@cam1.jpg"

python

import json
import os
import requests

state = [-0.53, 189.14, 181.41, 60.64, -3.60, 1.10]

resp = requests.post(
    "https://api.ironstratum.com/v1/action",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    files=[
        ("image", ("cam0.jpg", open("cam0.jpg", "rb"), "image/jpeg")),
        ("image", ("cam1.jpg", open("cam1.jpg", "rb"), "image/jpeg")),
    ],
    data={
        "model": "molmoact2-so100-101",
        "instruction": "pick up the lemon and drop it in the red bowl",
        "state": json.dumps(state),
    },
    timeout=30,
)
resp.raise_for_status()

answer = resp.json()
print(len(answer["actions"]), "joint targets in this chunk")
print("cost of this call:", answer["usage"]["cost"])

lerobot

A LeRobot-format rig already speaks this checkpoint's vocabulary. The port's observation keys map straight onto the form fields: observation.images.cam0 and observation.images.cam1 are the two image files, and observation.state is the state array. The response's normalization block is the same artifact statistics the port ships, so a LeRobot dataset recorded on these keys aligns with the returned actions without any extra conversion step.

import json
import os
import requests

# LeRobot-format observation for an SO-100 or SO-101 step
observation = {
    "observation.images.cam0": open("top.jpg", "rb").read(),
    "observation.images.cam1": open("side.jpg", "rb").read(),
    "observation.state": [-0.53, 189.14, 181.41, 60.64, -3.60, 1.10],
}

resp = requests.post(
    "https://api.ironstratum.com/v1/action",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    files=[
        ("image", ("cam0.jpg", observation["observation.images.cam0"], "image/jpeg")),
        ("image", ("cam1.jpg", observation["observation.images.cam1"], "image/jpeg")),
    ],
    data={
        "model": "molmoact2-so100-101",
        "instruction": "pick up the red cube",
        "state": json.dumps(observation["observation.state"]),
    },
    timeout=30,
)
chunk = resp.json()
print(chunk["actions"][0], "first joint target")
print("normalization applied:", chunk["normalization"])

The full route reference, with every error code and limit, lives in the action route reference.

Benchmarks

Every number below carries its owner and its date. None of it is this platform's own run. The platform's rule is that its numbers publish only after they exist, with the method named; the refresh for this lane is later work, not a promise on this page.

LIBERO, in simulation, per suite. The paper's Table 8, read 2026-10-05. Success rates, percent:

Read that honestly. The top four sit within 1.2 points of each other on the average. LIBERO alone will not pick your model. Note also which rows are open: the license section below says why that matters more than any tenth of a point.

The same benchmark, re-run through the LeRobot port. The LeRobot docs report their own fine-tune of the LIBERO member for 10,000 more steps on eight H100 GPUs: 98.4 spatial, 100.0 object, 98.0 goal, 96.6 long-horizon, 98.25 average against the original 97.2. Dated, method stated, reproducible from their commands. That is what a healthy port looks like.

Real robot, zero-shot, out of distribution. The paper's Table 6 runs five tasks on the DROID setup, a Franka-class rig, with randomized camera poses and novel objects, 15 trials per task, scored as successful trajectories. One caution before the numbers: the row is the DROID fine-tune, not this checkpoint. It is the zero-shot evidence from a sibling checkpoint, pushed outside its training distribution.

That is the spread worth knowing about. In simulation the leaders sit half a point apart. On a real robot, the field spreads by more than 40 points. Simulation scores do not transfer to your table, in either direction.

Fine-tuned, real world, beyond the lab. The paper's eight-task real-world suite: MolmoAct2 places first on seven of eight tasks, 50.1 percent average against 35.1 for the runner-up, OpenVLA-OFT. On bimanual RoboEval, the paper reports 0.443 against 0.405 for pi05. A third-party fine-tuning benchmark run by Cortex AI, cited in the launch post, scores MolmoAct2 highest at 0.51, against 0.36 for OpenVLA-OFT and 0.32 for pi05, first on seven of eight tasks.

Latency, with owners named. Ai2's own numbers on one H100, from the launch post: about 180 ms for a single action call, 790 ms with depth reasoning on the Think model, and a claim of up to 37x faster than the 2025 MolmoAct. Community evidence, from a widely used SO-101 setup guide: the first chunk takes about 700 ms on an RTX 3080-class laptop GPU, then chunks arrive continuously while the arm runs. First calls are slow everywhere while the model warms up; measure after warm-up, not before.

Getting started

1. Read the primary sources. The SO100_101 model card, the base model card, the official repository, and the paper are all public. Every identity fact on this page traces to one of them.
2. Pick the checkpoint for your rig, then run dry. An SO-100 or SO-101 takes this checkpoint. Match the two cameras, feed the six-number state, and print actions before you let the arm move. The joint transform section above is the one to reread first.
3. Check the license box early. This family carries the Apache-2.0 license file, which permits commercial use; read it yourself at the LICENSE file. The contrast is sharp: the GR00T foundation weights from NVIDIA ship under a license that reserves commercial use to NVIDIA, a finding the platform documents in its GR00T license guide. If your project is commercial, that single file decides the shortlist before any benchmark does.
4. Watch the index, not this page. The models index is the live catalog. The pricing page renders the rate card for every listed row. The VLA page introduces the rest of the action model set.
5. Open the console when you build. The signup flow opens the prepaid wallet, the keys, and the billing history. Each key revokes alone, and the wallet balance is the spend bound. The shape above is the contract to write a client against.