MolmoAct2 API pricing: no per-call price exists, one card carries it, and the per-robot-hour math

MolmoAct2 API pricing has no per-call rate to look up. As of 26 October 2026, no seller lists MolmoAct2 at a published per-call price. One market rate card does carry the model, and it bills per million tokens in and per million actions out. The weights are open and Apache-2.0, so the price you can act on today is a rented GPU by the hour. The other option is this platform's written record for the molmoact2-so100-101 model id. This page shows every dated check, then works the per-call and per-robot-hour math at the model's own 30-step horizon.

Last verified: 2026-10-26

What you are actually trying to price

MolmoAct2 is an open family of action reasoning models from the Allen Institute for AI. The policy reads camera images, the robot's joint state, and a task sentence, then returns the motor commands for the next stretch of motion. The release post is dated 5 May 2026, and the paper, MolmoAct2: Action Reasoning Models for Real-world Deployment, is on arXiv. The official repository carries the weights, the training code, and the evaluation code. The publisher's own 28 May update reports more than 400,000 artifact downloads in the weeks after the release. Capability details for this platform's row live on the model's own page: molmoact2-so100-101.

One property of the checkpoint sets the pricing unit. A call does not return text. It returns an action chunk, and the length of that chunk comes from the control rate of the data the model was trained on. The paper is explicit for the SO-100 and SO-101 arm: "a 30-step action chunk for the 30 Hz control rate." One call therefore buys about one second of motion. The LeRobot port agrees, with policy.chunk_size and policy.n_action_steps both set to 30 by default in the shipped policy config.

All amounts are United States dollars written as bare numerals. Every rate below carries its party and its date.

The host census, checked today

People search "molmoact2 api pricing", "molmoact2 api", "molmoact2 cost", and "ai2 molmoact api". Every one of those queries wants a rate card row. As of 26 October 2026, one published rate card carries the model, and the big model hosts carry none of it. Here is what each place that looks like a seller actually offers.

Three notes on this table. First, every row carries its own date, because host states move. Second, the last three rows are new platforms. They did not exist when most "no one hosts robot models" claims were written, and two of them now price the action tier in the open. That is the lesson in this table. An absence claim is a dated snapshot, not a permanent fact. Third, the agi.diy row is the sharpest one. Its meter bills every action a call returns, and it publishes per-call prices for the rows it serves. Its custom-checkpoint path takes three policy families, and MolmoAct2 is not one of them.

What the absence is not: a license wall. The weights and the code carry the Apache-2.0 license, so there is no royalty and no fee on the use of the weights themselves. The repository also states the intended use as research and educational, in accordance with Ai2's Responsible Use Guidelines. Read that before you ship a product on it. What is missing is not permission. It is a seller who has done the serving work and published a per-call rate.

The one rate card that carries MolmoAct2

abstract.inc publishes a full action-tier rate card, read today. Six robot models sit on it, each priced per million tokens in and per million actions out, with a printed hour estimate beside each row. The card states its own basis: an hour estimate is one hour of a 30 hertz control loop, which is 108,000 actions.

The MolmoAct2 row reads input 0.50 per 1M tokens, cached input 0.05 per 1M tokens, and output 1.40 per 1M actions. It prints an hour estimate of 0.99.

Two things to know about that row. First, it is not a per-call price, and no per-call price for this model is published anywhere as of 26 October 2026. Second, its hour estimate is not a flat rate. The action side bills on every action the model returns, so it follows your control rate and your chunk length. The token side bills on what your cameras send. How many tokens that is depends on your camera setup and your frame rate, not on the model. That is why the card can print one number and still leave the hour math to you.

Their printed estimate is worth reading against its own arithmetic. On their basis the action side alone comes to about 0.15 for the hour, and the rest of the 0.99 is the token side. A different camera setup moves that split, so treat 0.99 as a starting point to check, not a number to budget.

Why the chunk length decides the bill

This is the part most price pages skip. A robot policy is billed per call, and a call returns a chunk of actions. The number of calls in an hour is set by two numbers you control: how fast your loop runs, and how many actions each call covers.

calls per robot hour  =  3600 x frame rate / chunk length

For MolmoAct2 the chunk is not a free parameter. The paper gives each embodiment a chunk of about one second of motion. That is 30 steps at 30 hertz for SO-100 and SO-101, 15 steps at 15 hertz for DROID, and 10 steps at 10 hertz for the LIBERO recipe. Each one buys about one second of motion per call, so the native loop makes the same number of calls whatever arm you use.

That last row is where the 108,000 actions in the market card's hour estimate come from. The same action count, reached with a different chunk length. It also explains why a per-call price and an action price are not the same number. The action count is fixed by your loop, and the call count is fixed by your chunk.

Chunk length is the whole lever on the hourly side. Halve the chunk and you double the hourly bill at a fixed per-call rate. Double it and you halve it. A 10 action chunk on a 30 hertz loop is 10,800 calls an hour. That is three times the bill of the model's own horizon on the same loop.

This platform's written record

This platform keeps a written record for the molmoact2-so100-101 model id on its action route. As of 26 October 2026, the facts of that record are these. The row sits in the platform's model data, and the lane is metered per call. Its rate is set at the midpoint of the flagship band. The model is not on the public list, and no date attaches to that. Only listed rows render in the table below, and the models index is the live catalog. A written record is not a launch.

Budgeting that record is arithmetic on two named inputs:

cost per robot hour  =  C x P

C:  calls per robot hour, from your loop
P:  per-call rate, read off the rendered table above

The numeric form. On this model's own SO-100 and SO-101 horizon, one robot hour holds 3,600 calls, so the written-record rate works out to 18.00 per robot hour. Work it forward from there. A hobby arm running 10 hours a month spends about 180. A 160 hour work month runs about 2,880. The other robot pages use a 50 action chunk on a 30 frame per second camera. That convention gives 2,160 calls an hour and reads 10.80 for the same rate. Same price, different loop. One sensitivity line: halve the chunk and you double the hourly bill at any fixed per-call rate, and double the chunk and you halve it.

The bundle band printed in the fence is a different unit. It is a price per robot hour on the flagship class, so it converts to a per-call rate by dividing it by your call count. On this model's own horizon that band sits below the 18.00 the per-call route works out to, and the gap between the two is the whole unit question. One route bills you for every chunk you ask for. The other bills you for the hour the robot works. Only the call count tells you which one fits your loop.

The wallet floor is the point of the shape. An unattended robot loop cannot run up a credit line. A refused call bills nothing. The general argument for prepaid floors under robot and agent workloads, with documented runaway cases, is the API bill shock guide.

What self-hosting costs instead

With no public per-call rate to buy, the open weights are the path you can price today. The publisher's own materials set the envelope. The paper reports inference on a single H100 at an action horizon of 10. It reads 23.02 hertz for the original path, 27.39 hertz with a reusable cache, and 55.79 hertz with CUDA graphs on, a 2.42 times speedup.

The card rental side of that path has a named party and a date. Read 26 October 2026 on the RunPod pricing page: the 24 GB A5000 at 0.27 per hour, the 3090 at 0.50, the 4090 at 0.89, the L4 at 0.59, the A100 PCIe at 1.79, and the H100 SXM at 3.99. Rates move, so treat every rate as a snapshot with a date.

The edge option is not a rumor. AMD's own engineering team published a working path for this model. It runs on a single desktop mini PC, with no cloud and no accelerator, and a browser driven robot control panel on top. The ROCm blog post is dated 30 September 2026 and carries the container recipe, the LIBERO evaluation harness, and an open loop replay on DROID episodes.

To compare a card hour with a per-call API, you need one more input: the time one call takes on your card. No publisher publishes that for your setup, so keep the comparison symbolic:

GPU cost per call  =  R x t / 3600

R: hourly rate for the card, from a dated price page
t: seconds per call, from a benchmark you trust for your setup

One sensitivity line. Idle time, restarts, and your own engineering sit on top of the raw card time. Treat the output as a floor at full duty, never a bill. The deeper local-versus-hosted treatment, with amortization and break-even tables, is the VLA break-even guide.

If you need it on a different arm

This is the question search engines attach to this model, and it has a straight answer. The exact question is: "Are you planning to deploy MolmoAct2 on a specific robot hardware setup (such as DROID, SO-100, or Bimanual YAM) or integrate it into a custom LeRobot pipeline?" MolmoAct2 ships as a family, and the family is meant to be adapted.

The base checkpoint is a foundation checkpoint, not a deployment policy. Its own model card says so. It is meant as a starting point for further robot fine-tuning, and it deliberately carries no policy inference code. If your arm resembles one of the released ones, start from that fine-tune. The SO-100 and SO-101 checkpoint covers the low-cost arm family, with DROID for the Franka and Bimanual YAM for the two-arm setup.

Three practical points for the fine-tune itself. The training path is LeRobot, so you record your task in LeRobot's dataset format and train with the same scripts the publisher used. The docs keep the action expert trainable in every setting, including the low-memory options, and they say that matters for performance. And the normalization statistics are not optional. The policy loads its action and state normalization from norm_stats.json through the policy.norm_tag setting. That setting also carries the action horizon, the prompt metadata, and the image key order. A policy run against the wrong tag moves the arm and the motion is wrong. The normalization statistics guide covers that failure family, and the wider capability record for the model is on the MolmoAct2 guide.

What to do now

1. Budget two routes, not one. The per-call route, priced in the table above, and the self-host route, priced by the card hour, are the two options a robot builder can act on today. The market card row is a third, and it is priced per million tokens and per million actions.
2. Serve it yourself first. Pull the fine-tune for your arm, run the LeRobot path, and measure your own seconds per call. That number is the input your hosting decision needs, and no price page can give it to you.
3. Write your client against a published contract. This platform's action route documents every field: multipart form data in, the action chunk, the applied normalization block, and the call count with its cost on every answer. The full field list is on the action route page and in the run-action reference. Your driver can be finished and tested before any spend begins.
4. Budget metered calls from the live table. When a row is listed, its rate renders on the pricing page. You can sign up and create a key without a call from us, and the prepaid balance is the spend stop.

Frequently asked questions

Is there a MolmoAct2 API?

One priced per million tokens and actions, and no per-call price. Checked on 26 October 2026: the Hugging Face inference surface returns no serving entry for the base checkpoint or any fine-tune. Replicate, fal, DeepInfra, and the multi-provider router list none of it. The publisher ships weights, code, and two FastAPI servers, with no product and no checkout. abstract.inc carries a MolmoAct2 row on its rate card. agi.diy publishes per-call prices for its own rows, and its custom-checkpoint path does not take a MolmoAct2 checkpoint. Robotic Inference covers MolmoAct2 behind a registration or pilot gate with no published rate. The census table above is the part that goes stale first, so check its dates.

What does MolmoAct2 cost per robot hour?

Three honest answers, in three units. This platform's written record for the molmoact2-so100-101 model id converts to 18.00 per robot hour on this model's own horizon of 3,600 calls. It reads 10.80 on the 50 action convention the other robot pages use. The market card prints 0.99 for its own MolmoAct2 row on a 30 hertz loop of 108,000 actions. And a rented 24 GB card costs 0.27 to 0.89 per hour on RunPod today, plus your engineering time and the benchmark you still owe yourself. Any figure you meet elsewhere should state its unit, its party, and its date.

Can I fine-tune MolmoAct2 on my own robot arm?

Yes, and the publisher built the path for it. The base checkpoint is a foundation checkpoint for exactly that. The family ships fine-tunes for the Franka, the SO-100 and SO-101 arms, and the bimanual YAM setup. Training runs through LeRobot, with the action expert left trainable in every setting. The one thing you must not skip is the normalization statistics. The policy reads them from norm_stats.json through the policy.norm_tag setting. That setting also carries the action horizon, so the wrong tag gives you wrong motion rather than an error.

What does one MolmoAct2 call return?

An action chunk, not text. For the SO-100 and SO-101 arm the checkpoint was trained with a 30-step chunk at 30 hertz, so one call covers about one second of motion. The LeRobot port sets policy.chunk_size and policy.n_action_steps to 30 by default. The chunk length belongs to the model, so it is not a request knob. It is the number your hourly bill turns on.

Is MolmoAct2 free?

The weights and the code carry the Apache-2.0 license, so downloading, fine-tuning, and serving them commercially cost nothing in license fees. What you pay is compute: the card hours to fine-tune and serve, your recording time, or a per-call rate if you buy hosted access. This page's fence quotes the only written per-call record we know of, dated today.

The short version: no per-call MolmoAct2 price exists anywhere today. One market card carries the model in token and action units. This platform's written record works out to 18.00 per robot hour on the model's own 30-step horizon. Listed rates live on the pricing page. Sign up to create a key and budget metered calls.

Last verified: 2026-10-26