> ## 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 decoded RoboCasa365 actions without confusing them with physical robot targets.

This checkpoint targets the RoboCasa365 PandaOmron simulator. A physical Franka arm or mobile base
does not become compatible because it has similar actuators. No validated physical robot driver is
provided here. Start with a simulator adapter and the checkpoint's observation/controller
conventions.

## Preserve the state representation

The 14-value state consists of base-relative EE pose, two gripper joint positions, and world-frame
base pose. Convert quaternions from `xyzw` to axis-angle; never put four quaternion values into a
three-value rotation slot. Preserve the raw simulator coordinate frames and units. The model
performs checkpoint normalization remotely.

Keep a seven-observation client buffer for the reference history settings, sampling `t-6`, `t-4`,
`t-2`, and `t`. Pair that state history with the server's actual video samples. See
[simulation](/robotics/xr1/robocasa365/simulation) for the missing transport adapter and receipt
gate.

## Execute the simulator action

Once an aligned observation has produced a validated chunk, the upstream execution boundary is:

```python theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
import numpy as np
from robocasa.utils.env_utils import convert_action


def simulator_action(row):
    action = np.asarray(row, dtype=np.float32)
    if action.shape != (60,) or not np.isfinite(action).all():
        raise ValueError("Expected one finite 60-value action row")
    return convert_action(action[:12])
```

Pass this dictionary to your configured RoboCasa environment's `step`. This helper only validates
and maps one returned row; it is not a complete rollout loop. The controller owns scaling of EE,
base, torso, and gripper commands. These outputs are decoded controller commands; do not apply
additional checkpoint denormalization or reinterpret them as joint positions.

Execute at most the available 16 rows before replanning. The reference evaluator uses all 16; a
shorter window changes evaluation behavior and should be measured. Update measured state history
before sending a strictly increasing executed-action count. The returned prediction `step` is a
separate counter and must not be treated as the number of executed simulator steps.

## Control ownership

Keep the action executor local and bounded: validate outputs, enforce controller limits, and define
safe behavior for stale observations, missed deadlines, disconnects, and simulator termination.
Discard unused actions when replanning or changing episodes. Reset both sides' history; reconnect
when old media must not cross the episode boundary.

Moving to physical hardware additionally requires an appropriate checkpoint, calibrated cameras,
kinematic/frame mapping, controller scaling, execution timing, and a robot safety system. The
synthetic quickstart proves none of those conditions.

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