What a Robot Dataset Is Worth: Pricing Demonstration Data

Episode count is the number everyone quotes and the one that tells you least

Every listing leads with it. Two hundred episodes. Five hundred episodes. It is the first field in the metadata, it is free to compute, and it sounds like a quantity of something. Then you download the thing and discover that an episode is not a fixed unit. It is however long the operator held the record button, and across the public corpus that is a wildly variable number.

Take a real published dataset. lerobot/svla_so101_pickplace is a reference pick and place set from the LeRobot team. Its metadata says 50 episodes, which clears the 50 episode floor that GR00T N1.7, Pi0.5 and ACT all require here. It also says 11,939 frames at 30 fps. Do the division and the whole dataset is six minutes and 38 seconds of robot motion, under eight seconds per episode.

What the public market for robot data actually looks like

Before arguing about what a dataset should cost, it helps to know what is on the shelf. So we counted. On 23 August 2026 we paged the Hugging Face datasets API for everything tagged LeRobot, drew a random sample of 700 repositories with a fixed seed, and pulled each one's meta/info.json. Anyone can rerun this. It is two API calls and a loop.

# 1. count every LeRobot-tagged dataset on the Hub (follow the Link: rel=next header)
curl -s "https://huggingface.co/api/datasets?filter=LeRobot&limit=1000" -D headers.txt \
  | python3 -c "import json,sys; print(len(json.load(sys.stdin)))"
grep -i '^link:' headers.txt   # -> cursor for the next page

# 2. read one dataset's metadata without downloading a byte of video
curl -sL "https://huggingface.co/datasets/lerobot/svla_so101_pickplace/resolve/main/meta/info.json" \
  | python3 -c "
import json,sys
d = json.load(sys.stdin)
cams = [k for k,v in d['features'].items() if v['dtype'] in ('video','image')]
print(d['total_episodes'], 'episodes |', round(d['total_frames']/d['fps']/60,1), 'min |',
      d['fps'], 'fps |', d['codebase_version'], '|', d['robot_type'])
print('cameras:', cams)
"

Two things fall out. First, the public corpus is a long tail of tiny recordings: the median contribution is ten episodes, about three minutes of motion at the median episode length, one person trying the record a dataset tutorial once and pushing the result. The 19.5 minutes in the table above is a mean, and a handful of large repositories set it. Second, value is concentrated: seven datasets out of 679 hold nearly half the episodes in the sample.

Demand concentrates the same way. Across all 72,393 repositories the median 30 day download count is 18, the 99th percentile is 521, and the top ten repositories alone absorb 49.3 percent of every download. Those ten are almost entirely re-hosted conversions of the canonical corpora: Language-Table, DROID, BridgeData V2 and the RT-1 fractal data. Meanwhile 97.8 percent of public LeRobot datasets have never received a single like. The market is not thin, it is bimodal.

Six properties that actually move the price

1. Coverage, not volume

The clearest published result is Data Scaling Laws in Imitation Learning for Robotic Manipulation (Lin et al., arXiv 2410.18647, October 2024, revised through June 2026). They collected over 40,000 demonstrations and ran more than 15,000 real world rollouts to answer one question: what do you get for the next demonstration? Generalisation follows a roughly power law relationship with the number of environments and objects, and once demonstrations per environment cross a threshold, more of them have minimal effect. Their recipe is 32 environments, each with a unique object, 50 demonstrations each.

• That is 1,600 demonstrations, roughly 8.3 hours of motion at the 18.7 second median episode we measured.
• It is also 32 distinct scene setups, the part that costs a day of somebody's life to arrange.
• A 1,600 episode dataset shot in one corner of one room is worth far less than 400 episodes across 32 setups, and no metadata field distinguishes them.
• This is the mechanism behind a policy that only works in one setup: the dataset priced the wrong axis.

2. Yield, and whether the failures were kept

The DROID paper is unusually honest here. The released dataset is 76,000 successful trajectories, 350 hours, 564 scenes, 50 collectors, 18 replicated stations across 13 institutions, twelve months. It also reports roughly 16,000 further trajectories labelled not successful. That is a yield near 82 percent, so the real collection cost is about 1.2 times what the episode count suggests.

Discarded failures are a cost. Labelled failures are an asset. RoboMIND ships 107,000 trajectories across 479 tasks and deliberately includes 5,000 failure demonstrations, each with a recorded cause. A seller who kept and annotated their failures earns a genuine premium. Most of the public corpus deleted them.

3. Task language and metadata hygiene

This is where public data quietly loses its value. When Hugging Face built SmolVLA they went shopping in the same public Hub corpus we measured, and the SmolVLA paper records what they came back with: 481 community datasets, 22.9K episodes, 10.6M frames, filtered by embodiment type, episode count, overall data quality and frame coverage. The paper does not say how many repositories they started from, only that 481 survived the filter.

Then they repaired what they took. The paper reports placeholders such as task desc, vague commands such as Hold or Up, or no instruction at all, so they regenerated task descriptions with Qwen2.5-VL-3B-Instruct and normalised camera viewpoints. The LeRobot community datasets post (11 May 2025) documents the same failure modes and asks for 25 to 50 character task strings such as "Pick the yellow lego block and put it in the box".

4. Sensor layout

48.0 percent of sampled datasets have a wrist or hand mounted camera key. That single bit is worth more than a hundred extra episodes on any task where the gripper closes on something a fixed third person view cannot see. 3.2 percent had no camera stream at all, which makes them useless for every vision-language-action model on this platform.

• Two cameras is the modal layout, usually one overhead or front view plus a wrist view. 640x480 dominates; lighting and focus constrain quality long before resolution does.
• Camera keys are named by whoever recorded them. We saw front, top, wrist, side, laptop, camera1 and cam_high in one corpus. A key named laptop says nothing about where the lens pointed.
• Camera order has to survive fine-tuning and deployment. Swap two keys between recording and inference and the policy degrades without ever raising an error.

5. Provenance and licence

97.4 percent of all 72,393 public LeRobot datasets are Apache-2.0. That is not 72,000 deliberate licensing decisions, it is the default the tooling writes into the dataset card. 1.8 percent declare no licence at all, which leaves you no grant of rights to point at if anyone asks. The standard buyers apply here is old and boring: Datasheets for Datasets (Gebru et al.) argues every dataset should document motivation, composition, collection process and recommended uses, and the Hugging Face dataset card is the practical implementation of that idea.

6. Format, version, and whether it loads at all

A LeRobot dataset is not a folder of videos. Per the v3.0 format documentation it is Parquet shards for the tabular signals, MP4 shards per camera, and a metadata layer (meta/info.json, meta/stats.json, meta/tasks.jsonl, meta/episodes/) that reconstructs episode boundaries from byte offsets rather than filenames. The community post warns that deleting episode files without updating metadata breaks sequential consistency. When that happens the dataset does not load, and its episode count is worth exactly nothing.

A due diligence pass you can run in twenty minutes

1. 1
   Read the metadata before the media

   meta/info.json answers episodes, frames, fps, robot type, format version and camera layout. If it 404s, as for 2 percent of our sample, stop here.

   bash

   REPO=youliangtan/so101-table-cleanup
   curl -sL "https://huggingface.co/datasets/$REPO/resolve/main/meta/info.json" | python3 -m json.tool | head -20

2. 2
   Convert episodes into seconds

   total_frames divided by fps is the only honest measure of how much robot motion you are buying. Compare it against the 18.7 second median before accepting a per-episode price.

   bash

   curl -sL "https://huggingface.co/datasets/$REPO/resolve/main/meta/info.json" \
    | python3 -c "import json,sys;d=json.load(sys.stdin);print(round(d['total_frames']/d['fps']/60,1),'minutes over',d['total_episodes'],'episodes')"

3. 3
   Read the task strings

   Placeholders like 'task desc', 'Hold' or 'Up' are the strongest single signal that nobody reviewed this data.

   bash

   curl -sL "https://huggingface.co/datasets/$REPO/resolve/main/meta/tasks.jsonl" | head -20

4. 4
   Watch ten random episodes, not the first ten

   The opening episodes are always the operator's best work. Sample the middle and the end, looking for scene changes, lighting changes and object variety. That is what the power law pays for.

5. 5
   Check the format against your target model

   v2.0 or v2.1 for GR00T. v3.0 for Pi0.5, SmolVLA and ACT. Conversion is a documented script, but price in the hour.

   bash

   # migrate a v2.1 dataset up to v3.0, per the LeRobot v3 docs
   python -m lerobot.scripts.convert_dataset_v21_to_v30 --repo-id=<HF_USER/DATASET_ID>

6. 6
   Buy the cheapest answer first

   Train ACT before anything expensive. ACT is roughly 80 M parameters, runs on a 24 GB card and costs about 1 to 3 USD per run here. If ACT cannot fit the dataset, no 3 B parameter VLA will rescue it. The same job runs from a terminal through the CLI.

   bash

   # stream the candidate from the Hub instead of downloading it first
   # (flags per the LeRobot v3.0 dataset docs)
   lerobot-train --dataset.repo_id=<HF_USER/DATASET_ID> --dataset.streaming=true

Putting a number on it

There is no public price index for robot demonstration data, and anyone quoting one is quoting a survey rather than a market. What exists is a cost stack you can compute yourself. The honest way to price a dataset is to work out what an equivalent recording would cost you, then discount for the coverage you would not have arranged.

Compare the bottom rows with the top ones. Compute is 1 to 12 USD. Human attention is hours. That ratio is the whole argument: the cost of a training run has fallen far enough that it is no longer worth optimising, and the dataset is. A bad dataset does not cost you 4 USD, it costs you the day you spend proving it was bad.

Where this gets you nothing

Three honest limits, because a pricing article that only lists upsides is a brochure.

• There is no marketplace here. The directory lists public datasets. No auction, no escrow, no ratings, no price discovery, no payment rail. This platform hosts and trains on demonstration data, it does not clear transactions for it.
• No automated quality score exists, here or anywhere. The curation research (DemInf, SCIZOR) scores demonstrations, or individual state-action pairs, inside a dataset you already hold. Nobody has a credible cross-dataset metric to put in a listing.
• Evaluating over the public internet will misprice a dataset. The control loop is 20 ms per action step for ACT and 485 ms for Pi0.5. Add internet round trips and a good policy looks hesitant. Remote inference suits slow pick and place and misleads on anything reactive. Read inference latency before blaming the data.
• Our measurement is a snapshot. 72,393 datasets on 23 August 2026, sample size 700. The Hub grows daily and the distribution will drift. The method is printed above so you can rerun it rather than cite us.

If you are on the selling side

The shape of that corpus is an opportunity. The median public dataset is ten episodes shot once in one room, while demand concentrates on a handful of well documented corpora. Almost nothing separates the two ends except work that costs discipline rather than money.

• Vary the scene. Thirty two setups beats three thousand episodes, and the scaling law paper put a number on it.
• Write real task strings: 25 to 50 characters, an actual verb, an actual object. The cheapest value you will ever add.
• Mount a wrist camera. Half the corpus does not, and it is the view that decides whether the end effector closes on the right thing.
• Keep your failures and label why they failed, the way RoboMIND did with 5,000 of them.
• Record at 30 fps unless you have a reason not to. Mixed frame rates make a merged corpus unusable.
• Ship a real dataset card and a licence you actually chose. See SO-100 data collection and the desktop client that writes the format for you.

If you would rather be paid for the recording than for the artefact, that is a different market with different economics. RoboTurk showed the shape of it in 2018: 137.5 hours of manipulation data and over 2,200 successful demonstrations gathered in 22 hours of wall clock system time, because remote operators work in parallel. Operator work runs the same way here, in the browser, against real hardware.

Questions buyers actually ask

Related reading

For the recording side, see how to collect high quality VLA training data. For what a large public corpus is made of, see the DROID breakdown and Open X-Embodiment. To pick a model for your data, ACT against SmolVLA is the cheapest comparison, and the dataset documentation covers the formats this platform accepts.