Own the run-loop

The starter kit ships one harness: read state, call the model, move the arm, repeat. It's real and it works — and it's one choice among many the same SDK lets you make differently. This chapter is about the loop underneath it, the one you're free to rewrite.

The same two callbacks, your own logic

Every harness on the SDK reduces to the same shape: a function that reads what your robot is sensing, a function that moves it, and robot.run(prompt) calling them in a loop until the model says the task is done. The starter kit's embodiment.py is one implementation of that shape — a read_state() that returns joint positions and two camera frames, an execute() that applies the chunk. Nothing forces you to keep it as-is. Anything exposing those same two methods is a valid embodiment, starter-shipped or hand-built.

What goes between "chunk arrived" and "chunk applied"

That gap is deliberately yours. execute() is your code, so a gate you add there is real: read a camera frame in read_state(), and hold or abort if what you see doesn't match what you expect before the next chunk lands. Refuse a chunk that would push a joint past a bound you set. None of that is a callback New Theory defines — it's ordinary logic sitting inside the two functions the SDK already calls every cycle.

Chaining tasks is the same trick, used twice. robot.run() finishes one instruction and returns; nothing stops your script from calling it again with the next one. A harness that runs "pick up the cube," checks the result, then runs "place it in the bowl" is two run() calls and the logic in between — yours to write, not a feature to look up.

How much of a chunk you trust

The model doesn't return one move — it returns a plan. An SO-101 fine-tune answers with (30, 6), thirty steps ahead of where the arm is now. The SDK re-infers every cycle, but by default it hands your execute() the whole plan; playing all thirty steps against an observation that's already gone stale is a choice, not a requirement. The SO-101 starter's own execute() doesn't make that choice — it plays the first fifteen, then asks for a fresh plan, because a chunk gets staler than it's worth trusting past that point. That fifteen is the starter's own harness decision, sitting in its source, not a setting the SDK hides from you. Your harness can make a different one.

Recording from the loop you built

The kit's local site is one way to record episodes; it isn't the only path back into training data. nt-writer, New Theory's episode-writing library, takes the same two kinds of readers your harness already has — one for robot state, one per camera — and turns whatever loop you're running into a valid episode. If your harness already reads state and camera frames to drive the arm, it's most of the way to recording with them too.

Run it yourself

The callback contract, the embodiment protocol, and the starter's own chunk-truncation code all live in the docs.

→ The newt SDK — the full callback and embodiment contract — with the SO-101 starter for the shipped execute() to read or replace, two clocks for why the model returns a plan instead of one move, and build custom recorders for recording outside the kit's site.

You've made this loop yours — what runs between chunks, how much of each one you trust. The next chapter is where you find out if it's any good.