> ## 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=` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/; 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 > Connect observations to hosted inference and execute validated DROID targets. Reactor owns model inference, episode context, and action messages. Your application owns camera capture, state measurement, target validation, low-level control, and stopping behavior. These docs do not include a validated hardware driver. ## Observation and action loop 1. Create one session per robot/episode stream. Subscribe before connecting; publish named cameras after `READY`. The SDK maintains transport keepalive. 2. Send measured joint and gripper state, start all camera streams, then set the task prompt. 3. Receive `action_chunk`, validate its shape and finite values, and check it belongs to the active episode. Track `chunk_index` and `obs_seq` to reject already-consumed messages. 4. Apply your robot's position, velocity, acceleration, and workspace limits before replacing the pending plan. Execute accepted targets at the controller's cadence. 5. Continue sending current measured state and new camera samples. There is no execution acknowledgement command gating the next chunk. Validate the seven Franka joints in native order and the normalized gripper separately. The RoboLab adapter uses 15 Hz and full 24-step execution; a physical controller needs its own validated execution and replanning policy. Action chunks describe a new plan from an observation anchor. Queuing complete chunks behind each other accumulates stale plans. Replacing a pending chunk also requires care: a large jump from the current measured state must be rejected or handled by the local controller, not blindly executed. ## Freshness and temporal context Use actual captured frames. Repeating a still image at video rate can fill the model's four-frame history with copies and change its temporal conditioning. Video and state use separate transport paths; `obs_seq` does not make them an atomic observation or identify your last capture exactly. For paced simulator requests, use an adapter that explicitly manages camera delivery and episode state. For live control, log capture time, model counters, receipt time, and the rows actually executed. Set a cross-camera skew limit and measure capture-to-execution age and controller queue depth. Camera FPS, action cadence, and inference latency are separate quantities. Set an application-specific maximum action age and observation age. On a stalled view, inference timeout, disconnect, malformed output, or out-of-bounds target, stop replacing the plan and invoke your controller's defined hold/stop behavior. Do not continue indefinitely on the final chunk. ## Episode transitions Stop or hold the controller before changing an episode. A changed prompt re-anchors model context but does not reset episode counters. For a new episode, send `reset`, wait for `episode_reset`, discard buffered actions, and republish measured state and frames before the next prompt. The reset acknowledgement is not a physical-stop acknowledgement. After an ambiguous interruption, a fresh session gives the clearest boundary between old and new messages. See the [reference](/robotics/dreamzero/droid/reference) for exact command names and [troubleshooting](/robotics/dreamzero/droid/troubleshooting) for symptoms. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.