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

> FastWAM control-loop, state mapping, and execution responsibilities.

Reactor predicts actions. Your application acquires observations, validates replies, and drives the
controller. This variant is trained for LIBERO's Panda setup; no physical robot driver or hardware
validation is supplied with this guide.

## Map the observations

Use the exact [camera and state contract](/robotics/fastwam/libero/reference). Capture both views
and state together. Camera dimensions alone do not establish compatibility: preserve the reference
views, orientation, field of view, robot coordinates, and gripper joint ordering.

The input orientation is axis-angle, not Euler angles or the robot's joint angles. For a LIBERO
observation, use robosuite's axis-angle conversion, matching the upstream evaluator. The simulator
environment supplies robosuite.

```python theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
import numpy as np
from robosuite.utils.transform_utils import quat2axisangle


def encode_observation(obs):
    frames = {
        "exterior_view_1": np.ascontiguousarray(obs["agentview_image"]),
        "wrist_view": np.ascontiguousarray(obs["robot0_eye_in_hand_image"]),
    }
    orientation = quat2axisangle(np.array(obs["robot0_eef_quat"], copy=True))
    proprio = np.concatenate([
        obs["robot0_eef_pos"], orientation, obs["robot0_gripper_qpos"]
    ])
    if proprio.shape != (8,) or not np.isfinite(proprio).all():
        raise ValueError("Expected eight finite LIBERO state values")
    return frames, proprio.tolist()
```

## Request and execute

Keep one request outstanding. Publish its current observations, send `state_json`, and continue
supplying camera frames while waiting. Validate the returned `step`, finite `(32, 7)` array, and
controller limits before scheduling any actions. Discard duplicate or obsolete replies.

Use the controller scaling documented in the
[reference](/robotics/fastwam/libero/reference#action-reply). Do not interpret the first six columns
as physical displacement without that controller mapping. The gripper is already converted to
LIBERO's convention.

Choose how many rows to execute before observing and replanning. The upstream evaluator uses 10; all
32 rows are predictions, and there is no seed prefix or executed-action acknowledgement. For the
next prediction, replace the observations and increment `chunk_id`.

## Timing and recovery

Track observation age, request-to-reply time, and actual execution time separately. Camera
publishing rate, model prediction time, and controller frequency are distinct. Set an
observation-age limit and response deadline appropriate to your controller; an expired request must
not enqueue actions later.

If a timeout leaves request ownership uncertain, stop consuming its results and start a fresh
session. Retry only when your client can recognize and discard duplicate replies. Never blindly
replay returned actions after reconnecting.

At episode end, clear the local pending action plan and reset the simulator or robot through your
own controller. Reset the model separately, set the new instruction if needed, and send fresh frames
with a new request ID. The model's `reset` does not interrupt physical motion.


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