How Many Demonstrations Do You Need? What Published Work Reports

Why the question has no single answer

Buyers ask for a number to put in a request. The literature gives numbers, but each belongs to a specific setup: a policy class, a robot, a task family, an evaluation, and a way of counting. Copying one into a purchase order would carry over none of those conditions. Use the figures below to bracket a pilot, not to define a sufficient package.

What published work reports

Sources: Zhao et al., 2023; Fu et al., 2024; Mandlekar et al., 2023; Mandlekar et al., 2021; Brohan et al., 2022; Khazatsky et al., 2024; Open X-Embodiment Collaboration, 2023.

Three regimes appear:

• Single-task, small data. ACT reports 80-90% success on six real tasks from only 10 minutes worth of demonstrations, and Mobile ALOHA used 50 demonstrations per task. Both use specific low-cost teleoperated hardware, and tasks the authors chose.
• Multi-task, fleet scale. RT-1 collected about 130,000 episodes across 700+ tasks with 13 robots over about 17 months, with human-teleoperated demonstrations (Brohan et al., 2022). DROID spread collection over 50 data collectors across North America, Asia and Europe over 12 months, with a replicated rig at 13 institutions.
• Pooled cross-embodiment. Open X-Embodiment combined over a million trajectories across 22 embodiments and reports positive transfer between platforms.

Quantity is not the only lever

• Co-training. Mobile ALOHA reports that co-training with static ALOHA datasets raises success by up to 90% on its mobile tasks, so existing related data can change how many new demonstrations a task needs.
• Generation. MimicGen produced more than 50,000 demonstrations from about 200 human ones. Generated volume depends on seed quality; see real vs synthetic and simulation data.
• Quality. The offline-demonstrations study found results depend on demonstration quality, using datasets graded Worse, Okay and Better across six operators. Fewer good demonstrations can outperform more poor ones; see expert vs novice demonstrations.
• Variation. 100 demonstrations in one scene differ from 100 across ten. Coverage of objects, positions, lighting and operators drives generalization; see depth vs breadth collection strategy.
• Human video. A policy co-trained with human data can change the robot count needed, as discussed in what human demonstration video can support. Visual pretraining is a different stage; see imitation vs pretraining.

Factors that move your number

How to size a purchase

1. Define the task family and the success rate you need on a hardware protocol; see real-world policy evaluation protocols.
2. Run a pilot collection per task variant and measure policy success as data grows.
3. Write quantity as a phased commitment, not a sufficiency claim.
4. Reserve held-out episodes for evaluation.
5. Re-scope after each phase.

# Illustrative phased request (synthetic values, not recommended minimums)
phase_1_pilot: {tasks: 2, episodes_per_task: "buyer sets", sites: 1}
phase_2: {tasks: "same", episodes_per_task: "set after phase 1 curves", sites: 3}
holdout: {by: site, never_in_training: true}
report: [per_episode_quality_grade, operator_id, failure_tags]

Questions to ask suppliers

1. What counts as one demonstration in your units: episode, segment or minute?
2. What share of recorded episodes pass your quality gate?
3. How many operators contribute, and how are they graded?
4. Can you deliver in increments so we can measure learning curves?
5. How many variants of object, position and scene are covered per task?
6. Are failures and recoveries recorded and flagged?

Reading counts carefully

Units differ between papers. "Demonstrations", "episodes", "trajectories" and "minutes" are not interchangeable: one long-horizon episode can contain many sub-tasks, and an hour of footage can hold many short episodes or few long ones. Ask whether failed attempts, resets and truncated runs are counted. DROID's counts, for example, are given as trajectories and hours together, which lets you derive average length only if both are reported for the same subset.

Also note who collected the data. DROID used 50 data collectors, and RT-1 used a fleet of 13 robots; those programs paid for coordination, calibration and quality control as well as raw episodes. A small count from a single expert on a single rig is cheaper to organize but says less about variation.

What the figures do not tell you

None of these studies set a threshold below which a humanoid policy fails. They show that some tasks were learned from small sets under favorable conditions, and that broad capability was reported at much larger scale, usually with pooled or multi-site data. Your target lies somewhere between, and only pilot measurements on your embodiment will place it.

Discuss your requirements

State the task, embodiment and phases you want when you describe your requirements to SourceX. SourceX reviews the requirement and follows up about potential sources; scale and collection are scoped case by case, and a request does not guarantee a match. See the demonstrations hub, cross-embodiment robot datasets and the humanoid data guide.

Discuss your humanoid training-data requirements with SourceX.

Sources

• Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware — 10 minutes of demonstrations.
• Mobile ALOHA — 50 demonstrations per task, co-training.
• RT-1 — fleet-scale episode counts.
• Open X-Embodiment — pooled trajectories.
• DROID — distributed collection counts.
• MimicGen — generation from human demonstrations.
• What Matters in Learning from Offline Human Demonstrations — demonstration quality.