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

# Cosmos3 Nano Sim Transfer

> Turn simulator depth into realistic-looking RGB video.

Cosmos3 Nano Sim Transfer generates camera-like video from your simulator's depth frames and a scene
description. Your simulator determines the motion and physics; the model generates the visual
appearance.

For example, a simulated robot reaches for a cup. Feed its depth frames to Transfer with a
description of the room and lighting, then display the resulting RGB video or pass it to a
vision-based policy.

## What you provide and receive

| You provide | You receive |
| - | - |
| Prepared depth frames and a description of the scene | Generated RGB observations, with an optional video preview |
| A recorded control video and a scene description | A streamed RGB preview of the trajectory |

Use model identifier `reactor/cosmos3-nano-sim-transfer` with a Reactor session.

## Choose a workflow

> **[Render a depth sequence](/robotics/cosmos/nano-sim-transfer/render-a-sequence)**
>
> Start with a recorded simulator trajectory and inspect the generated video.

> **[Connect to a simulator](/robotics/cosmos/nano-sim-transfer/connect-a-simulator)**
>
> Supply depth incrementally and feed complete RGB results to your policy.

> **[Generate appearance variants](/robotics/cosmos/nano-sim-transfer/appearance-variants)**
>
> Explore lighting and materials for synthetic observation generation.

## Which use case fits?

* **Interactive visual rendering:** display a simulator trajectory with generated appearance.
  The video preview is for viewing and can drop or repeat frames.
* **Closed-loop integration:** pause simulator advancement until a complete depth-step result arrives,
  then let your policy consume its RGB observations. Feedback is once per four render frames.
* **Synthetic observation generation:** replay trajectories with varied appearance descriptions and
  evaluate output quality. Throughput matters more than latency; dataset storage and scheduling are
  your application's responsibility.

The [Transfer cookbook examples](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/simulation/cosmos-transfer)
provide runnable Python clients and synthetic inputs for recorded-video and incremental-depth workflows.

## Visual transfer and simulation

Transfer changes how a simulated scene looks. Your simulator still owns robot actions, collisions,
object state, and success criteria. Generated RGB is a synthetic observation, not a measurement from
a real camera. Evaluate its effect on your policy before assuming better real-world performance.

For an interactive learned environment driven directly by arm movements, use
[Cosmos3 Nano Sim Bimanual](/robotics/cosmos/nano-sim-bimanual/overview).


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