Can a small robot use a model it cannot run itself?

Why can't a small robot just run the model locally?

Most capable navigation and manipulation models are large. They were trained on data that demanded significant compute, and they need similar compute at inference time. A small robot — one with modest onboard processing, a tight power budget, or both — simply cannot hold that model in memory, let alone run it fast enough to be useful.

The straightforward response is to offload. The robot sends its sensor readings — camera frames, distance measurements, joint states — over a network connection, and a machine with the necessary compute sends back a sequence of moves. The robot does not need to understand the model; it only needs to execute what it receives before the next answer arrives. This is not a new idea in robotics, but the infrastructure around it matters enormously.

What is a policy host, and why does the middle layer matter?

A policy host is a GPU machine that answers a robot's observations with its next moves. The robot pays the host per answer from its own wallet. The host earns from that. The owner of the robot never leaves the page to arrange any of this — the connection, the payment, and the earning all happen through the same platform that manages the robot's identity and contract.

That last point is where a simple cable between two machines falls short. A direct connection has no trust layer. There is no record of what was sent, what was answered, or whether the robot's claim about distance matches what the platform measured independently. A platform that sits in the middle can enforce the robot owner's contract — which moves are permitted, what speed cap applies, what battery floor must be respected — for every party that interacts with the robot, including the policy host. It can also hold unusual earnings for review rather than paying them immediately, which matters when the robot is executing autonomously and no human is watching each step.

The earning from hosting a policy also matures through the same trust check as any other earning on the network. A host that answers badly — or that a robot's recording shows did not produce the declared result — does not simply collect. That asymmetry is what makes it reasonable to let a robot pay a host it has never met before.

How does a skill from a shelf teach a robot a move?

A robot skill is an ordinary skill file — the same format used for any other skill on the platform — that teaches a robot one move. There are two ways it can do that.

The first is a short list of moves the robot already has, played one after another. If the robot has declared that it can move forward, rotate, and stop, a skill can chain those in a sequence. Each step is recorded separately. This requires no external compute beyond what the robot already uses; it is composition, not inference.

The second is a served behaviour. Here the skill points to a policy host. The robot streams its observations to that host, which runs the model and returns actions. The robot executes them. From the owner's perspective, installing the skill and running it looks the same either way — a sentence in the chat, a confirmation, and the robot moves. The difference is invisible at the surface and significant underneath.

Robot skill

A skill file that teaches a robot one move — either a sequence of moves the robot already knows, or a served behaviour that routes observations to a policy host.

Served behaviour

A skill type where the robot's observations are sent to a policy host, which returns the next moves; the robot pays the host per answer from its own wallet.

Policy host

A GPU machine listed on the platform that runs a model on behalf of a robot and earns per answer, with that earning maturing through the standard trust check.

Skills shelf

A catalogue of installable skills matched against what a robot says it can do when it links to the platform; a skill is only offered if the robot's declared capabilities support it.

Is every episode worth keeping, and what can an owner do with the recordings?

Every job a robot completes leaves a recording: camera frames, the path the platform itself tracked, and the platform's own distance reading next to the robot's claim. These recordings exist primarily for accountability — they are how the platform verifies that a job was done before releasing payment, and how disputes are assessed.

But they are also data. A robot that has been operating for some time accumulates episodes that describe how it actually moves through real environments, not simulated ones. That is genuinely useful for training or fine-tuning models, and it is the kind of data that is difficult to generate at scale without physical hardware running real tasks.

A robot's owner can put those recordings on the market as a dataset. Buyers pay through the same mechanism used for skills and circuits. The owner is paid per sale. The recordings include the frames, the path the platform kept, and the platform's own readings alongside the robot's claims — so a buyer knows exactly what they are getting and can assess its quality before committing.

This does not mean every recording is valuable. A robot that has only performed simple, repetitive tasks in a controlled space will produce a dataset of limited interest. The value scales with the variety and difficulty of the environments the robot has worked in. That is worth knowing before deciding whether to list.

When is a simpler approach the better choice?

If the task is well-defined and the robot's existing move set covers it, a sequence skill is almost always preferable to a served behaviour. It requires no policy host, no per-answer payment, and no network dependency during execution. A robot that needs to patrol a fixed route, dock to a charger, or repeat a known manipulation sequence does not need a large model answering its observations in real time.

Served behaviours are worth the added complexity when the task requires the robot to respond to conditions it cannot anticipate — varied terrain, objects in unexpected positions, instructions that arrive in natural language and need to be interpreted into physical action. If the environment is predictable, the simpler tool is the right one.