Robotics Startups Building on LeRobot: What You Get, What You Do Not

If you are starting a robotics company in 2026 and you are not writing your own motor bus driver, your stack probably begins with huggingface/lerobot. That is not a marketing claim. It is what the dependency graph looks like: NVIDIA ships GR00T inside it, Physical Intelligence's Pi0 family has a reference implementation in it, and the tag on the Hugging Face Hub that identifies a robot dataset is literally the string LeRobot.

This article covers what the library actually hands you, what it very deliberately does not, and who is demonstrably building on it. Everything below was checked against the repo, the docs and the package index on 24 August 2026. Where upstream has changed, the version is named. If you want the shorter product-level version first, the five policies AY-Robots can train and the model and arm matrix are the practical entry points.

What LeRobot is, precisely, in August 2026

Two of those numbers deserve a second look. 816 open issues and pull requests against 252 contributors is a healthy, busy project, not a finished one. And Python >= 3.12 is a hard floor as of 0.6.1, which is the single most common reason a team's existing robot control machine cannot just `pip install lerobot` on Monday morning.

The four things the stack actually gives you

1. A dataset format that other people already speak

The LeRobot dataset format is the part of the stack with the highest leverage. An episode is stored as synchronised MP4 video plus Parquet columns for state and action, with metadata that names each joint and camera. Because the format is fixed, a dataset recorded on somebody else's SO-100 loads in your training script without a converter.

from lerobot.datasets.lerobot_dataset import LeRobotDataset

# Streams straight from the Hugging Face Hub, decodes video for you
dataset = LeRobotDataset("lerobot/aloha_mobile_cabinet")

episode_index = 0
print(f"{dataset[episode_index]['action'].shape=}")
print(dataset.features.keys())      # observation.state, observation.images.*, action, ...
print(dataset.num_frames, dataset.fps)

2. One Robot interface, plus a plugin bus that third parties actually use

Natively supported hardware in 0.6.1 is SO100, LeKiwi, Koch, HopeJR, OMX, EarthRover, Reachy2, gamepads, keyboards, phones, OpenARM, Unitree G1 and reBot B601. That list is not the interesting part. The interesting part is the discovery rule: LeRobot imports any installed package whose name starts with lerobot_robot_, lerobot_teleoperator_ or lerobot_camera_, and the type it registers becomes available to every CLI command immediately.

# Install a vendor plugin, then use it like built-in hardware
pip install lerobot_robot_<name> lerobot_teleoperator_<name>

lerobot-record \
    --robot.type=<robot_name> \
    --teleop.type=<teleoperator_name> \
    --dataset.repo_id=${HF_USER}/my-dataset \
    --dataset.num_episodes=5

This is why the hardware list in the docs undersells reach. The official third-party page names integrations maintained by the vendors themselves, which is the clearest available signal of who is invested in the stack:

3. Policy implementations you did not have to write

As of the 0.6.1 README, LeRobot carries twenty-two model implementations across five families. For a company, the value is not that they are state of the art; it is that they share one config system, one training loop and one checkpoint layout, so switching from a small imitation learning baseline to a large vision-language-action model is a flag change rather than a rewrite.

AY-Robots trains five of these as managed jobs, and the ACT, SmolVLA, Pi0.5 and GR00T N1.7 pages carry the parameter counts, GPU tiers and measured per-step latency side by side. If you want the wider research picture instead, the model arena compares 85 VLA models across 332 benchmark results with every value linked to its source.

4. Four commands that are identical on every arm

Teleoperate, record, train, deploy. The teleoperation loop and the recording loop are the same code path, which is the reason a demonstration you can drive is a demonstration you can store.

1. 1
   Teleoperate to check the arm and the cameras

   The id is what the calibration file is keyed on. Use the same id for recording and deployment or the joint offsets will be wrong and nothing downstream will make sense.

   bash

   lerobot-teleoperate \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem5AB90687491 \
       --robot.id=my_follower_arm \
       --robot.cameras="{front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
       --teleop.type=so101_leader \
       --teleop.port=/dev/tty.usbmodem5AB90689011 \
       --teleop.id=my_leader_arm \
       --display_data=true

2. 2
   Record a dataset

   Defaults matter here: --dataset.episode_time_s is 60 seconds, --dataset.reset_time_s is 60 seconds and --dataset.num_episodes is 50. During recording, the right arrow or n ends an episode early, the left arrow or r re-records it, and ESC or q stops and encodes.

   bash

   lerobot-record \
       --robot.type=so101_follower \
       --robot.port=/dev/tty.usbmodem585A0076841 \
       --robot.id=my_follower_arm \
       --robot.cameras="{front: {type: opencv, index_or_path: 0, width: 1920, height: 1080, fps: 30}}" \
       --teleop.type=so101_leader \
       --teleop.port=/dev/tty.usbmodem58760431551 \
       --teleop.id=my_leader_arm \
       --dataset.repo_id=${HF_USER}/record-test \
       --dataset.num_episodes=50 \
       --dataset.single_task="Grab the black cube" \
       --dataset.streaming_encoding=true

3. 3
   Train a policy

   The policy adapts itself to the number of joints and cameras stored in your dataset, so the same command works across arms. Add --job.target=a10g-small to run it on Hugging Face Jobs instead of your own machine.

   bash

   lerobot-train \
     --dataset.repo_id=${HF_USER}/so101_test \
     --policy.type=act \
     --output_dir=outputs/train/act_so101_test \
     --job_name=act_so101_test \
     --policy.device=cuda \
     --wandb.enable=true \
     --policy.repo_id=${HF_USER}/my_policy

4. 4
   Deploy and evaluate on the real arm

   lerobot-rollout replaced the ad hoc eval scripts. --strategy.type selects base (no recording), sentry (continuous recording with auto-upload), highlight (ring buffer plus keystroke save), dagger (human in the loop) or episodic. Slow VLAs want --inference.type=rtc.

   bash

   lerobot-rollout \
     --strategy.type=base \
     --policy.path=${HF_USER}/my_policy \
     --robot.type=so100_follower \
     --robot.port=/dev/ttyACM1 \
     --robot.cameras="{ up: {type: opencv, index_or_path: /dev/video10, width: 640, height: 480, fps: 30}}" \
     --task="Put lego brick into the transparent box" \
     --duration=60

Who is actually building on it

Adoption claims in robotics are usually unfalsifiable. These are not, because each one leaves an artefact you can open:

The most useful adoption number is the dumbest one. The Hub listing for the LeRobot tag reported 72,437 datasets when we counted it on 24 August 2026. The lerobot organisation itself hosts only 66 models and 188 datasets, so the overwhelming majority of that is community and company data rather than anything the core team published. A chunk of the first wave came from the worldwide LeRobot hackathon of 14 and 15 June 2025, whose Hub organisation still carries 992 members, 190 datasets and 12 models.

That is the honest shape of the ecosystem: a very large pile of hobby and hackathon data, a much smaller pile of curated company data, and a handful of vendors treating the plugin bus as a distribution channel. If you are collecting your own, what makes a dataset trainable matters far more than how many megabytes you have.

What LeRobot does not give you

This is the section that decides whether you ship. LeRobot is a research-grade library that is very good at the first mile. Everything after the first working policy is your problem.

# Pin hard. A robotics repo that floats its lerobot version will break
# on a Tuesday for reasons unrelated to your code.
pip install 'lerobot[core_scripts,training,smolvla]==0.6.1'

# On Linux the CUDA wheel depends on the install path, and this bites people:
#   uv source install  -> torch pinned to cu128, driver floor 570.86
#   pip install lerobot -> PyPI default is a cu130 wheel, driver floor 580.65
# If your driver is older than 580.65, install torch explicitly first.
pip install --index-url https://download.pytorch.org/whl/cu128 torch torchvision
pip install 'lerobot[core_scripts,training]==0.6.1'

The dataset format itself is a moving target too. LeRobotDataset v3.0 packs many episodes per file and moved metadata to Parquet; several trainers, including NVIDIA's GR00T loader, still expect v2.1 and crash on v3.0. The wider model landscape is in the VLA overview, and this particular failure has its own page at dataset rejected as v3. On AY-Robots the conversion happens in the pipeline, which is a small thing that stops being small the third time it happens to you.

Same goal, two routes

What a training run costs, either way

Cost is where the two routes stop looking similar. Upstream, you either own the card or you submit a Hugging Face Job and pay by the second against flavours such as t4-small, l4x1, a10g-large or a100-large. On AY-Robots the GPU is rented on a spot market by required VRAM, so the number is a range rather than a price.

One number to sanity-check yourself against: at 30 fps, 50 episodes of 30 seconds is about 45,000 frames, and robotics imitation learning typically converges in 5 to 10 epochs over the dataset rather than in hundreds of thousands of raw steps. If your step count implies 200 epochs, you are probably about to pay for overfitting. The pricing page and the training docs carry the platform-side detail.

The latency question, answered plainly

The honest limit of any cloud-served policy is inference latency. The five policies here sit between 20 ms and 485 ms per action step. Add a public-internet round trip to that and a working policy becomes a hesitant one. Remote inference is viable for slow pick-and-place. It is not viable for fast reactive motion, and no amount of engineering on the serving side changes that. If your task needs sub-100 ms closed-loop response, the model has to sit next to the servos.

LeRobot's own answer to part of this problem is asynchronous inference, introduced with SmolVLA: the robot keeps executing the current action chunk while the server is already computing the next one, so there are no idle frames waiting on the network. In the SmolVLA paper this finished tasks about 30 percent faster, 9.7 seconds against 13.75 seconds, and roughly doubled completions in a fixed time window.

# Terminal 1: the policy server (put this on the GPU machine)
python -m lerobot.async_inference.policy_server --host=127.0.0.1 --port=8080

# Terminal 2: the robot client (this one must sit next to the arm)
python -m lerobot.async_inference.robot_client \
    --server_address=127.0.0.1:8080 \
    --robot.type=so100_follower --robot.port=/dev/ttyACM0 --robot.id=arm_a \
    --policy_type=smolvla \
    --pretrained_name_or_path=lerobot/smolvla_base \
    --policy_device=cuda \
    --actions_per_chunk=50 \
    --chunk_size_threshold=0.5 \
    --debug_visualize_queue_size=True

So should you build on it

Yes, and then plan for the parts that are not there. LeRobot has won the interchange layer: the dataset format, the policy zoo and the plugin bus are all things you would otherwise build badly and maintain forever. It has not won the operations layer, and it is not trying to. Fleet state, data curation, checkpoint lineage, access control and GPU procurement are all still yours.

The practical pattern that works is: pin a version, keep your own thin wrapper around the four CLI commands, validate datasets before they reach a trainer, and treat every minor release as a migration with a test rather than a bump. If you would rather not run the operations layer at all, the recording walkthrough and first training run cover the managed version of the same path, and the SO-100 setup guide covers the hardware end. For the arm itself, SO-100 with LeRobot is the direct comparison of both routes on one robot.