Hugging Face Robotics Models: A LeRobot Guide for 2026

Teaching a robot arm a repeatable pick-and-place task starts with demonstrations, cameras and compatible hardware. Hugging Face provides policies and tools to build on; this guide compares four paths for choosing what to evaluate on your robot.

Choose your robot and task before choosing the policy. For one repeatable manipulation task with demonstrations from your hardware, evaluate ACT as a baseline. For language-conditioned manipulation, consider SmolVLA. Larger foundation policies such as π₀.₅ and GR00T need a closer check of embodiment, data and runtime compatibility.

Sources checked October 31, 2026. This is an implementation-selection guide, not a robot benchmark. We have not run physical robots or simulation trials for this article. Its recommendations are starting points based on official documentation and checkpoint descriptions.

What Hugging Face provides for robotics

LeRobot brings together policy implementations, datasets, robot and camera integrations, simulation and deployment tools. Its models return actions conditioned on observations; they are a different category from the chat models in our OpenRouter guide.

A vision-language-action model combines visual observations, language and robot state to predict actions. That does not mean a natural-language instruction is sufficient. The policy still needs inputs in the format it was trained or configured to use, and outputs interpreted correctly by the target robot.

Four evaluation paths

Sources: linked official pages as of 2026-10-31. ACT here is an implementation choice, not one universal pretrained checkpoint. The rows do not compare measured task success, and their licenses are not interchangeable.

SmolVLA's card describes its base checkpoint as intended for fine-tuning on a specific use case. The LeRobot π₀.₅ card explicitly limits its implementation to the released flow-matching action head, excluding other components described in the original work. GR00T's card describes post-training with real or synthetic data for a particular robot or task. Those details are more useful for implementation planning than download counts.

Before downloading weights, write down the interface

List the cameras, image sizes, frame rates, state fields and action fields available on your robot. Include units and joint ordering. Record the policy's expected observation and action formats alongside them. A shape-compatible tensor can still contain values in the wrong order or scale.

Next, check preprocessing and postprocessing. Image resizing, normalization, state mapping and action conversion belong to the model interface. LeRobot model examples include processor construction for a reason: copying a raw forward pass can omit part of the usable policy.

Finally, inspect the dataset. A checkpoint trained on demonstrations from another embodiment is not evidence that it will control yours without adaptation. The useful question is whether your data and integration support a credible fine-tuning and evaluation path.

A pilot that produces interpretable evidence

Choose one bounded task with observable completion. For example, move an object from a marked starting area to a target area. Define success before training: the object must end inside the target, the attempt must finish within a fixed time, and a reset must not be counted as a success.

Create training and held-out evaluation conditions. Vary object placement, lighting or background deliberately, and record which variation each attempt uses. Keep a demonstration count and separate training runs from evaluation runs. Do not select only the best-looking rollout video.

Report:

• Successful attempts divided by all attempted trials, with the count shown.
• Time to completion and how many attempts required intervention or reset.
• Which object positions and conditions were held out from training.
• The exact checkpoint, training configuration, data revision and robot setup.

Simulation can help test an implementation, but simulator success and physical deployment are separate results. Likewise, loading weights, computing a loss or predicting an action only confirms a piece of the software path. It does not measure whether the robot finishes the task.

For physical trials, use the robot's documented supervised commissioning process, limits and stop controls. The point is to make each trial bounded and repeatable, with interventions recorded instead of hidden.

Compute: distinguish training from inference

Training needs optimizer state and gradients that inference does not. Batch size, image resolution and the components you fine-tune affect memory. An advertised parameter count is not a measured training budget, and a successful CPU import is not a useful control-loop timing result.

Use LeRobot's compute hardware guide and the selected policy's current implementation to plan an experiment. Check the exact accelerator and dtype path on a Mac rather than assuming a CUDA recipe transfers unchanged. If inference runs on another machine, include network and preprocessing time when measuring action latency.

For a first project, a smaller policy with compatible demonstrations can be a more informative baseline than a larger model with an unresolved interface. Promote a larger policy only when the evaluation shows what it improves.

Keep physical robotics separate from office automation

Teamday's AI marketing team works on company tasks and deliverables; this article does not establish robot-control support in Teamday. Robotics belongs here as a technical guide to a distinct part of the Hugging Face ecosystem, rather than a claim that every AI model fits the same product workflow.

For other specialized models, see speech recognition, document extraction and video generation.

Checkpoint revision and license-metadata snapshots, retrieved 2026-10-31.