LeRobot can take new instructions mid-motion. Put the stop boundary beside the prompt

THE SIGNAL IN ONE SENTENCE

A robot that accepts a new sentence while it is moving is not just a chatbot with elbows. The sentence joins the control loop. Hugging Face released LeRobot 0.7 on November 5 with interactive rollout sessions and remote policy inference among a long list of changes to its open robotics stack. The interactive part is the attention grabber. An operator can load a language-conditioned policy, start a session and send a new subtask without unloading the model. The operator can ask what the robot sees. An external planner can choose another instruction. On supported setups, LeRobot can discard obsolete work, hold the robot and request fresh motion for the new goal. That is useful. It also turns language from setup text into a live control surface. The command “put the red block in the tray” no longer belongs only in a test script prepared before the run. It can arrive while the arm is carrying something, while an action chunk is buffered or while a policy server across the network is still computing an answer to the previous request. This is where the stop boundary matters. LeRobot's interactive-session documentation makes several distinctions that are easy to miss in a cheerful demo. The robot stays still until the session receives a start command. A new subtask is available only for language-conditioned policies. With a synchronous backend, the old precomputed action chunk can be dropped. With asynchronous or remote inference, an obsolete result can be discarded and queued motion can be invalidated on a supported robot before a local hold is acknowledged. Those details are the product. They are also not a universal safety guarantee. Position hold depends on the robot and configuration. A gripper may already be holding a glass, tool or battery. A discarded action packet does not reverse momentum. A fresh language instruction can be vague. A planner can return a plausible subtask that does not fit the actual workspace. A remote server can be late, unreachable or acting on a camera observation that is already old. The right architecture keeps the physical boundary local. Start with an emergency stop that does not depend on the language model, planner, policy server, network link or application process. It should cut or inhibit motion through the robot's approved safety path. Test it with the network disconnected and the model process frozen. If the only way to stop the arm is to send another prompt, the prompt is not a stop control. It is a wish. Map the workspace before the session. Define where the arm may travel, which surfaces are protected, which people may enter the area and which objects may be handled. Keep those constraints in the local controller or another independent enforcement layer. A planner can propose a destination. It should not be able to redraw the fence because the sentence sounded confident. List permitted objects and actions. “Tidy the table” is wonderfully convenient language and a wonderfully sloppy machine contract. Does tidy include a laptop cable, a hot mug, a medication bottle or somebody's hand resting near the edge? Give the live instruction layer a small vocabulary of allowed subtasks and an explicit object inventory when the deployment permits it. LeRobot supports a planner instruction list that can constrain possible subtasks. In remote-inference configurations, that list needs to be provided explicitly or the planner may answer in free-form language. Treat the list as an input boundary, not proof that every permitted phrase is safe in every state. Capture a fresh observation after a command change. The old instruction and old camera frame form one decision context. The new instruction deserves a new one. Record the image timestamp, joint state, gripper state, sensor confidence and action queue at the moment the change arrived. If the view is blocked or stale, do not let fluent language substitute for sight. Invalidate old motion before accepting new motion. LeRobot's remote path uses action chunks. The robot computer keeps cameras, motors, teleoperation and recording local, while observations and instructions can travel to a GPU policy server and action chunks come back. The client may continue buffered actions while the server computes. It aligns returned chunks, discards expired steps and can blend overlapping targets. That can smooth operation. It can also create a dangerous ambiguity unless the system can answer a simple question: which instruction authorized the action being executed now? Attach an instruction identifier and observation timestamp to every chunk. When a new instruction arrives, reject any chunk produced for the old identifier. Flush or safely stop queued motion, acknowledge the local hold, then request the new action. Do not infer cancellation from silence. Put speed, force and approach limits below the model. The language layer can ask for a faster route. It should not be able to exceed the controller's limits. Use slower modes when a person is inside the supervised area. Bound gripper force. Limit approach speed near uncertain objects. Define what happens when force, current, proximity or joint-error readings cross a threshold. Human takeover should be boring. Give the operator one unmistakable control for stopping motion and another well-defined process for resuming. A takeover should not require navigating a dashboard, remembering a command syntax or waiting for a planner worker. Record who took control, why, what state the robot entered and who authorized the restart. Remote inference needs a failure table. LeRobot uses Zenoh for its remote inference path and documents transport security and access-control options. Encryption and identity controls are necessary. They do not decide what the robot should do when packets arrive late, the server restarts or the action buffer runs dry. Set deadlines for observations and action chunks. Reject old timestamps. Define the local behavior for server loss: hold, return to a safe pose or transfer to a human, depending on the machine and task. Test partial failures, not only a clean unplugged cable. Keep the planner trace separate from the execution record. Interactive sessions can ask an external planner to answer a question about the scene or select a subtask. A planner accepting an instruction does not mean the robot completed it. Store the planner request, available instruction list, selected subtask, observation reference and confidence or explanation when available. Then store the actual policy actions, controller interventions, sensor readings and final state. One is intent. The other is evidence. Replayability matters because physical failures are rarely one neat mistake. A vague prompt may meet a stale image, a delayed chunk, a near-empty action buffer and a person entering the workspace at the same time. A useful log connects the instruction version, observation, planner response, policy version, action chunk, local safety checks, network state, human interventions and outcome on one timeline. That record lets a team reproduce the boundary failure instead of arguing over the smooth demo video. LeRobot 0.7 also adds dataset streaming without storing the full dataset locally, a more unified simulation and evaluation core, support for additional world-action and vision-language-action models and training changes for very large policies. Those are meaningful engineering updates, but the live instruction path is the part that changes the human relationship with the machine. The operator can now redirect the robot in ordinary language while the session stays alive. That can make robots easier to teach, supervise and adapt. It can also make control feel deceptively conversational. Keep the conversation on top. Keep the stop, workspace fence, speed limit, force limit and human takeover underneath it, local and independent.