Set up your embodiment

You've made an inference call against the API and watched action chunks come back (Getting started). Those chunks ran against mock callbacks. This page is the fast route to running them on real hardware.

How embodiments connect

An embodiment is a class you own that implements read_state() and execute(). For the embodiments New Theory supports, you get that class from a starter kit — a project you create and own. The kit's centerpiece is embodiment.py, where the class lives; the kit also ships the project structure, dependencies, config, and a thin entry script that constructs the class and passes it to Robot(embodiment=...). You fill in your hardware specifics and run it. For the full picture, see How to use embodiment starter kits.

The fast path

1. Pick your embodiment. Each starter pairs one robot with the model that drives it. The list lives on the starters page.
2. Create the project. newt create <template> unpacks that starter into a directory named after it — newt create so101 gives you ./so101, and a second argument names the directory yourself. The kit arrives at a pinned commit with no git remote, so embodiment.py and its class are yours from the first byte. See the CLI reference for the flags.
3. Run the kit's setup step. The kit asks about your hardware — the arm's serial port, your two camera indices — and writes the config its class reads in from_config(). newt create prints that step as the next command to run; --setup runs it during create. The starter's README names the exact fields.
4. Run the entry script. With your NT_API_KEY exported and the config filled in, run the starter's entry script. It constructs the embodiment class, passes it to Robot(embodiment=...), opens a WebSocket to the model, streams observations from your hardware, and executes the returned chunks on the arm.

SO-101

The SO-101 is a low-cost arm driven by MolmoAct-2 SO-101. Start with the SO-101 starter for what's in the kit — the file map, config fields, camera setup, calibration flow, and task flags. The model is open-vocabulary: you supply a natural-language --task description at run time.

No starter for your embodiment yet?

Any class with read_state() and execute() is an embodiment. Write one for any hardware: read_state() returns the robot's current state and camera frames, and execute() applies a (30, 6) action chunk to the arm. Pass an instance to Robot(embodiment=your_rig). No inheritance or registration — the two methods are the whole contract. See the SDK reference for the protocol. Resize camera frames to the contract's shape on every read, not just the first — the SDK measures every frame before it sends, so an observation over the frame size limit ends the run with FrameTooLargeError instead of an action chunk. See Errors.

You can also pass the two methods as bare callbacks — Robot(read_state=..., execute=...) — which produces the same run and stays supported. The SDK reference shows both as mocks; a real integration replaces them with reads and writes against your hardware. More starters are coming as we add embodiments.

Safety is client-side

The API has no emergency-stop or recovery primitive — stopping the robot is your code's job. The starter kits wire their own stop paths: a keyboard abort during the trial and a blocking move to a safe rest pose afterwards. A custom integration needs the same, in addition to the hardware e-stop your arm ships with.