Skip to main content
This guide runs the RLDX-1 cookbook client against RLDX-1 deployed in your account. The client sends synthetic camera frames and synthetic state.
Do not send the returned actions to a robot. The synthetic inputs do not represent real observations. The client simulates action execution and does not implement a robot controller.

Requirements

The client uses Python 3.12 and reactor-sdk >= 1.6.0, < 2. On macOS, install uv with Homebrew:
For other platforms, follow the uv installation guide. From the cookbook repository root, install the client:

Run the client

Create an API key for the same Reactor account as the deployment. CLI sign-in does not set REACTOR_API_KEY for the Python client. Replace <account-slug> below with the account slug that the CLI printed when you published the model. Wait for the model to become ready before you run the client.
In a new terminal, return to models/rldx-1/client and activate .venv again. The client allows 300 seconds to connect by default. Startup can include image and checkpoint loading, especially after a deployment scales to zero. Use --connect-timeout to change that wait. Check model status and logs if the connection times out.

Example output

This abbreviated example shows the output format. Angle-bracket placeholders stand for results from your run, not measured performance claims.
For latency metrics, p50 is the median and p99 is the 99th percentile. In streaming mode, cadence follows the server execution horizon. In RTC mode, requests follow the client execution horizon. A late response does not shift the control timeline. The client prints RTT every 10 seconds and its average in the final summary. N/A means no valid RTT measurement is available. Use --stats-interval 5 for five-second reports or --stats-interval 0 to disable them. If the deployment does not return source echo fields, E2E and echo correlation are unavailable. View skew can still be available because frames retain their shared capture time.

What the handshake selects

The client reads the model_schema handshake. It does not hardcode the views, state layout, or control rate. The handshake selects:
  • The views (left_view, right_view, and wrist_view), resolution, and control rate.
  • The state vectors and their lengths.
  • The state carrier, either frame metadata or set_state_json.
The client reads one clock value with time_micros() at each observation tick. It sends that value as capture_time_us on all three frames. Use this monotonic clock instead of time.time(). It serializes one state snapshot and attaches the same bytes to each frame when the carrier is frame_metadata. When the handshake announces capture_us and seq in state_tag_keys, the client includes them in the state JSON. RLDX-1 echoes them as source_capture_us and source_seq on the action chunk. The client uses the echo to identify the observation that produced the action. The correlation fields source_capture_us, source_seq, and view_skew_us can be null. Null means the measurement is unavailable, not zero.

Guided RTC

This cookbook configures guided Real-Time Chunking (RTC) in config.yml. The client controls inference timing when the handshake announces inference_trigger: client_request. The model uses a 20 Hz control rate and an action horizon of 16. It uses an RTC execution horizon of 8 and an RTC delay of 5 control steps. Each returned chunk contains 16 actions, but the client requests a replacement every 8 steps. The scheduler starts in a hold state and requests the first plan without a prefix. For later requests, it includes the next 5 actions from the active plan as a prefix. It continues simulated execution of that plan while inference runs. At install_step, it discards the returned prefix and installs the remaining actions. Each request and response carries the active plan ID and install metadata. A late response or an invalid plan chain triggers reset and returns the scheduler to its hold state. If a deployment announces inference_trigger: streaming, the server controls inference timing automatically. When state is missing or invalid, the model applies its configured fallback. The default hold_last value reuses the last valid state and skips inference until the first valid state arrives. The client reports a command_error with command="state" when this fallback engages. Other configurations can fill missing state with zeros or skip inference. Inspect these errors even when actions continue to arrive. For the full client, metrics, and transport pattern, read the complete RLDX-1 cookbook guide.