Skip to main content
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 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. 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. To deploy your own model code and weights, use Serve Models.