VLA API pricing: per call vs per robot hour, converted

Robot APIs price their work in two units. Per call is one request that returns a chunk of actions. Per robot hour is the cost of one robot working one hour. The two are not rivals. Your control loop converts one into the other by plain math. At the SO-arm convention of 30 frames per second with chunks of 50, one robot hour holds 2,160 calls, so any per-call rate times 2,160 is an hourly cost. Per-action meters ride 108,000 actions an hour. This page defines both units, works the conversion in the open, converts every dated market rate into robot hours, and shows one seller's price list in both units at once.

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

Last verified: 2026-10-26

The two units, defined

Per call is the unit buyers know from the language-model world. One request in, one answer out, one charge. On a robot action route the answer is not text. It is an action chunk: a run of future joint targets computed in one pass. The robot works through the chunk while the next one computes. The LeRobot reference stack documents the knob directly. It ships a default of 50 actions per chunk. The chunk length is set by the model's training, not by the request.

A per-robot-hour is one robot working for one hour, used as a unit of price. A per-robot-hour is the cost of keeping one robot at work for one hour, quoted as one number. When the thing being priced is hosted inference, that number is not a guess. The count of calls in the hour comes from your loop. The rate comes from the seller. The two multiply. The unit glossary separates the other senses of the phrase, from used-arm wear counters to whole-machine cost spreads. This page stays on the inference sense.

Between the two main units sit the other meters you will meet on a rate page. A per-action meter bills every returned action in the chunk. A per-step meter is the same idea under a training-world name. A per-token meter bills what the model reads and writes. A per-second meter bills wall-clock time on the platform's compute. Each of these reduces to a robot hour once you know one thing: how many metered units an hour of your robot holds. That count is loop math, and it is yours, not the seller's.

The conversion: from a rate to an hour

The count comes from two numbers you control. One is your camera's frame rate. The other is your model's chunk length.

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

The first row is the SO-arm convention used throughout this site. A 30 frame per second camera stream with chunks of 50 actions makes 2,160 calls an hour. A per-call rate times 2,160 is the hourly cost. Divide any hourly quote by 2,160 and you recover the per-call rate. The conversion inverts. That is what makes an hourly figure checkable instead of magical.

Action meters convert the same way, with the frame rate alone. At 30 frames per second an hour holds 108,000 actions, whatever the chunk length. That is the factor to hold in your head when a per-action price looks small.

Chunk length moves a per-call bill but not a per-action bill. Chunks of 15 triple the call count of chunks of 50 at the same frame rate. A shorter chunk reacts faster. It also costs more per hour at any fixed per-call price. One knob, fixed at training time, moves an hourly bill by a factor of three or more before you touch a rate.

What the trackers list, and what it means for a robot loop

Price trackers now carry robot models. The LiteLLM model page lists Gemini Robotics ER 2 at 1.00 in and 5.00 out per million tokens, cache reads at 0.10, checked October 26 2026. The AI Signal page carries the same rows. It ranks the input price 24th from the bottom of the 75 models it tracks. The rates are correct. Both trackers read them off Google's pricing page. That page lists ER 2 input at 1.00 per million tokens through December 31 2026, then 2.00 from January 1 2027. Output runs 5.00 now and 10.00 from the same date.

What the tracker rows cannot tell you is what a robot pays. Two gaps sit inside them.

First, the worked examples are writing workloads, not robot loops. LiteLLM's own page prices 1,000 requests of 2,000 input and 500 output tokens at 4.50. AI Signal's calculator starts from a million input and 200,000 output tokens. A robot hour at the chunk convention is 2,160 calls carrying camera images. No tracker or vendor publishes the token size of those calls. A rate without its hour factor is a mood, not a budget.

Second, the listed model is the brain, not the arm. Google's own model page describes ER 2 as a high-level brain. It hands off motor execution to a separate, lower level vision-language-action model (DeepMind). The priced endpoints are reasoning endpoints. The policy route a robot loop calls at control rate is a different market with different meters: per call, per action, or per step. The split shows in the tracker's own machine file, pulled today. Its only robotics rows are the Gemini reasoning family, all token-metered. That is five rows in a three-megabyte catalog of per-token prices. Zero per-call or per-action rows exist in it.

The market's rates, converted to robot hours

Every row was read or verified October 26 2026. Rates move. Carry the date with the number.

Read the table as a unit lesson before you read it as a price rank. The community service bills a tenth of a cent per action. It lands at 10.80 an hour. The platform meter bills a quarter of a cent per second. It lands at 9.00. The self-managed step row lands near 2, because you supply the labor and the standing software. Stated per unit, these offers sit more than a hundredfold apart. Stated per robot hour, they differ by about five to one. The one major-cloud rate on the list cannot be converted at all. That absence is the most useful fact in the table. A token price without a token count is not yet a robot price.

The two newest entrants deserve their dates. abstract.inc publishes a full action-tier price list. Six models, each priced per million tokens in and per million actions out, with a printed hour estimate per model. Their pi0.5 row prints 0.85 an hour. Their rho row prints 1.00. Their molmoact2 row prints 0.99. agi.diy prints per-call prices on top of its per-action meter. The smolvla route, serving 50-action chunks, prints half a cent per call. Both cards were verified today. Neither appeared in the market sweep this site ran one day earlier. The action tier is being priced in the open now. Every card in it still leaves the hour math to you. Physical Intelligence opened a hosted fine-tune and inference beta on October 13 2026. Its page carries no pricing terms. Google's own vision-language-action model, the one that actually moves motors, has no public rate at all. Only the reasoning endpoints are priced.

Both units on one card

This platform meters its robot action route per call. The table below is generated from the platform's model data at render time. It always shows the listed catalog with its listed rates. This page does not type those numbers in prose. The fence below carries the rows this page's lane math uses, verbatim values from the platform's model data as read on 2026-10-26: the small-class floor row, the flagship-class midpoint row, and the flagship bundle band. That bundle band is the form continuous-duty buyers ask for first.

With the rate side anchored to that table, the lane math is two named variables:

cost per robot hour  =  C x P

C:  calls per robot hour, from your loop, 2,160 at the SO-arm convention
P:  price per call, from the rendered table above

The bundle band and the per-call math meet where they should. A bundle in the flagship band printed in the fence is the same money as a per-call rate between roughly 0.0012 and 0.0019 at 2,160 calls. That sits at the small-class end of the card. Sensitivity is one line: halve the chunk and you double the hourly bill at any fixed per-call rate. Double the chunk and you halve it. The full derivation, with the hardware side and the break-even tables, is the robot inference cost derivation. There, 2,160 calls at the written-record rate for the pi05 model id yield 6.48 per robot hour.

The honest state of these two rows, in plain words. The smolvla model id and the molmoact2-so100-101 model id sit in the platform's model data with their rates set. They are not on the public list as of 26 October 2026. The models index is the live catalog. Every listed rate renders on the pricing page.

Which unit should you buy

Let duty pick the unit. A weekend arm running two hours a week makes under 5,000 calls a week. Per-call pricing with a prepaid wallet caps the spend at what you use. An hourly or monthly bundle would buy hours you will not burn. A demo robot running all day, ten hours or more, makes over 150,000 calls a week at the convention. A per-robot-hour bundle turns a variable bill into a flat one. The seller, not you, carries the idle-time risk between calls. If your duty sits between, price both ways on your own call count before signing anything. The conversion above is four lines of math.

The managed-versus-self question that search engines attach to this topic also has a number answer, not a taste answer. The break-even guide works the crossover in robot hours per month between a per-call route and your own card. Whatever you pick, a prepaid wallet with a hard balance beats an open postpaid line for anything metered per second or per action. Those meters run while you sleep. The habits that keep metered routes honest are in the bill shock guide.

Frequently asked questions

Is VLA API pricing per call or per token?

Both exist, and they are not the same market. The one major cloud with public robot rates prices tokens. Its priced rows are reasoning endpoints, not the policy route a robot loop calls at control rate. The action tier that moves arms is priced per call, per action, or per step by the specialists listed above, dated. If a page quotes you a token price for robot work, ask for the token count of one robot hour. Without it, the number does not convert.

Which is cheaper, per call or per robot hour?

Neither, at honest math. A per-call rate times your call count is an hourly cost. A bundle divided by the same count is a per-call rate. Price differences between sellers are real. Unit differences are not. Compare everything per robot hour first. Then let your duty cycle pick the meter: low duty favors per call with a prepaid cap, and continuous duty favors a flat hourly bundle.

Why does a per-action price look so small?

Because the hour is large. A tenth of a cent per action, the community rate above, is 108,000 actions an hour at 30 frames per second. That lands at 10.80 per robot hour. Small per-unit numbers are honest only next to their hour factor. Demand the factor. Or do the math yourself: the metered units in one hour, times the rate.

Can I convert the Google ER 2 token price into an hourly robot cost?

Not from public data. Google's card gives input and output rates per million tokens and a doubling date, January 1 2027. The trackers republish those rates faithfully. No party publishes the token count of a robot hour on that endpoint. It depends on camera count, image size, and how often the brain is called. None of that is on any rate page. Until someone publishes that count, the honest conversion is a dashed cell, not a guess.

Two units, one hour of robot work, every rate dated. The listed catalog with its rendered rates is on the pricing page. To run the conversion against a real route, sign up, create a key, and count your own loop for one hour. The program that serves policies when you self-host is defined in the policy server guide. The per-model rate cards for the models named here start at the Gemini rate card guide.

Last verified: 2026-10-26