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

# DROID variant

> Compatibility and checkpoint selection for FLUX 3 Action DROID.

| Property | Contract |
| - | - |
| Model | `reactor/flux3-action-droid` |
| Documented model release | `0.3.0`; see [release notes](/robotics/flux-action/droid/changelog) |
| Reference embodiment | DROID: seven-joint Franka arm and one gripper |
| Observations | Wrist RGB, two exterior RGB views, seven measured joint angles, gripper closed fraction, task instruction |
| Output | 32 × 8 absolute joint targets and gripper closed fraction; 15 Hz action samples |
| Protocol | One `state_json` request → one matching `action_prediction` |

The [upstream model card](https://huggingface.co/black-forest-labs/flux-3-action-droid) describes
the DROID policy and its checkpoint variants. Compatibility requires the DROID camera, state, and
action conventions, not only a seven-joint arm.

## Checkpoint choices

| Selection value | Upstream variant | Precision |
| - | - | - |
| `base-bf16` | Base | BF16 |
| `base-fp8` | Base | FP8 |
| `gd-bf16` | GD | BF16 |
| `gd-fp8` | GD | FP8 |
| `sd-bf16` | SD | BF16 |
| `sd-fp8` | SD | FP8 |

For a first run, use the available default returned by `get_checkpoint`, as the quickstart does. To
select another checkpoint, call `get_checkpoint` and inspect `checkpoint_selected.available` before
selecting. The schema enumerates six choices, but a worker may expose only a subset.
`select_checkpoint` pins the choice for the session. Repeating that choice is accepted; changing it
requires a new session, including after `reset`. If no selection is made, the first valid request
pins the default; inspect the reported choice rather than assuming availability.

Checkpoint labels identify model variants and precision, not an end-to-end latency guarantee.
Evaluate task quality and capture-to-execution latency in your own setup.

[Request your first actions](/robotics/flux-action/droid/quickstart), then implement the
[simulator bridge](/robotics/flux-action/droid/simulation). Use the
[API reference](/robotics/flux-action/droid/reference) for exact fields and payloads.


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