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 clone 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. Clone its starter repo. Each starter is a standalone Git repository you clone and modify. You own the result after clone, including embodiment.py and its class.
3. Fill in your hardware config. Copy the starter's config template to ~/.config/nt/nt.toml and edit it with your specifics — the arm's serial port and your two camera indices. The class reads this file in from_config(); 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 — clone URL, 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.

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.