How Many Demonstrations Does a Robot Policy Need?

There is no single number, and any article opening with one is quoting a trainer's floor rather than what your task needs. What can be given honestly is that floor, the studies that measured the trade, a conversion from published hours into episodes on a small arm, and two cheap experiments that answer it for the recordings you already have.

Task difficulty and scene variation decide the answer, and both swamp the raw count: the same 50 demonstrations are plenty for one task and useless for another on the same arm. Below is what the trainers accept, what the literature measured, and how to tell which side of that line your LeRobot dataset sits on.

The floor: what the trainers will actually accept

Every policy on this platform has a minimum episode count enforced before the form rents a GPU. These are gates, not recommendations. A vision-language-action model trained on a handful of trajectories produces a checkpoint that loads, moves the arm and does nothing useful, which is expensive to diagnose afterwards.

What the published record actually measured

Five studies bracket the question. They disagree about the number and agree about the mechanism: what you vary between episodes matters more than how many you record.

RT-1: capping episodes per task cost less than dropping tasks

The RT-1 dataset is about 130,000 episodes over more than 700 tasks, gathered across 17 months with 13 robots. Section 6.5 and Table 7 of the RT-1 paper separate the two axes: to shrink data without touching diversity they capped examples per task; to narrow diversity without touching volume they removed the tasks with the least data.

Read the last row against the second. Dropping a quarter of the tasks while keeping 97 percent of the frames landed at 54 percent generalization; halving the data while keeping every task landed at 50 percent. The paper's own summary: diversity matters more than quantity. Choosing between 200 episodes of one grasp and 50 each of four related grasps, this points at the second.

BC-Z: 37 demonstrations, or 1,000, for the same task

The BC-Z paper collected 25,877 robot demonstrations totalling 125 hours across 100 manipulation tasks, with 12 robots and 7 operators, plus 18,726 human videos. Its appendix holds the most useful single data point in the imitation learning literature for anyone with one arm on a desk.

That is why the question is unanswerable in the abstract: a fixed camera, one object, one pose and controlled light is a different problem from a bench somebody walks past. More on this in our BC-Z article on what scale really means.

robomimic: the task decides, not the count

The robomimic study trained the same BC-RNN agent on 20, 50 and 100 percent subsets of human data. The proficient-human sets hold 200 demonstrations for Lift, Can and Square, and 300 for the bimanual Transport task. These are the image-based numbers from its Table 27.

Forty demonstrations solved Lift completely and the other 160 bought nothing. The same forty on Square scored 29.3 percent, and the full 200 still left 18 percent failing. One robot, one algorithm, a fivefold difference in what enough means. Ask which row your task resembles before you ask for a number.

Data scaling laws: 50 per environment-object pair

The ICLR 2025 study Data Scaling Laws in Imitation Learning for Robotic Manipulation collected over 40,000 demonstrations and ran more than 15,000 real-world rollouts on exactly this question. Its findings are the most directly actionable of the five.

• Generalization scales approximately as a power law with the number of training environments, objects, or environment-object pairs.
• It does not follow a clean power law in the number of demonstrations: correlation coefficients for their two main tasks were -0.62 and -0.79, which the paper calls only a weak relationship.
• Demonstrations saturate. With 8, 16 and 32 environment-object pairs, performance plateaued at 400, 800 and 1,600 total demonstrations.
• The recommendation: 50 demonstrations per environment-object pair, and spend the rest of the budget on more pairs.
• Verification run: 32 pairs at 50 demonstrations each gave 85.0, 92.5, 87.5 and 90.0 percent success on four tasks, in 8 unseen environments with 2 unseen objects each.

The paper is explicit that harder dexterous tasks may need more per pair. It is still the closest thing to a defensible default, and it lands just above the floor enforced here.

Pi0.5: more places, the same amount of data

Physical Intelligence ran the cleanest version of this experiment in the Pi0.5 paper: mobile manipulation data from 3, 12, 22, 53, 82 and 104 locations, with the training steps (40k) chosen so each model saw the same number of unique samples, controlling for dataset size while only the location count varies. Performance on unseen mock homes rose steadily, and the 104-location model matched a control trained directly on data from the test homes.

What the model builders themselves shipped

The two NVIDIA figures get quoted against each other and are not really in conflict: the FAQ's roughly 100 trajectories is a simple fixed-location pick and place, while the 200-episode figure is apple-to-plate on a Unitree G1 humanoid, which the FAQ's own bands put well above a desk arm. Read the band that matches your embodiment, not the smallest number on the page. DROID is a scale reference only, unpacked in our DROID article.

The counter-example worth remembering

ALOHA gave Thread Velcro twice the data of every other task, 100 demonstrations against 50, because it was the hardest. It still finished at 20 percent: 92 percent at the lift, 40 at the grasp, 20 at the insert, roughly halving at every stage. Doubling the episode count did not buy the millimetres.

Turning published hours into SO-100 episodes

Papers report hours; recording sessions count episodes. The conversion needs one real number, so read it out of lerobot/svla_so100_pickplace, the reference SO-100 set released with the SmolVLA paper.

curl -sL https://huggingface.co/datasets/lerobot/svla_so100_pickplace/resolve/main/meta/info.json \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d["total_episodes"], d["total_frames"], d["fps"])'
# 50 19631 30
# 19631 frames / 50 episodes / 30 fps = 13.1 seconds of robot motion per episode

The bench-time column is arithmetic, not a measurement: the lerobot-record defaults shipped in v0.6.1 (fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50) plus 13.1 s of motion. The reset window dominates, and most operators cut reset_time_s to 10 or 15 seconds once they have a routine, roughly halving the wall clock. ALOHA's reported 30 to 60 minutes for 50 demonstrations is the order-of-magnitude check. Caveat on the last row: Pi0's hours are bimanual and mobile with far longer episodes.

A starting number for a single SO-100 bench

Combining the floors with the evidence gives a defensible place to start a first fine-tuning run. The third column matters more than the second.

Two experiments that answer it for your dataset

Everything above is other people's benches. Two runs on a 24 GB card, a couple of dollars each, tell you about yours: hold out episodes, then retrain on half the data. Every flag below exists in lerobot v0.6.1; check your install with lerobot-train --help first, and see train your first policy for the end-to-end version.

1. 1
   Hold out episodes and watch the held-out loss

   --dataset.eval_split holds out a fraction of episodes per task; --eval_steps computes loss on them every N steps. lerobot rejects eval_steps > 0 unless eval_split > 0, so set both. Training loss falling while held-out loss flattens or rises means memorisation, and more of the same is the wrong purchase.

   bash

   lerobot-train \
     --dataset.repo_id=your-name/your_task \
     --dataset.eval_split=0.1 \
     --eval_steps=500 \
     --policy.type=act \
     --steps=100000 \
     --batch_size=8 \
     --seed=1000

2. 2
   Train the same recipe on half the data

   --dataset.episodes takes an explicit list of indices. Train once on the even half and once on everything, same seed and step count, then evaluate both on the arm. If the half-data checkpoint matches the full one, the next fifty of the same will not help either.

   bash

   lerobot-train \
     --dataset.repo_id=your-name/your_task \
     --dataset.episodes='[0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48]' \
     --policy.type=act \
     --steps=100000 \
     --seed=1000 \
     --output_dir=outputs/half

3. 3
   Delete the episodes you know are bad first

   There is no exclude flag on the trainer. Cut bad recordings out of the dataset with lerobot-edit-dataset, writing to a new repo id so the original survives. Sixty episodes with twelve defective ones trains like forty-eight, and the twelve teach the wrong thing.

   bash

   lerobot-edit-dataset \
     --repo_id your-name/your_task \
     --new_repo_id your-name/your_task_clean \
     --operation.type delete_episodes \
     --operation.episode_indices "[7, 19, 33]"

4. 4
   Evaluate on the arm, not on the loss curve

   Loss is a poor proxy for success. Run each checkpoint on the robot from fixed start poses and score it. In v0.6.1 lerobot-record is a pure data-collection tool with no policy inference; lerobot-rollout runs a trained policy on real hardware. Ten trials per pose is roughly the papers' protocol.

   bash

   lerobot-rollout \
     --strategy.type=base \
     --policy.path=outputs/half/checkpoints/last/pretrained_model \
     --robot.type=so100_follower \
     --robot.id=my_arm \
     --robot.port=/dev/ttyACM0 \
     --robot.cameras='{top: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}' \
     --task="Pick the cube and place it in the box." \
     --duration=30

Getting the episodes recorded

pip install 'lerobot[core_scripts,feetech]'

lerobot-find-port
lerobot-calibrate --robot.type=so100_follower --robot.id=my_arm --robot.port=/dev/ttyACM0

lerobot-record \
  --robot.type=so100_follower --robot.id=my_arm --robot.port=/dev/ttyACM0 \
  --teleop.type=so100_leader --teleop.id=my_leader --teleop.port=/dev/ttyACM1 \
  --robot.cameras='{top: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}' \
  --dataset.repo_id=your-name/your_task \
  --dataset.single_task="Pick the cube and place it in the box." \
  --dataset.num_episodes=60 \
  --dataset.episode_time_s=20 \
  --dataset.reset_time_s=15 \
  --dataset.push_to_hub=false

Where more demonstrations will not save you

A large share of "I need more data" turns out to be something else wearing a data costume. Rule these out before booking another recording afternoon.

• Defective episodes. Swapped camera indices, frozen frames, a joint parked against its limit. The bad ones teach the wrong thing. See loss falls but the policy does nothing.
• Coverage, not volume. If the arm succeeds from recorded poses and fails elsewhere, that is a policy that only works in one setup. The fix is different poses, not more of the same.
• Format. A LeRobot v3.0 dataset crashes the GR00T loader and surfaces as a failed job, not a shortage. See dataset rejected as v3.
• Latency. The control loop is 20 to 485 ms per action step depending on the model, and public-internet round trips on top turn a working policy into a hesitant one. Remote inference suits slow pick and place, not fast reactive motion. No episode count fixes it.
• The gripper. If the approach is right and the gripper closes on nothing, check the wrist camera before the episode count. See gripper does not close.
• Lighting. NVIDIA's FAQ notes vision-language backbones struggle with hard shadows and hue shifts, and recommends colour jitter plus 20 to 50 episodes under different lighting rather than more under the same lamp.

What the extra episodes cost

Recording time is the expensive input; the GPU is not. A second training run to test whether 100 episodes beats 50 costs less than the hour it takes to record the extra 50.

Full numbers are on the pricing page, and the training matrix links every model-and-arm pair to its guide, for example SmolVLA on the SO-100 or GR00T N1.7 on the SO-100. Still choosing between the 24 GB models? ACT against SmolVLA is the head-to-head, and the arena lists 85 VLA models with 332 benchmark results, each linked to its source.