Build with the starter kit
The SO-101 deploy client
Calling the model got you a stream of action chunks — arrays of numbers, one every step, each describing where the arm should go next. Nothing has moved yet. The starter kit is what turns that stream into your arm moving.
What the kit is for
The split is the whole point. The model decides what to do; the kit owns how this specific arm does it. That line is the boundary the SDK is built on: newt.Robot consumes the model's output stream, and the embodiment underneath it owns the physical actuation. Everything the model sends is arm-agnostic — a (30, 6) action chunk means the same thing whether it reaches your SO-101 or a rig you built yourself. Making those numbers become motion on your hardware is the kit's job, and yours.
A starter kit is a project you clone and own, not a library you install. You clone it, fill in your hardware, run it — and after that it has no version relationship to New Theory. The result is yours.
The SO-101 starter, concretely
The SO-101 starter is real and shipped. It gives you an embodiment class exposing two methods — one that reads the arm's current state and its two camera frames, and one that applies an action chunk to the arm — and a runner that hands the embodiment to newt.Robot and runs one closed-loop trial. You fill in a config with your arm's calibration id (--robot.id=<USB_ID>) and the serial of each camera.
The two cameras the kit expects — top and side — are the exact two your episodes were recorded and exported with. That isn't a coincidence you manage by hand; it's why a model trained on those episodes and this rig line up without any translation in between. And because the starter reads the same LeRobot-format calibration the kit wrote when you calibrated, the joint angles your checkpoint trained on and the ones it commands mean the same physical pose — no second calibration.
Stopping the robot is your code's job
Nothing stops the arm but your code
This is the first step where that matters. The API has no emergency-stop or recovery primitive — stopping the arm is code you own. The SO-101 starter handles it for you: a keyboard abort you can trigger during the trial, and a blocking move to a safe rest pose afterward. It also ships a reset mode that moves the arm to that rest pose without running any inference. A robot in motion earns a stop the earlier steps never needed.
Where this course's run stops
Here's the honest seam. This chapter does not narrate the arm completing your task on the fine-tune. The red-cube-bowl model trained through our pipeline, auto-admitted, went live, and answered a call with correctly shaped chunks — and that is where our own run is proven. Driving the physical arm on those weights is a live-rig moment we had not yet confirmed when this was written. The chunks are real; the arm doing the task on them is described here, not claimed as done.
One more gap worth naming. The shipped runner drives the base SO-101 model, not a fine-tune. Pointing it at the model you trained — calling your model by name through the kit — is documented across the starter and the calling-the-model page, but no single page yet joins the two. It's a seam that's described, not a path anyone has walked on record.
[ closed-loop trial — an action chunk arriving, the arm taking one step ] Placeholder. Base-model trial or a chunk → execute → motion schematic; no fine-tuned rollout is shown until one is on record.
→ Build with the SO-101 starter — clone the starter repo directly.
You have the loop closed on the arm in code. Everything from here is what you build with it — starting with the SDK underneath the starter kit.