> ## 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=` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/; 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. # Robotics > Choose a hosted policy, verify its robot contract, and receive action chunks. Your Python client runs on a computer connected to your robot or simulator. Reactor runs the model on cloud GPUs. Your client sends camera images, the task, and any required robot state; Reactor returns predicted actions. Your local controller validates and executes those actions. You need the Python SDK and access to the hosted model, but no local model weights or inference GPU. Your application owns camera and state mapping, execution timing, and safety limits. The [How the API works](/robotics/how-the-api-works) guide explains the connection and what your Python code receives. Then choose a model and run its first-action example. ## Choose a model Start with the **embodiment and action representation**. Matching tensor dimensions alone does not establish compatibility with a robot. The catalog below groups policies by their observation and action contracts. Session access depends on model availability, capacity, and your account. | Family | Documented embodiment / variant | Returned actions | | - | - | - | | [Cosmos](/robotics/cosmos/overview) | Nano Policy DROID · Franka arm | 32 × 8 absolute joint targets + gripper | | [FastWAM](/robotics/fastwam/overview) | LIBERO · Panda | 32 × 7 controller commands + gripper | | [FLUX Action](/robotics/flux-action/overview) | FLUX 3 Action DROID · six checkpoint choices | 32 × 8 absolute joint targets + gripper | | [DreamZero](/robotics/dreamzero/overview) | DROID; Bimanual YAM | 24 × 8 or 24 × 14 joint targets + grippers | | [LingBot-VA](/robotics/lingbot-va/overview) | LIBERO · Panda | 16 × 7 controller deltas + gripper | | [X-WAM](/robotics/xwam/overview) | RoboTwin · bimanual `aloha-agilex` | 32 × 14 end-effector and gripper deltas | | [XR-1](/robotics/xr1/overview) | RoboCasa365 · PandaOmron | 16 × 60 padded actions; first 12 columns used | For a simulation rollout, check whether a Reactor bridge is supplied: * **Reference bridge supplied:** Cosmos DROID (RoboLab), DreamZero DROID (RoboLab), LingBot-VA (LIBERO), and X-WAM (RoboTwin). Their simulation pages include setup and launch commands. * **Bridge implementation required:** FastWAM, FLUX Action, DreamZero YAM, and XR-1 RoboCasa365. Their adapter guides describe the observation and control mappings you need to implement. ## Developer journey 1. **Check compatibility.** Choose a family and embodiment. Read the variant's compatibility table and checkpoint choices. 2. **Get your first actions.** Follow the quickstart to install the client and inspect one reply. Synthetic fixtures test connectivity and tensor shape; they do not test task success. 3. **Choose your integration path.** Use a supplied simulator bridge, build an adapter, or connect your existing robot client using the integration guide. 4. **Integrate your robot.** Confirm camera and state mapping, action units, and execution rules. Validate replies, schedule your local controller, and define stop/recovery behavior. 5. **Look up the API details.** Use the reference for exact track names, command payloads, reply fields, and model-specific limits as you implement your integration. Installation is included in each quickstart; execution guidance is in each integration guide. ## Families, variants, and checkpoints A **family** groups related policies. An **embodiment variant** defines a robot-specific observation and action contract and has its own guide. A **checkpoint choice** selects weights or precision within that contract, where the endpoint supports it. The model slug identifies the endpoint; the release identifies the deployed model version. For example, FLUX Action has one documented DROID endpoint with six checkpoint choices. DreamZero has separate DROID and YAM endpoints because their robot contracts differ. For shared SDK behavior, see [Python SDK](/sdk-reference/python/reactor). To deploy your own model code and weights, use [Serve Models](/deploy/overview). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.