> ## 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.

# AgiBot

> Generate visual observations for the supported AgiBot embodiment.

Cosmos3 Nano Sim Bimanual supports the **AgiBot embodiment**. Start with a compatible image of the
robot and scene, provide a scene/task description, and drive the simulation with calibrated arm
poses and gripper values.

## Inputs and outputs

| Input | Purpose |
| - | - |
| Starting image | Establishes the robot, camera view, and scene |
| Scene/task description | Provides generation context; does not execute a task |
| Initial arm poses and grips | Establishes the controller anchor for the world |
| Updated arm poses and grips | Drives subsequent movement |

The model returns generated RGB video on `main_video`. Connect using
`reactor/cosmos3-nano-sim-bimanual`.

> **[Build an AgiBot simulation](/robotics/cosmos/nano-sim-bimanual/agibot/interactive-controls)**
>
> Initialize a scene, map mouse or trackpad input to arm controls, and view the generated response.

## Runnable example

[Run the AgiBot rollout in the Reactor Cookbook](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/simulation/cosmos-bimanual).
Initialize a scene, send arm and gripper controls, reset, and save preview snapshots using Python.
The same example includes a download command for a public AgiBot starting image and terminal controls for experimenting with both arms.

## Compatible controls

Positions use meters in your calibrated tracking space; orientations are unit quaternions in
`[x, y, z, w]` order. Grippers range from `0` (open) to `1` (closed). Align the controller axes and
starting poses to the supported embodiment before applying movement.

Another robot's joint targets, torques, or policy actions cannot be supplied directly. An image of a
different robot does not change the supported action representation. Integrating a custom policy
requires an embodiment-compatible mapping and validation of the generated dynamics.

This interactive interface generates visual responses; it does not expose physics state,
task-success scores, or synchronized action-by-action policy evaluation.


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