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

# Build a RoboCasa365 adapter

> Set up the upstream simulator and identify the Reactor adapter boundary.

The upstream XR-1 repository includes a RoboCasa365 evaluator. Its transport is a local model
socket, and it does **not** connect directly to Reactor. The cookbook includes a
[local-runtime evaluation adapter](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/sim/robocasa365),
but it is not a verified hosted Reactor bridge: it uses local authentication mode and requires
interval-one server history sampling. You can run the
[synthetic connectivity check](/robotics/xr1/robocasa365/quickstart) now; a hosted simulator rollout
requires the adapter described below.

## Set up the benchmark

Follow the
[official RoboCasa installation guide](https://robocasa.ai/docs/build/html/introduction/installation.html)
for the simulator, its matching robosuite dependency, and kitchen assets. Use the
[XR-1 RoboCasa365 evaluator guide](https://github.com/XiaomiRobotics/Xiaomi-Robotics-1/blob/7c20088/eval_robocasa365/README.md)
for the upstream benchmark environment and headless rendering requirements. Pin the evaluator to
`7c20088b5328db7bdb6c399352326af3b38c9d31` when comparing with these docs.

The upstream guide's local server and checkpoint download are needed for its socket evaluation path.
Hosted Reactor inference replaces that server and runs model preprocessing remotely. Its launcher
cannot be pointed at a Reactor session by changing a host or port.

## Adapter responsibilities

Use the upstream evaluator's `observation_to_state`, `collect_images`, and history-sampling logic as
the observation reference. Replace the local `EvalClient.infer` request with named video tracks,
`set_state_history_json`, an execution echo, and an `action_prediction` reply.

| Boundary | Required behavior |
| - | - |
| State | Four 14-value EE/gripper/base rows in the [documented order](/robotics/xr1/robocasa365/reference#state-layout) |
| Cameras | Publish synchronized three-view sets with no per-track duplication or loss |
| History | Match the server's four-slot, interval-two sampling to the client state timestamps |
| Initial request | Satisfy the minimum four complete camera sets and send an initial echo |
| Actions | Validate `(16, 60)`, take the first 12 columns, and call RoboCasa `convert_action` |
| Replanning | Execute a chosen window, refresh history, then advance the echo |
| Episodes | Clear local action/history queues; reconnect for strict separation |

The timing boundary needs explicit validation. With the default server sampling, publish consecutive
environment observations rather than pre-sampling video twice. Startup padding and the receipt gate
of four complete camera sets per echo must preserve the same sample indices for video and state.
Wall-clock frame repeats can satisfy the receipt count while corrupting temporal spacing; the
quickstart helper therefore cannot be reused as a rollout publisher without an adapter.

## Validate a rollout

Start with one task and one episode. Record capture indices for every camera/state row, prediction
indices, executed actions, and simulator success/termination. Check history alignment before judging
policy quality. Use the upstream reference window of 16 actions only after checking the simulator's
control cadence; network frame rate does not set that cadence.

There is no hosted XR-1 RoboCasa365 benchmark result established by these pages. Report environment
revision, task/split, seed, history settings, replan window, and success criteria with any results.


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