What is a per-robot-hour? The pricing unit, defined

A per-robot-hour is one robot working for one hour, used as a unit of price. For hosted robot inference it is the honest unit. An hour of robot work converts, by pure arithmetic, into a known count of calls. Any per-call rate then turns into an hourly figure you can check. The same words also price other things. They price a wear counter on a used arm, a whole machine spread over its life, and a worker's replacement sold as a service. This page defines the unit, separates those senses, shows the conversion from hours to calls, and maps which vendors bill which unit today.

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

Last verified: 2026-10-26

Per-robot-hour

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. A robot running a policy loop issues a countable number of calls in an hour. The count comes from the loop's own settings, not from the seller. So the honest form of an inference price is two numbers: a count of calls per robot hour, and a rate per call. Multiply them and you have the hourly cost. Divide an hourly quote by the count and you recover the rate. That invertibility is what makes the unit trustworthy, and almost no hourly figure in the wild offers it.

A warning belongs inside the definition. Four different crowds use the phrase per robot hour, and they mean four different things. The senses do not convert without knowing which one is meant. A used-equipment dealer means a wear counter. A cost accountant means a whole machine amortized. A service vendor means a worker's replacement, hardware and staff included. An inference platform means the brain alone. The senses share an hour and nothing else. Each sense gets a section below. The table near the end names real quotes in each row, so you can sort any figure you meet before comparing it with anything.

Robot hour

The denominator of the unit is the robot hour itself: sixty minutes during which one robot is doing its job. That sounds plain, and in billing it is. Sellers count working hours, and conditions attach to them. One published rate comes from the palletizing service Tutor Intelligence. It runs 14 to 18 per robot-hour for the work their machine does. Conditions attach: a floor of 80 robot-hours a month, an 8,000 refundable deposit, and a 10,000 flat implementation fee (Tutor pricing page, read October 26 2026). That hour is a unit of delivered labor. The vendor says the rate is all-in: support, maintenance, and every model improvement they ship.

The phrase has an older life as a maintenance counter. A used-robot buyer meets that sense first. Industrial arms count several kinds of hours. Operation hours accumulate whenever the robot has been powered on, productive or not. Running hours count only the time it was actually working, tracked the way a car tracks mileage for oil changes. Servo hours count time on the servo amplifiers that drive the joints. Waiting hours count time powered on but idle. The hour meter usually lives on the controller. A buyer is told to ask whether the controller was ever swapped, because a swapped meter may belong to a different robot (Robots Done Right). None of those counters is a price. They are the machine's odometer. They matter here because they prove the hour came first as a measure of wear, and only lately became a measure of money.

One trap sits inside the billing hour: the charging gap. A robot that must rotate off shift to charge delivers fewer productive hours than the calendar suggests. A nominal per-hour rate then understates the cost per productive hour. A 2026 billing-units catalog puts it plainly: you provision extra robots to keep one continuously busy, and the true cost per useful hour climbs above the headline number. When you read a per-hour quote, ask which hour it counts: powered on, working, or productively working.

Machine-hour

The machine-hour is the unit's accounting ancestor. In cost accounting, the machine hour rate is the cost of running one machine for one hour. You take every annual cost tied to the equipment and divide by the hours it operates. The method exists to spread overhead fairly across products, and it has been standard practice for a century.

Every whole-robot hourly figure you meet is a machine-hour build-up in disguise. A parts-level teardown published in 2026 puts commercial automotive humanoid work at about 25 per robot-hour. That price is an operating cost, not a capital purchase. The math is honest: a machine running 4,000 hours a year at that rate bills about 100,000 a year. Labor-parity calculators do the same sum with more inputs. Purchase price spreads over service life. Maintenance and power add on. The total divides by the hours the robot actually works, then sits against a loaded human wage. Those tools are useful. They answer should we buy the machine.

What a machine-hour cannot do is price a hosted brain. The build-up divides the cost of one machine by the hours of one machine. A serving platform is the opposite shape. One machine's hour is shared by many robots at once. A policy call takes tens of milliseconds, and an hour holds 3.6 million of them. The cost of one robot's thinking inside that shared hour is a slice. The machine-hour method has no way to cut that slice. That is why the inference sense needs its own arithmetic, the call count. Lumping a hosted rate into a machine-hour table produces nonsense rows. The two units share an hour and divide by different things: one by ownership, one by work.

Calls per robot hour

This is the conversion that ties the unit to a bill. A hosted policy does not bill per camera frame. It bills per call, and one call returns 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 count is loop arithmetic, set by two numbers you control: your camera's frame rate and your model's chunk length. The reference stack documents the chunk knob directly. LeRobot's async inference guide calls it actions_per_chunk and shows a default of 50 (LeRobot docs).

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

The first row is the SO-arm class convention this site uses throughout. It means a 30 frame per second camera stream and chunks of 50 actions. Counting camera frames instead of chunks overstates a hosted bill by fifty times in that row. Your camera hands you 108,000 frames an hour. The bill counts 2,160 calls. The same hour can also be counted in actions or steps. At 30 frames per second, an hour holds 108,000 actions. A vendor's own worked example runs 115,200 steps per hour at 32 Hz. Frames, calls, actions, steps: four counters over one hour. Each converts into the others by arithmetic. Only one of them, the call, is what most hosted routes bill.

Chunk length is set by the model's training, not by the request. A shorter chunk reacts faster and multiplies the call count. A longer chunk runs smoother and cheaper. That one choice moves an hourly bill by a factor of three or more before any rate is chosen.

The four senses in one table

Every row below was read or verified October 26 2026. Sort any hourly figure you meet into one of these rows before comparing it with another.

A fifth row almost fits and should not: parity claims. Essays and forecasts say a robot hour will cost less than a worker hour by some year. Those are arguments about the future of the labor row, not offers. One widely quoted figure says a humanoid costs a worker-like amount per hour. In at least one documented case it is a chief executive's benchmark for payback, not a price anyone can pay.

What inference vendors bill instead

No vendor was found, as of October 26 2026, that bills robot inference by the robot hour. What exists instead is a spread of meters, each named here with its party and date.

The agi.diy row is the most instructive, because its meter looks tiny and is not. A hundredth of a cent per action, at the SO-arm convention of 30 frames per second, means 108,000 actions per robot hour. That multiplies out to 10.80 per robot hour. This is not a criticism of the price. Serving small policies for hobby arms is a real service, and their terms are transparent: every returned action is billed, executed or not. It is a demonstration of the unit's whole point. Stated per action, two offers can look a hundredfold apart while costing the same per hour. Stated per robot hour, they compare honestly. A token meter resists comparison for the same reason. A robot hour's token count depends on how many cameras, how large the images, and how much reasoning a call carries. No robot vendor publishing tokens publishes that count.

Why the robot hour is the honest unit

Pull the threads together. An hour of robot work is not a price. It is a count of calls waiting for a rate. The count comes from your loop. The rate comes from the seller. Everything else in an hourly figure is bundling, and bundling is where numbers go to hide.

Three questions make any hourly robot figure comparable. Which sense is it: machine, labor, or inference? What is the count: calls, actions, steps, or tokens per hour? What is the rate, dated? An answer that supplies all three can be checked with a pencil. An answer that supplies none of them is marketing, not math.

The unit on this platform

This platform serves robot policies over a hosted action route. One call is one billed request. The platform publishes its own worked basis for the unit. The derivation page works it end to end: 2,160 calls per robot hour at the written-record rate for the pi05 model id equals 6.48 per robot hour. Every input is dated, and the method re-runs on your own loop. It is the robot inference cost derivation. The honest state, in plain words: these rows sit in the platform's model data with their rates set, and they are not on the public list as of 26 October 2026. No live rate is quoted here. The models index is the live catalog. Listed rates render on the pricing page.

The sibling pages each take one question further. Per-call against per-robot-hour billing, as a buyer's decision, is the pricing units guide. When your own card wins is the break-even guide. Habits that keep any metered route honest sit in the bill shock guide. If you serve policies yourself, the policy server guide defines the program doing the serving. To try the arithmetic against a real route, sign up, create a key, and count your own loop for one hour.

Frequently asked questions

Is a robot hour the same as a machine hour?

No. A machine hour spreads the cost of one whole machine over the hours it runs: purchase, maintenance, power. A robot hour, in the inference sense, prices the thinking alone for one robot over one hour. Many robots can share one machine's hour. Machine-hour figures answer should we buy the robot. Inference-hour figures answer what does the brain cost per hour of work.

How many calls is one robot hour?

Divide 3,600 by the seconds one chunk covers. At 30 frames per second with chunks of 50, one call covers about 1.7 seconds of motion, so an hour holds 2,160 calls. Chunks of 15 at the same frame rate make 7,200. The formula and the table are above, and the derivation page works the money end.

Does anyone sell inference by the robot hour?

As of October 26 2026, no vendor was found billing robot inference per robot hour. Google bills tokens, a community service bills actions, one provider bills steps, one platform meter bills seconds, and the newest foundation-model gateway is unpriced. Labor services do bill per robot hour, with hardware and staff in the hour. The inference sense of the unit has a definition and a worked basis on this site, and no live biller yet.

Why does a per-action price look so small?

Because the hour is large. A hundredth of a cent per action sounds like nothing. Then you multiply by the 108,000 actions in a 30 frame per second hour. That lands at 10.80 per robot hour. Small per-unit prices are honest only next to their per-hour conversion. Demand the conversion.

What should I ask when someone quotes a cost per robot hour?

Three things: which sense (machine, labor, or inference), which count (calls, actions, steps, or tokens per hour), and which dated rate. With those three, the quote checks itself. Without them, you are reading marketing, not a quote.

The unit is the fix for a market that quotes hours, sells calls, and compares neither. Define the sense, count the calls, date the rate. The worked money math lives on the derivation page, and listed rates for every listed model render on the pricing page.

Last verified: 2026-10-26