Robot inference API: what one is and where each lane stands
A robot inference API is a hosted endpoint that runs a robot's neural network for it. Your code sends what the robot senses. That means camera images, an instruction, and the arm's state as numbers. The endpoint answers with what the robot should do next. The answer might be a chunk of motor actions, a mask, a depth map, or a decision. And it has to land on a clock. The name is young, so this page does the naming job. It maps the three model classes and their call contracts. It states the frequency law that decides which part of a robot can be hosted at all. It reads who publishes rates, and in what unit, with dates. And it states where each of this platform's robot lanes stands as of October 26, 2026. Some rows serve today. The action rows are not on the public list. The models index is the live catalog, and every state claim here carries its date.
Last verified: 2026-10-26
What a robot inference API is
The trade is simple. You send what the robot senses. You get back what the robot should do next. The hosting part means the model lives on someone else's machine. Your robot calls it like it would call any web service.
The request carries three things at category level. Images from the robot's cameras. A short instruction in plain language. And the robot's own state as an array of numbers. A perception call drops the instruction. A reasoning call drops the state. The answer carries the class's output: actions for an arm, masks or depth for a vision call, text and decisions for a reasoning call. Nothing in the request needs a robotics SDK. A plain HTTP client is enough, the same tool you would point at a language model.
That is also where the confusion starts. The phrase inference API already belonged to the language model world. Search the robot phrase today and you meet three impostors. One is the LLM side itself, glossary pages that define an inference API as a prompt in, text out service. One is a search engine feature that reuses the exact words for its own machine learning endpoints. One is history: Google once ran a Cloud Inference API that was a time-series product, with no robot in it anywhere, and its docs are gone today. The robot sense of the phrase is real, and older than the current boom. A 2020 paper called RILaaS, Robot Inference and Learning as a Service, served robot policies over the cloud. That was six years before foundation models made the idea cheap.
The short decoder: if the answer steers a motor, it is the robot kind.
Three model classes, three contracts
The category splits into three classes by what they read and what they return. The split matters. Each class has its own request shape, its own latency budget, and its own metering unit.
| Class | Reads | Returns | Meters by |
|---|---|---|---|
| Action (VLA) | Cameras, instruction, robot state | A chunk of motor commands | The call |
| Perception | Camera frames | Masks and depth maps | The image |
| Reasoning | Scene video and text | Decisions, plans, calls to other systems | The token |
Action models are the heart of the field. A vision language action model, or VLA, looks at the cameras, reads the instruction, and writes the next short run of motor commands. That run is called an action chunk. Google DeepMind started the class in 2023 with RT-2 (paper, 2023). The chunk covers the next fraction of a second. The robot runs it, then calls again with fresh images. The action route on this platform meters by the call. That fits a loop better than tokens. A call is the thing your robot schedule actually makes.
Perception models answer what the robot sees. A mask model returns an outline for each object you ask about. A depth model returns how far away each part of the scene is. The output feeds grasping, obstacle checks, and workspace tests. These lanes meter by the image. That is the natural unit: one frame in, one answer out.
Reasoning models answer what the robot should decide. Google describes its Gemini Robotics ER endpoints as vision language models for embodied reasoning: precise scene understanding, task planning, and work across many robots (Google's pricing page). Reasoning rows do not write motor commands. They plan, and hand the doing to an action model or a lower layer. That is why they meter by the token, like a language model. It is also why they can run slower than a policy loop.
The loop decides what can be hosted
No page in the current search results states the rule that governs this whole category. Here it is. A robot's control stack is a set of loops running at very different speeds. Only the slowest loop can be hosted.
Read the stack from the bottom. Motor current loops run at tens of thousands of cycles per second. Joint servo loops tick at ten thousand and up. Whole-body control runs at hundreds to a thousand cycles per second. The policy, the neural network that decides what to do, runs at tens of calls per second. A 2026 study from NVIDIA researchers frames about ten calls per second as the acceptable floor for a policy (VLA-Perf study, 2026). The same study models a pi 0 class policy at about 19 cycles per second on a robot-grade Jetson module, and several hundred on datacenter hardware. The original pi 0 paper reports a control loop at 50 cycles per second, with fresh inference twice a second, every 25 actions (pi 0 paper, 2024).
The network math follows from the tiers. A policy loop at tens of hertz has a budget of tens of milliseconds. A good connection spends single-digit milliseconds of it. That is not theory. Physical Intelligence runs remote robot inference in production today. The published case study reports 10 to 15 milliseconds of added network overhead, with deployments pinned to regions close to the robots (Modal case study, 2026). The servo tier has no such room. A one-millisecond deadline does not survive a round trip. The joints never call the cloud. A robot inference API serves the thinking tier of the stack, full stop.
One more result deserves plain words. A hosted policy answers in chunks, so a slow answer does not have to stall the arm. The robot keeps running the current chunk while the next one computes. That pattern is now standard in the open tooling. It is the difference between a laggy demo and a usable loop.
Who serves what in October 2026
The seller field is small, young, and split by unit. This section is dated October 2026. Treat every sentence here as a snapshot.
Google is the frontier name with a public price. Its Gemini Robotics ER endpoints sell embodied reasoning by the token. The published rates double on the first of January 2027 (Google's pricing page). That dated fact is worth checking before you budget a year. The endpoints plan and organize work. They do not drive motors directly.
Physical Intelligence, the lab behind the pi models, opened its API beta on October 13, 2026 (announcement, 2026). The workflow is upload data, fine-tune on managed compute, then serve through a hosted gateway. Access runs through an application, and teams join in batches. No public rates exist. The same lab runs its own remote inference in production, which is the strongest public evidence that the hosted policy tier works.
Around those two names, the first small specialist hosts appeared in 2026. Some print rate cards priced per action, with an hour estimate beside each model. The big general hosts, the ones that serve every open language model, have not picked up the open action models as of October 26, 2026. The census guide listed with this page carries that check in full, host by host, with dates.
Why try a hosted action model at all when the weights are open? Two reasons keep coming up in builder threads. First, the machines. A 7 billion parameter policy wants a serious graphics card, and not every team owns one. Second, the silent failures. A policy run with the wrong scaling numbers does not error out. It just moves the arm wrongly. A hosted lane returns the scaling numbers it applied with every answer. That turns one class of silent failure into something you can check.
Where this platform's robot lanes stand
This is the dated state section. It is the core job of a hub page. Each statement below mirrors the platform's own model data. The models index is the live catalog.
The action route is the VLA lane. It meters by the call. It holds eight rows in the platform's model data. The set spans the pi 0.5 family with its DROID and LIBERO tunes, plus SmolVLA, OpenVLA-OFT, ACT, X-VLA, and the MolmoAct2 tune for the SO-100 and SO-101 arms. As of October 26, 2026, none of the eight is on the public list. The VLA lane page carries each model, its sizes, its sources, and the full call contract.
The vision route is the perception lane. It meters by the image. Two of its three rows are on the public list, confirmed by the October 6, 2026 requests. Those two are sam2.1-base, the base mask model, and da3-small, the small depth model. The large mask tier is not on the list. The vision lane page carries the pair and the route contract.
The reasoning pair rides the chat route. Both rows went on the public list October 6, 2026. Those two are molmo2-er and cosmos-reason2-2b. They meter by the token. They answer in text, and they serve robot-scene reasoning alongside general vision language work. The chat category is their catalog surface.
The pattern to read from those three paragraphs: states differ by class and by row inside one platform. Any page that tells you a whole category is live or dead, without dates and without naming its rows, is guessing. Demand the dates.
What it costs to run one
This section sets units, not numbers. The action lane meters by the call. The vision lane meters by the image. The reasoning rows meter by the token. Every rate that exists renders on the pricing page from the platform's own model data. A change lands there first. The pricing guide explains how metering and the wallet work end to end.
Spend on any lane draws down a prepaid wallet. The balance is the hard stop. A call that arrives after the balance is gone is refused with a named error instead of running a debt. A refused call is never billed. That matters more on a robot than on a chatbot. A robot can loop all night.
For planning, the honest unit is not the call or the token. It is cost per hour of robot runtime. Your loop rate, times the metering unit, times the hours. The cost guide listed with this page works that math with measured numbers. The pricing-unit glossary listed beside it fixes the vocabulary. A robot at ten calls per second makes about 36 thousand calls an hour. Multiply that by any per-call rate you see published anywhere, and you have the real hourly shape of the decision.
Running the models yourself
Every action model named above ships open weights. The small ones truly run at home. ACT and SmolVLA train on a single consumer graphics card. The big ones, OpenVLA-OFT and the pi 0.5 family, need a serious machine to train and less to serve. Two open toolkits carry most of the work. One is LeRobot from Hugging Face (LeRobot). The other is openpi from Physical Intelligence. If you own a low-cost arm, the community path from box to trained policy is written down step by step.
So when does hosting earn its keep? Not on the model itself, since the weights are free. Hosting earns it on the parts around the model. That means an endpoint that stays up through a long session. It means metering and spend history you did not have to write. It means scaling numbers returned with every answer. And it means the freedom to try a second model by changing one string. Teams whose robot is a product, rather than a research project, tend to make that trade. The break-even question, one card against one account, is what the Jetson-versus-cloud guide listed with this page answers. The cost guide listed beside it answers the cloud side with measured numbers.
Getting started
- Open a console account. The beta is invite-only for now. The wallet, the keys, and the spend history live there, and you can start at the signup page. An account opened today covers every lane the platform lists.
- Read the rates once, in one place. The pricing page renders every listed row's rate from the platform's own model data. The pricing guide explains the units.
- Pick the class, then the lane. Actions: the VLA lane page. Perception: the vision lane page. Reasoning: the chat category. Each lane page carries the exact request shape.
- Read the guides listed with this page. The host census covers who serves robot models across the big general hosts. The rate card guide reads the frontier rate card line by line. The access guide explains how the Physical Intelligence waitlist works. The cost guides carry the measured per-hour math. The Jetson guide carries the local side. And the vision guide covers masks and depth for robots.
Everything else the platform serves is mapped on the models index. Chat, speech, transcription, embeddings, rerank, document parsing, image generation, and the robot lanes all draw from one wallet.