The LLM must never touch the control loop
My robot arms want a new command every 50 milliseconds, and a cloud model doesn't promise anything about its worst second.
My robot arms take a new command every 50 milliseconds, and that is the slow setting: the CAN adapter floods above 20 Hz when both arms are moving, so 20 Hz is what they get. A cloud language model answers in a second or two on a good day. Those two numbers are more than an order of magnitude apart, and nobody ships on a good day.
This post is about what follows from that gap. A language model can write the program a robot runs. It cannot sit in the loop that runs it.
What a late packet does to an arm
In August I drove the arms from a VR headset. Controller poses went through inverse kinematics at 60 Hz, and commands went onto the CAN bus at 40 Hz for one arm. Every frame was a decision about where sixteen motors go next, which meant I also had to decide what the arm does when a frame does not arrive.
On my rig a watchdog holds the last target for half a second. If the stream stays silent for five seconds, the arm eases back to hanging straight down, and the next connection has to ease in again from there. That is what one missing packet costs on a physical arm. It is not a retry. It is a policy for what the hardware does while nobody is talking to it. Put a cloud model in that loop, and the question becomes what its five-second silence looks like.
The tail is the product
Ken Goldberg's group studied this problem in FogROS2-PLR, running cloud robots over two commodity 5G carriers. They frame it as an impossibility triangle between latency reliability, a single server and commodity hardware: you get to pick two. Their answer is redundancy. Send the request over both carriers and take the first reply, and in one experiment the 99th-percentile latency improves by up to 3.7 times against a single carrier.
That is the right fix for a planner. It is no fix at all for a control loop, because a control loop does not get to average over the second it lost. An arm moving at 30 degrees a second travels 30 degrees in every second the reply is late. What decides whether the arm is safe is the worst reply, not the typical one, which is why the tail of the latency distribution is the product.
What the model is for
The model is for writing the program, not for running it. You type the task, and the model writes a small program against a fixed set of bounded motions: read the joints, move to a target, open or close the gripper. The program then runs at control rate with no model anywhere in the path.
On my rig that means motion interpolated at 20 Hz, capped at 30 degrees a second per joint and clamped five degrees inside every vendor limit, with an emergency stop checked between every single step. If the program fails, the model gets the failure and writes a better program. Once the model has written it, the model is gone.
The regulator got there first
The standards have arrived at the same place from the safety side. ISO 10218-2:2025 moves its focus from the robot to the robot application, and the application now includes the task program, so the program is part of what gets validated. A program is something you can read, test and sign off. A model's next reply is not.
The EU Machinery Regulation, which applies from January 2027, puts safety functions with self-evolving machine-learning behaviour on its high-risk list, where a third party has to assess them. Both point the same way. The thing that moves the robot has to be inspectable, and it has to be the same thing tomorrow.
Unplug the cable
The test I hold myself to is simple. Teach the robot a task, unplug the network cable, and run the task again.
Teaching can use the cloud. The best models live there, and there is no reason to handicap the teacher. Running cannot, because the program is on the robot and has to execute whether the uplink is there or not. Let the model write the program, then take the model out of the room.