> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To build and serve your own model, start at /deploy/development/quickstart and /deploy/development/overview. Deploying is the default path: reactor init scaffolds a workspace, reactor auth login authenticates, and reactor model deploy registers the model, publishes the release with the weights/ folder, and activates it on Reactor's GPUs, in one command from that workspace. Docker must be running, because the publish step builds the image locally. Bump model.version in reactor.yaml before redeploying a change, because a release that already has an image is reactivated as it is. Deployment access is granted per account, so contact team@reactor.inc if a deploy is refused. Every key in reactor.yaml is documented at /deploy/platform/reactor-yaml. Model code imports reactor_runtime; Python client code imports reactor_sdk. The runtime overview explains the model interface. Running the model on your own machine with reactor run is optional and needs a GPU you attach with --gpus; /deploy/development/local-testing covers that loop and pairs a complete brightness model with a Python client test in a separate brightness-test workspace.
> Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The video model catalog — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Robotics policy documentation starts at /robotics/overview; X-WAM observations, actions, and client integration are under /robotics/xwam/; Cosmos3 Nano Policy DROID is under /robotics/cosmos/nano-policy-droid/. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it.
> Fastest path to a working app: `npx create-reactor-app my-app --model=<slug>` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/<model>; Python uses the base reactor-sdk package.
> Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code.
> Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp.

# Build an AgiBot simulation

> Connect a starting scene, arm controls, and generated video in a Reactor session.

Use Cosmos3 Nano Sim Bimanual with an image of the supported AgiBot robot and scene, a task prompt,
and calibrated controller poses. This guide covers the session commands and a mouse or trackpad
control scheme.

## Run the Python examples

Start with the [scripted AgiBot rollout](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/simulation/cosmos-bimanual#run-a-short-rollout)
to connect to the hosted model, initialize your scene, change an arm pose and gripper value, and
reset. It saves three preview snapshots so you can inspect the received video.

Then try the [interactive terminal controls](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/simulation/cosmos-bimanual#try-your-own-controller-inputs)
to select either arm, adjust XYZ positions, open or close a gripper, and save snapshots. These are
Python clients with saved images, not live graphical viewers. Both include pinned dependencies and
setup instructions, including a pinned download of NVIDIA's public AgiBot starting image.
Bring a Reactor API key with model access; no local GPU or weights download is needed.
Use the supplied image first, then substitute your own compatible scene.

The examples were verified against hosted model version 0.2.0 with Python SDK 1.10.0.
Preview snapshots are not synchronized action-to-observation results for policy evaluation.

## Session contract

Connect to `reactor/cosmos3-nano-sim-bimanual`. Use the
[SDK's commands and uploads](/sdk-reference/using-the-sdk) after the session is ready. These
operations are session commands, not separate HTTP endpoints.

| Command | Input | Effect |
| - | - | - |
| `set_image` | `image`: uploaded PNG or JPEG; each side at most 4,096 pixels | Sets the scene and restarts the world |
| `set_prompt` | `prompt`: task text, at most 800 characters | Changing the prompt restarts from the starting image |
| `set_teleop` | `teleop`: left/right poses and gripper values | Updates the held controller sample |
| `set_seed` | `seed`: integer from 0 to 2,147,483,647 | Applies when the next world starts |
| `set_paused` | `paused`: boolean | Holds or resumes generation |
| `reset` | No parameters | Restarts from the current image and controller anchor |

Generation starts once an image, nonempty prompt, and valid controller sample are present. Each new
world anchors itself to the current controller positions; resetting does not move controllers to
zero. Set the seed before starting or resetting a world.

The `main_video` track carries generated RGB frames. Per-frame metadata contains `step` and `frame`.
The `simulation_status` message reports input readiness, pause state, frame/step counters, and any
configured rollout limit. A command acknowledgement confirms handling, not that its visible effect
has reached the screen.

### Controller payload

This is an example payload for `set_teleop`. Positions are meters in your calibrated tracking space;
orientations are unit quaternions in `[x, y, z, w]` order. Align the controller axes and initial
poses to the supported robot before applying movement. These numbers illustrate the shape, not a
calibration.

```json theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
{
  "teleop": {
    "left": { "position": [-0.2, 1.0, -0.4], "orientation": [0, 0, 0, 1] },
    "right": { "position": [0.2, 1.0, -0.4], "orientation": [0, 0, 0, 1] },
    "left_grip": 0.0,
    "right_grip": 0.0
  }
}
```

Grippers range from `0` (open) to `1` (closed). An optional `head` pose uses the same position and
orientation fields; omitting it holds the head camera still.

## Build a mouse or trackpad playground

Choose a compatible starting scene, upload it, set a task prompt, and send the initial controller
poses. Display `main_video` with an explicit Left / Right arm selector, pause, and reset controls.
Map each gesture to a bounded change in the selected controller's calibrated pose:

| Gesture | Client behavior |
| - | - |
| Click without dragging | Toggle the selected gripper between open and closed |
| Click and drag | Move the selected arm across the tabletop |
| Two-finger scroll or mouse wheel | Raise or lower the selected arm |
| Release the drag | Hold the current controller pose |
| Left / Right selector | Choose which controller receives subsequent changes |

The model receives `set_teleop` pose samples, not mouse events. Use a small drag threshold so
releasing a drag does not also toggle the gripper. Clear pending movement on focus loss or pointer
cancellation. Holding a controller pose does not pause world generation; use `set_paused` for that.

Keep the latest desired pose in the browser and bound pending commands so a slow connection does not
replay old movement. Multiple clients share session state, so give one person control and make other
clients viewers. The model API does not provide a controller lease.

Start with a small number of tested scenes. Arbitrary image support does not establish reliable
behavior for unseen robots, objects, or camera layouts. For a custom-policy experiment, first define
an embodiment-compatible action mapping and evaluate the generated dynamics; the current controller
API does not provide a causal action-to-observation stepping contract or task-success scores.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.