How Much Data Do You Need to Train a Robot Policy?

A demonstration is one recorded attempt at a task. An environment-object pair is one distinct combination of scene and target object. These are the two quantities you can spend money on, and they do not behave the same way.

The scaling study measured both independently and found a clean asymmetry:

Their efficient recipe was 32 unique environment-object pairs at 50 demonstrations each, roughly 1,600 episodes, evaluated on 8 environments the policy had never seen. That configuration reached approximately 90% success on unseen objects in unseen environments, and the collection fit into an afternoon with four people. The full paper is worth reading directly: Data Scaling Laws in Imitation Learning for Robotic Manipulation.

Read the two numbers next to each other. 1,600 well-spread episodes reached 90% generalization. The 40,000-demonstration total in the same study existed to map the curve, not because the policy needed it.

These are the planning bands we quote against. They assume real teleoperation on the target embodiment, training a modern imitation-learning policy, and they assume the count is spread across the diversity matrix rather than concentrated.

Two adjustments apply to every row.

Multiply by your acceptance rate. These are accepted episodes, meaning episodes that pass your acceptance bar and reach the training loop. Acceptance on complex tasks typically runs 70 to 85%. If you are billed per hour, the rejected fraction is on your invoice, so 3,000 ordered at 70% acceptance means paying for 3,000 and training on 2,100. Pricing on accepted episodes moves that risk off your side of the table, which is why we price that way.

Divide if you start from a pretrained checkpoint. Fine-tuning a pretrained vision-language-action model rather than training from scratch typically moves you toward the low end of each band, sometimes below it. The mechanism is the same one that made LoRA fine-tuning viable at 200 examples: the checkpoint already carries the general capability, so your data only teaches the specific.

Two public datasets do most of the pretraining work in this field, and both get misread as substitutes for your own collection.

The pooled multi-embodiment corpus averages roughly 120 timesteps per trajectory at 3 to 10 Hz control, gathered from single arms, bimanual setups and quadrupeds. It is a genuinely useful pretraining substrate and the original Open X-Embodiment paper is the reference for what is in it. What it is not is your data. It does not contain your gripper geometry, your camera baseline, your control frequency, your workcell, or your task. Data captured on somebody else's arm is useful for pre-training and not much beyond that, and any vendor selling it to you as a substitute for on-embodiment collection is selling you a policy that will not transfer.

The honest framing: public corpora change how many of your own episodes you need. They do not change whether you need them. If you plan to mix public pretraining data with your own corpus, settle the storage format early, since the pooled corpora ship in RLDS and the same content can differ by more than 40x on disk between formats. We compare them in LeRobot vs RLDS vs HDF5.

Six variables account for most of the variance between a program that needs 500 episodes and one that needs 8,000.

Embodiment match. Every millimetre of difference between the collection rig and the deployment robot is a distribution shift the policy has to absorb. Collecting on the exact target platform is the single largest reduction in required volume. Collecting on a similar arm and hoping is the single largest cause of a corpus that trains a policy which fails on the real machine.

Precision tolerance. A task with a 2 cm success window and a task with a 2 mm success window are not the same task. Tight tolerances need more demonstrations per pair, because the policy must learn a narrow action distribution rather than a broad one, and they need higher-quality teleoperation to produce them.

Task horizon. Success rate compounds. A five-step task where each step succeeds 95% of the time completes 77% of the time end to end. Long-horizon tasks therefore need per-step reliability that only comes from more data, or need decomposition into separately trained skills.

Contact richness. Free-space motion is easy to learn from vision. Anything involving sustained contact, deformation, or force control (cloth, cables, insertion, wiping) needs proprioceptive and force channels recorded cleanly and needs substantially more episodes.

Observation stack. More cameras and a wrist view generally reduce the demonstration count for the same performance, because occlusion is a major source of ambiguity that the policy otherwise has to resolve statistically. Adding a wrist camera is usually cheaper than adding a thousand episodes.

Operator consistency. A corpus recorded by twelve operators with twelve different strategies for the same task teaches a multi-modal action distribution, which is harder to fit. Some multi-modality is good (it is diversity). Uncontrolled multi-modality is noise. This is a protocol problem, solved by explicit demonstration guidelines, not by more volume.

The two numbers that make a schedule real are throughput and acceptance.

Work an example. A policy that must generalize across scenes and objects, sized at 2,000 accepted episodes, collected by trained operators at 25 usable episodes per hour, is about 80 hours of clean capture. That is not two working weeks. Scene changes, rig recalibration, review passes and re-runs of rejected episodes typically put it at four to six weeks of wall clock, and diverse data means many scene changes by definition. Any plan that assumes 2,000 episodes lands in ten days has assumed a single static setup, which is exactly the corpus that will not generalize.

The corollary on price: quotes below roughly $15 an hour almost always exclude QA rejection and replacement, so you pay twice for every episode that fails review. Compare quotes on cost per usable demonstration or the comparison is meaningless.

Before committing to a second collection round, run the subset curve. It costs one training run.

The curve tells you which problem you have:

The third row is the expensive one to miss, because the instinct when a policy underperforms is to order more data, and more data drawn from the same narrow distribution moves nothing. This mirrors the failure mode we see in language model evaluation, where teams add examples to a plateaued fine-tune instead of fixing coverage. Our guide on building evaluation datasets covers the held-out discipline that makes this test trustworthy.

Automated data generation systems can expand a small human corpus dramatically. One published system generated over 50,000 demonstrations across 18 tasks from roughly 200 human demonstrations by adapting them to new object poses and scene configurations, and it works across simulators and real robots. That is a 250x multiplier on human effort, and it is real, with a boundary: it multiplies coverage of configurations you can programmatically vary (object pose, initial state, scene layout), not coverage of the physics you never demonstrated.

The practical rule we use: synthetic generation is excellent for initial-state and pose diversity, weak for contact dynamics and material properties, and useless for tasks you cannot specify well enough to validate. We work through the general version of this tradeoff in when synthetic data works for AI training, and the robot-specific version in our comparison of teleoperation, simulation and human video as data sources.

Start from the deployment condition, not from a demonstration count.

Write down how many distinct scenes, object instances and lighting conditions the policy must handle in production. That is your diversity matrix. Target at least 30 environment-object pairs if the policy must generalize at all, and roughly 50 demonstrations per pair. That lands most single-task generalizing policies between 1,500 and 3,000 accepted episodes, which matches both the published scaling recipe and the bands we quote.

Then divide by your acceptance rate to get episodes recorded, divide by realistic operator throughput to get hours, and add the rig calibration and review time that per-hour quotes never include. Run the subset curve after the first delivery, not after the last one.

More of our writing on collection, formats, simulation and policy training sits in the Physical AI and robotics hub.

The question worth asking is not how much data a robot policy needs. It is how much of your budget is currently buying the eight-hundredth demonstration of a scene the policy already learned in the first fifty. For most programs, that fraction is the majority, and moving it to the diversity axis costs nothing and changes everything.