Training gives you a model. This page covers what comes next: finding it, getting it ready to use, and running it next to your robot. In this release a model runs on hardware you own. EmbodiFlow gives you a copy-paste command that downloads the model and starts a policy server your robot client can talk to.
Find your models
Open Models in the sidebar to see every model in the team, or Models inside a project for just that project. The team list shows one card per model with its project, policy family, status, when it was trained or imported, and its evaluation. Search by name, or filter by Project and Policy family.
The evaluation compares the model's prediction error with simply repeating the last action, and says whether it's lower or higher. A model without an evaluation shows — and says it hasn't been evaluated yet. Not evaluated is not a pass. And even a good evaluation only measures predictions on held-out data, not how the model does on a robot.
Inside a project, Models lists the training jobs and the models side by side. Open a model to see its training curve, checkpoints and logs (see Train a model). Its Overview tab lists the robot protocols it can be deployed over under Deploy via.
Promote a model before you deploy it
Every model starts as Draft, and a draft can't be deployed. So the first step is to promote it to Registered. Open Deployments in the sidebar: the Weights tab lists every model version with its status and where it came from (Trained or Imported). Open the menu on the row and choose Promote.
Trained a model somewhere else? Bring it in from the same tab. Choose Import checkpoint, pick the project, name the version, choose the Policy family and select the checkpoint files; they go straight from your browser to storage. If you set an Action dimension, also enter the Joint order (comma-separated). An imported checkpoint starts as a draft too.
Run a model on your own computer
Open Deployments inside the project. As the page puts it: pick a model, then choose where it runs.
Choose the model
Under Model, pick a registered model. Drafts aren't listed here; if the project only has drafts, the page tells you how many need promoting.
Choose where it runs
Under Where will the model run?, choose On my robot's computer. You get a run command for your own GPU machine, with the lowest latency, and nothing is registered on our side. The page also shows In EmbodiFlow cloud, but hosted inference endpoints aren't offered at launch, so run the model on your own computer for now.
Choose the robot protocol
Under Robot protocol, pick the wire your robot client already speaks. There are exactly two:
- OpenPI WebSocket (
openpi-ws) on port 8000, for the OpenPIopenpi_client. - LeRobot gRPC (
lerobot-grpc) on port 8081, for the unmodified LeRobotrobot_client.
Both carry the same thing, observations in and action chunks out, so the choice only depends on the client you run. A protocol the model doesn't support is greyed out with the reason.
robot_client can't send a credential. Open port 8081 only on the robot's private network.Choose the robot and the hardware
Pick the Embodiment: the robot profile that tells the server about its joints and cameras. Then pick the Target hardware. x86 with NVIDIA CUDA is the usual choice. A Jetson option is listed, but it hasn't been tested on Jetson hardware yet. CPU only answers with a mock policy instead of your weights: handy for checking the wiring, but it can't drive a robot.
Generate the command
Choose Generate package. Under Package result you get the Run command, the Runtime image, and What this host needs (the GPU runtime and the minimum GPU memory). Copy the command to your robot computer and run it: it downloads the model and starts the policy server. The download stays valid for a while, so you can rerun the same command instead of generating a new one. There is no device registry, and EmbodiFlow never sees or manages that machine.
Check the connection
Before a model goes near a robot, do a dry run: start the server, point your robot client at it, and confirm that actions come back. A dry run proves the connection works; it doesn't prove the policy can do the task. Running the robot, and keeping it safe, stays with you. EmbodiFlow doesn't control the robot or judge how the policy behaves on it.