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

> LIBERO observation mapping and cloud adapter requirements for FastWAM.

There is not yet a verified public FastWAM-to-Reactor simulator adapter in the
[cookbook](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/sim). The existing
LingBot LIBERO client uses different track names, state inputs, and execution feedback; changing its
model slug is insufficient.

## Simulator and observation mapping

Use the
[upstream FastWAM evaluator](https://github.com/yuantianyuan01/FastWAM/blob/7faa71108368fbb3b6885649f112af607427a2d4/experiments/libero/eval_libero_single.py)
and its
[environment instructions](https://github.com/yuantianyuan01/FastWAM/blob/7faa71108368fbb3b6885649f112af607427a2d4/README.md#inference-with-released-checkpoints)
to establish the reference behavior. The original checkpoint's evaluation uses MuJoCo 3.3.2 and
LIBERO's Panda controller. Those upstream commands run local model inference; they are not Reactor
client commands. A cloud adapter would replace the evaluator's prediction call while keeping the
simulator, camera layout, initial states, and controller conventions.

| Simulator observation | Reactor input |
| - | - |
| `agentview_image` | `exterior_view_1`, raw RGB orientation |
| `robot0_eye_in_hand_image` | `wrist_view`, raw RGB orientation |
| `robot0_eef_pos` | `proprio[0:3]` |
| `robot0_eef_quat` (`xyzw`) | Axis-angle vector → `proprio[3:6]` |
| `robot0_gripper_qpos` | `proprio[6:8]`, preserving joint order |
| Benchmark task language | `task_description` |

The service performs the image rotation and action/gripper conversion. Skip those upstream
preprocessing and postprocessing steps in a Reactor client to avoid applying them twice.

## Episode loop

1. Reset the simulator to the selected initial state. Reset the model session and set the task.
2. Obtain both raw camera views and state from the same simulator observation.
3. Publish the views continuously, send a new `chunk_id`, and wait for its matching action reply.
4. Validate the reply and execute its selected prefix through `env.step(action)`.
5. Capture fresh observations and repeat until success, termination, or your episode limit.

The
[upstream configuration](https://github.com/yuantianyuan01/FastWAM/blob/7faa71108368fbb3b6885649f112af607427a2d4/configs/sim_libero.yaml)
uses 30 settling steps at episode start and executes 10 actions per replan from each 32-row chunk.
The
[LIBERO wrapper](https://github.com/Lifelong-Robot-Learning/LIBERO/blob/8f1084e3132a39270c3a13ebe37270a43ece2a01/libero/libero/envs/env_wrapper.py)
defaults to 20 Hz control. Those are evaluator settings, not requirements to echo executed actions
to the API. FastWAM needs another state request to produce another chunk.

Record task ID, initial-state ID, seed, executed rows, and success separately from inference timing.
Pausing simulation while waiting for the cloud can establish task behavior, but does not measure
uninterrupted physical-time control. Hosted end-to-end rollouts have not been validated for this
guide.


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