> ## 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. # Connect to a simulator > Use rendered RGB observations in a closed-loop policy evaluation. Your simulator executes robot actions and renders depth. Cosmos3 Nano Sim Transfer turns that depth into camera-like RGB for your policy. Physics, simulation time, and task scoring remain in your simulator. ## Try the delivery contract first Run the [incremental depth cookbook example](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/simulation/cosmos-transfer#advance-depth-rendering-step-by-step) to submit one frame followed by four-frame batches, match episode/step identifiers, verify RGB hashes, and save every PNG. It replays prepared depth; it is **not** a simulator or policy evaluation. Replace its fixture source with your simulator's depth renderer when building the loop below. ## Run the observation loop ```mermaid theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} flowchart LR Policy[Your policy] -->|Actions| Sim[Your physics simulator] Sim -->|Prepared depth frames| Transfer[Sim Transfer on Reactor] Transfer -->|Complete RGB frame batch| Policy Sim -->|State and task metrics| Eval[Your evaluator] ``` 1. Render the initial simulator depth and call `initialize`. Wait for its one-frame RGB result. 2. Let the policy consume that observation and choose actions. 3. Advance the simulator for four render frames, recording the depth at each frame. 4. Submit those four depth frames with `advance`. Pause simulation time while rendering completes. 5. Match the result's episode and step identifiers, consume its ordered RGB frames, and repeat. At the documented 30 FPS simulation cadence, four frames represent about 133 ms of simulated time. The policy cannot use the intermediate rendered observations to revise actions inside that chunk. A policy needing a new rendered observation before every simulator frame is not supported by this contract. Simulator physics can use smaller internal timesteps; render cadence and policy cadence are separate choices. Keep one render step outstanding. Register result listeners before sending commands. A command acknowledgement means accepted, not rendered. Use `step_result` as the observation source; encoded video previews can drop or repeat frames. On timeout, inspect episode state and retrieve or retry the same step rather than advancing simulation again. This tests policy behavior with generated visual observations. Compare against simulator RGB and real-camera evaluation where available. Measure task outcomes from simulator state, and check whether generated appearance preserves task-relevant geometry and objects. Reduced visual mismatch is a hypothesis to evaluate, not an established reduction in the full sim-to-real gap. ## Send depth and receive frames Use a normal Reactor session with Python SDK 1.10.0 or JavaScript SDK 3.2.0. Register a `step_result` listener before submitting commands. These are session commands, not new REST endpoints. | Command | Input | Result | | - | - | - | | `initialize` | One `depth_png_b64`, `prompt`, optional `total_frames`, `aspect_ratio`, `seed`, `preview` | Accepts step 0; later emits one RGB frame | | `advance` | `episode_id`, next `step_index`, four `depth_png_b64` strings | Accepts the step; later emits four RGB frames | | `get_episode_state` | None | Current episode, pending status, latest completed step | | `get_step_result` | `episode_id`, latest completed `step_index` | Re-emits the cached result without inference | | `reset` | None | Clears episode, cached result, uploaded video, and pending playback | `step_accepted` confirms acceptance. `step_result` contains `episode_id`, `step_index`, `first_frame`, ordered `frames_png_b64`, corresponding `sha256` hashes of decoded RGB uint8 pixels in row-major order, and `complete`. Match both identifiers and consume each result once; correlated replies can also reach the SDK message callback. `step_failed` means the step cannot complete; correct the input and initialize a fresh episode. Use prepared RGB 8-bit PNG depth visualizations, base64 encoded without a data-URL prefix. Metric float arrays, 16-bit depth, and ordinary RGB footage are not accepted substitutes. The [metric-depth preparation example](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/simulation/cosmos-transfer#prepare-depth-from-your-simulator) shows fixed near/far normalization and invalid-depth handling; use the same bounds throughout your episode. Each PNG must already match the selected output size: 832×480 for `16,9`, 736×544 for `4,3`, 640×640 for `1,1`, 544×736 for `3,4`, or 480×832 for `9,16`; episode mode does not resize or crop. Each encoded input PNG is limited to 4 MiB. Only depth is supported in this mode. `total_frames` is a finite `1 + 4N`, from 1 through 597 (default 121). Prompt, framing, seed, and preview selection remain fixed until reset. Set `preview: false` for reliable PNG results only; with preview enabled, the same generated frames also appear on `main_video`. The encoded preview is for viewing and is not the authoritative observation source. Large results use the existing SDK data-channel chunking; older clients with a plain 256 KiB limit are unsupported. Keep one step outstanding. An identical retry of the most recent completed `advance` returns its cached result; changed input is rejected. Older results are not retained. On timeout, query state, retrieve the latest completed result or retry the same input. Never increment `step_index` merely because a timeout occurred. Session loss requires a new episode; there is no checkpoint/resume. Reset before switching between episode and uploaded-video modes. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.