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

> Define the controller and observation adapter before using LIBERO actions on hardware.

Reactor supplies inference and SDK transport. Your application owns camera capture, command
execution, timing, robot state, and safety behavior. This LIBERO variant is trained for a simulator
embodiment; the examples do not provide a physical driver, IK solver, or calibrated hardware
mapping.

## Define the adapter

| Responsibility | Required mapping |
| - | - |
| Cameras | External and wrist views; RGB, upright images, consistent identities and geometry |
| Translation | Raw LIBERO delta inputs to your controller's world/base frame, scale, limits, and zero conventions |
| Rotation | Axis-angle delta components to your controller's orientation convention; not Euler increments |
| Gripper | Sign-based open/close commands to your driver's actuator convention; not jaw widths |
| Execution history | Commands actually executed, represented in the model's LIBERO action coordinates |
| Local state | Measured robot state for control and monitoring; this endpoint has no proprioception input |

The [reference](/robotics/lingbot-va/libero/reference#action-reply) specifies the simulator's scale
and frames. A seven-value output does not imply compatibility with any seven-joint arm. If your
hardware API takes joint targets, you must supply the Cartesian-to-joint control or IK layer and
validate it. Matching tensor dimensions alone does not establish transfer from LIBERO.

## Implement the episode loop

1. Start with observation capture and action inspection without actuation. Validate both camera
   identities, orientation, frame age, and the controller mapping.
2. Open a fresh session, publish frames, clear the echo, reset, and set the task. Accept only a
   finite `(16, 7)` first chunk with `step: 0`.
3. Skip its first four rows. Validate the remaining targets against local position, velocity,
   acceleration, and workspace limits, then execute through your controller.
4. Publish camera frames during execution and echo the 12 executed rows. For later chunks, execute
   and echo 16 rows and require the next counter. Maintain a single outstanding chunk.
5. On timeout, disconnect, unexpected counter, or interrupted execution, apply the local hold/stop
   policy and end the remote episode. Resume with fresh observations in a new session.

The first commit conditions on the original seed prediction even if the client altered those
commands. Later commits use the echoed actions. Do not assume the endpoint supports arbitrary
partial chunks or controller modifications without evaluating their effect on policy history.

At 20 Hz, a regular chunk covers 0.8 seconds of commanded motion. Transport and inference add a
pause between chunks in the reference loop; the chunk duration is not a guaranteed latency budget.
Measure observation-to-execution delay and tracking error along with task success.

The SDK supplies neither a hard real-time servo loop nor collision avoidance. Local controller
limits, stop behavior, and emergency-stop handling remain application responsibilities.

## Observation timing

Camera tracks and execution echoes 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.