# Set up your embodiment
URL: /docs/set-up-your-embodiment

Take your first inference call from a mock smoke test to a real robot using an embodiment starter kit.



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

## How embodiments connect [#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](/docs/starters).

## The fast path [#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](/docs/starters).
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 [#so-101]

The SO-101 is a low-cost arm driven by MolmoAct-2 SO-101. Start with the [SO-101 starter](/docs/starters/so101) 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? [#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](/docs/newt-sdk#embodiment) 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](/docs/newt-sdk#call-shape) 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 [#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.