> ## 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. # Render a depth sequence > Turn a recorded simulator trajectory into generated RGB video. Use Cosmos3 Nano Sim Transfer when you have already recorded a trajectory and want to see it with a different visual appearance. You supply the control video and a scene description; Reactor streams the generated RGB frames back to your application. ## Run the example The [recorded-control cookbook example](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/simulation/cosmos-transfer#render-a-recorded-trajectory) includes a synthetic fixture generator, a hosted Python client, bounded readiness checks, and a saved preview snapshot. Start with its depth video, then substitute your own simulator output. ## Upload and render 1. Export a supported control video from your simulator or preparation tool. 2. Connect a Reactor session and upload the complete control clip using the [SDK upload API](/concepts/file-uploads). 3. Wait for source readiness, then send `generate` with a scene caption and output settings. 4. Inspect `main_video` and wait for `done` or `failed`. 5. While idle, reuse the same source with another caption to compare appearance variants. These are operations within one session, not separate render-job HTTP endpoints. The API does not return a durable job ID or a downloadable training-video artifact. ## Prepare the input Upload a complete video with a video MIME type, up to 128 MiB. It must contain at least the requested number of frames at 30 or 29.97 FPS. This is the input/playback cadence, not a guarantee of generation throughput. Prepare one supported control representation yourself: `depth`, `edge`, `blur`, or `seg` (segmentation). Start with depth exported from your simulator. ### What `control` means `control` declares the representation already present in your uploaded video. It does not extract that representation from ordinary RGB footage. Prepare the matching pixels before uploading: | Value | Upload | Typical use | | - | - | - | | `depth` | A consistent RGB8 depth visualization | Render geometry from an existing simulator with a new appearance | | `edge` | An edge-map video | Constrain generated appearance using image outlines | | `blur` | A blurred RGB video | Supply coarse color and layout cues; output can remain soft | | `seg` | A video of stable, color-coded regions | Condition on region layout; label IDs and palettes are not automatically mapped | These are learned visual constraints, not guarantees of exact geometry or label preservation. Selecting `seg` does not perform segmentation, and selecting `depth` does not estimate depth. The incremental episode interface accepts **depth only**; these four choices apply to `generate`. Once a **fresh** `state_update` after your upload reports `has_source: true` and `generating: false`, send the `generate` command. This example is its JSON payload, not an HTTP request body: ```json theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} { "prompt": "A robot arm moves across a tabletop in a softly lit room.", "control": "depth", "num_frames": 121, "aspect_ratio": "16,9", "seed": 42 } ``` | Field | Accepted values | | - | - | | `prompt` | Nonempty scene caption | | `control` | `depth` (default), `edge`, `blur`, or `seg` | | `num_frames` | 1–600; default 121 | | `aspect_ratio` | `16,9` (default), `4,3`, `1,1`, `3,4`, or `9,16` | | `seed` | Integer from 0 to 4,294,967,295; default 42 | Output sizes are respectively 832×480, 736×544, 640×640, 544×736, and 480×832. Uploaded controls are directly resized. Their aspect ratio must match the selected output within 3%; mismatches are rejected. Account for resizing when comparing labels. ### Export metric simulator depth For a concrete conversion, use the [cookbook depth-preparation example](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/simulation/cosmos-transfer#prepare-depth-from-your-simulator). It accepts ordered 2D floating-point camera-depth arrays in meters and writes RGB8 PNGs plus 30 FPS video. It includes synthetic metric inputs so you can try it before connecting a simulator. Choose fixed near/far bounds for the workspace: this recipe maps near to white and far to black, clips out-of-range depths, and maps invalid pixels to far/background. Do not normalize each frame independently. Convert nonlinear depth buffers to metric depth first. Render at the selected canvas with consistent camera projection; the converter does not resize. This is an explicit starting recipe, not a guarantee that every simulator's depth distribution produces accurate observations. ## Follow generation The `main_video` track carries RGB preview frames as they become available. `state_update` reports source readiness and whether generation is active. `done` reports the number of generated frames queued for playback; the stream may still be draining. `failed` reports an input problem discovered during generation. Invalid commands are refused, including `busy`, `missing_control`, and `invalid_input`. Upload only while idle and validate the video type and 128 MiB size limit locally. With Python SDK 1.10.0, `upload_file` can return a file reference even when the model rejects an upload; upload-hook refusal codes are not reliably delivered to the caller. A file reference confirms transport, not model acceptance. Wait for a fresh source-readiness update with a timeout. Do not reuse a cached `has_source: true` flag: a rejected replacement can leave the previous source intact. A video MIME type alone does not establish that the clip contains usable frames. Decode, frame-count, FPS, and aspect validation can still emit `failed` during generation. Handle this separately from a command refusal. The cookbook example starts from a reset state to avoid silently reusing an old source. It saves successful render evidence before its final cleanup reset. A cleanup failure is recorded as `cleanup_warning` without discarding the preview or report; generation failures still fail the run. Wait until the request is no longer generating before starting another run. You can reuse the uploaded control with a different prompt. `reset` stops generation at a safe boundary, clears the control, and flushes pending playback; upload again before the next request. There is no pause command. ## Next steps [Connect to a simulator](/robotics/cosmos/nano-sim-transfer/connect-a-simulator) to supply depth incrementally, or [generate appearance variants](/robotics/cosmos/nano-sim-transfer/appearance-variants) to explore lighting and materials for a recorded trajectory. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.