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

# Integration

> Map DROID observations and absolute targets into your robot controller.

Use this checkpoint with the DROID robot and camera conventions. Another arm requires more than
padding or relabeling its joints; validate embodiment compatibility before using the policy.

1. Publish wrist and two exterior RGB views. Pair them with the measured state in your capture
   system and retain timestamps.
2. Encode the seven joint angles in the reference order and radians. Convert measured gripper state
   to a closed fraction (`0` open, `1` closed).
3. Pin an available checkpoint, set the instruction, and submit one request. Keep the tracks
   delivering frames after the request.
4. Accept only the matching `step`. Validate shape, finite values, target limits, and observation
   age.
5. Execute absolute joint targets through your local controller at the 15 Hz sample cadence, with
   any required interpolation to its servo rate. Convert column 7 into the gripper driver's command
   convention.
6. Observe the resulting state and request the next chunk. Decide and evaluate how many rows to
   execute before replanning.

Returned targets are already in the robot action representation; do not apply model-training
normalization again or treat joint targets as deltas. Enforce limits and watchdogs locally. Reactor
does not provide a hardware driver, trajectory execution, or collision checking.

A repeated request can return different actions because new frames are used. Never execute two
replies for the same logical request. After a disconnect or uncertain reset, start a new session and
discard the previous action queue.

## Observation timing

Camera tracks and state commands arrive independently. Timestamp observations at capture and set
limits for their age and cross-camera skew; a reply counter does not establish capture alignment.
Publish actual observations rather than treating repeated images as new measurements.

Measure capture-to-execution age and controller queue depth. Validate the complete loop in a
simulator or replay harness before adapting it to hardware.


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