Cost guide
What Teleoperation Data Collection Actually Costs
A production-grade teleoperation manipulation dataset frequently runs $50,000 to $200,000, but that headline hides the real structure. Skilled operators cost only $25 to $50 per hour and a practiced operator produces 30 to 60 usable demonstrations per hour, so 500 demonstrations of raw operator labor is roughly $600 to $700 — cheap. Cost is driven instead by hardware amortization (a rig runs $6,000 to $10,000 open-source or $60,000 to $80,000 with a UR5e and a commercial teleoperation stack), the operator learning ramp (4 to 8 hours before demonstrations are usable, 20 to 40 before they are consistently good), quality filtering that discards 20 to 30 percent of episodes, and engineering time for capture, QA, and formatting. At the 500-demonstration scale a DIY open-source build and a managed collection service converge near $8,000 to $15,000; the real difference is calendar time and whether the collection repeats.
The short answer: the $/hour quote is the wrong unit
Ask three vendors what teleoperation data costs and you will get three per-hour numbers, and none of them will let you compare the offers. Per-hour pricing describes the operator, and the operator is the cheap part. According to a line-item breakdown of robot manipulation data collection costs, skilled teleoperation operators run $25 to $50 an hour and a practiced operator on a familiar task produces 30 to 60 usable demonstrations per hour. Do the arithmetic at $40 an hour and 40 demonstrations an hour and 500 demonstrations of raw operator labor lands around $600 to $700. That is not where budgets die.
Budgets die in the line items nobody quotes: the rig you amortize over the project, the hours an operator burns before their demonstrations are usable at all, the fifth of every batch that quality filtering throws away, and the senior engineer whose time you spend on capture design and QA instead of on the policy. The same source puts a production-grade, environment-matched teleoperation dataset at $50,000 to $200,000 once those are counted. The gap between $700 of operator time and a $50,000 dataset is the entire subject of this guide. If you price teleoperation data as an hourly rate, you will underbid the build and mis-read every vendor quote you receive.
The teleoperation cost stack, line by line
Model the cost as a stack, not a rate. There are four layers, and only one of them scales with hours of footage. The hardware layer is a capital cost you spread across the whole collection: the same cost breakdown prices a bare-minimum open-source rig (an OpenArm-class arm, leader/follower teleoperation, two cameras, a GPU workstation) at $6,000 to $10,000 assembled, and a UR5e paired with a commercial teleoperation stack at $60,000 to $80,000. The arm alone spans $2,000 to $50,000 depending on platform. The operator layer is the per-demonstration labor already described. The supervision layer is a senior engineer running capture design and quality review at $60 to $100 an hour. The processing layer covers segmentation, synchronization checks, storage, cloud egress, and language annotation for VLA fine-tuning — small per episode, but real once you multiply by thousands.
The reason this matters is that the layers respond to scale differently. Double the dataset and operator labor roughly doubles, but the rig cost stays flat and the per-project engineering setup barely moves. Halve the dataset and you still pay for the rig, the operator ramp, and the QA tooling. That is why a $/hour rate over- or under-states the true cost depending entirely on how big the order is — the fixed layers dominate small orders and disappear into small change on large ones.
| Layer | What it covers | Typical range (cited) | How it scales with dataset size |
|---|---|---|---|
| Hardware (capital) | Robot arm, leader/follower or VR teleop interface, cameras, GPU workstation, mounts | $6,000-$10,000 open-source rig; $60,000-$80,000 UR5e + commercial teleop | Fixed — amortized across the whole collection, dominates small orders |
| Operator labor | Human performing demonstrations via teleoperation | $25-$50/hr at 30-60 usable demos/hr | Roughly linear in demonstrations, minus discard |
| Supervision & QA | Senior engineer on capture design and quality review | $60-$100/hr | Semi-fixed setup plus a per-batch review tax |
| Processing & delivery | Segmentation, sync checks, storage, egress, language annotation | Cents to ~$1 per episode | Linear but small; grows with modality count and format work |
Yield and ramp: where the money actually goes
Two numbers move a teleoperation budget more than the hourly rate: yield and ramp. Yield is the fraction of collected episodes that survive quality filtering. The cost breakdown assumes 20 to 30 percent of episodes get discarded — jerky motions, incomplete grasps, inconsistent speeds — which means you pay operator time for demonstrations that never reach training. At $40 an hour and 40 demonstrations an hour, 500 usable demonstrations is not $500 of labor; after discard and overhead it is closer to $600 to $700, and once you add senior-engineer supervision at $60 to $100 an hour the pure labor for 500 demonstrations reaches roughly $800 to $1,200.
Ramp is the second silent cost. Per the same operator-cost analysis, a new operator needs 4 to 8 hours of training before their demonstrations are usable at all, and 20 to 40 hours before they consistently produce smooth, variation-rich episodes. That ramp is a sunk cost that only pays back over a long engagement. A one-week collection with a fresh operator spends a large share of its hours climbing the learning curve; a standing team amortizes that curve across months. This is the real reason short, one-off teleoperation collections feel disproportionately expensive per usable demonstration — you buy the ramp every time you start cold.
- Yield is a multiplier on every labor dollar: a 25% discard rate means you collect ~667 episodes to keep 500.
- Unskilled demonstrations are not free — they consume operator time and QA review before being thrown away.
- The operator ramp (20-40 hrs to consistent quality) rewards continuity and punishes stop-start collection.
- Supervision and QA at $60-100/hr is often the second-largest labor line after the operators themselves.
Demand is a lever: how many demonstrations do you actually need?
Most teleoperation cost estimates treat demonstration count as a fixed input. It is a design choice, and it is the highest-leverage one you have, because cost scales with demonstrations while capability does not scale linearly with them. On the low end, the ALOHA system — a $20,000 open-source bimanual teleoperation rig — trains ACT policies that hit 80 to 90 percent success on fine-manipulation tasks from roughly 50 demonstrations per task, about 10 minutes of demonstration data. Mobile ALOHA reports that with 50 demonstrations per task, co-training on existing static ALOHA data can raise mobile-manipulation success rates by up to 90 percent.
The engineering takeaway is that "how much data" is downstream of policy architecture, task difficulty, and whether you can co-train on existing corpora — not a number to be maximized. If 50 demonstrations per task clears your success bar with the right method, the entire cost conversation changes scale: you are budgeting hundreds of demonstrations, not tens of thousands, and the fixed hardware and ramp costs dominate. Before you price a large collection, pressure-test the demand side. Cutting a 5,000-demonstration ask to 500 through better co-training or a more sample-efficient policy saves more than any per-hour negotiation ever will.
Why frontier teleoperation data is pooled, not collected solo
Look at what large-scale teleoperation data actually took to build and the case for sourcing over solo collection gets concrete. The DROID dataset is 76,000 demonstration trajectories — 350 hours of interaction across 564 scenes and 86 tasks — and it took 50 data collectors at 13 institutions across North America, Asia, and Europe twelve months to assemble, on a standardized hardware setup. That is a coordinated, multi-lab, year-long program, not a sprint one team runs on the side.
Open X-Embodiment went further by not collecting from scratch at all: it was constructed by pooling 60 existing robot datasets from 34 labs, spanning 22 robot embodiments and more than a million real robot trajectories across 527 skills. The structural lesson for a buyer is that breadth — across scenes, embodiments, operators, and geographies — is produced by aggregation, because no single team is staffed to collect it. If your bottleneck is diversity rather than a narrow proprietary task, the economical path is to source what already exists and spend your own rig time only on the demonstrations that are specific to your robot.
Build vs buy at 500 demonstrations, and how to compare a quote
At small scale the build-versus-buy math is closer than teams expect. The same cost breakdown models a representative 500-demonstration single-task project with two cameras and a 6-DOF arm two ways: a DIY build on open-source hardware costs about $8,000 in capital plus $7,500 to $14,500 in engineering and operator time, while a managed collection service delivers the same order in the $8,000 to $15,000 range within one to two weeks. The prices overlap. What does not overlap is calendar time and repeatability — DIY spends weeks standing up a rig and a workflow you will keep, buying trades that for speed and someone else absorbing the ramp and yield risk. The tie-breaker is whether the collection recurs: a standing weekly need amortizes an internal pipeline, a bounded one-off usually does not.
Whichever way you lean, a vendor quote is only comparable if you force the hidden variables into the open. A per-hour or per-demonstration price means nothing until you pin the operator throughput and skill tier behind it, the yield after quality filtering, whether hardware and QA are inside the number or billed separately, and whether delivery arrives in your target schema or a "similar" export you will have to reprocess. Truelabel sits on the buy side of this decision: a physical AI data marketplace where you post a teleoperation or robot-demonstration spec and matched partners return sample packets with QA evidence before scale, sourced from around 10,000 collectors across 100 countries and 100+ vetted capture partners, delivered rights-cleared with per-trajectory provenance in RLDS, LeRobot, or MCAP so the cost you compare is the cost you actually pay.
- 01
Throughput and yield
Usable demonstrations per hour and the discard rate after quality filtering. A rate without these two numbers is not a price.
- 02
Operator tier and ramp
Are demonstrations from trained operators past the 20-40 hour ramp, or from fresh hires still climbing the curve? Skill shows up as quality and variation.
- 03
What the number includes
Is rig hardware amortized in, or billed as capital? Is senior-engineer QA inside the rate or a separate line? Hidden layers are where quotes diverge.
- 04
Delivery format
RLDS, LeRobot, MCAP, or your internal schema — delivered clean, not a 'similar' export you reprocess. Format mismatch is silent rework.
- 05
Rights and provenance
Consent artifacts and per-trajectory metadata that survive partner and legal review, produced once and shipped with the data rather than reconstructed later.
Related pages
Use these to move from category-level context into specific task, dataset, format, and comparison detail.
FAQ
How much does teleoperation data collection cost?
A production-grade, environment-matched teleoperation manipulation dataset frequently runs $50,000 to $200,000, but the operator labor inside that is small: skilled operators cost $25 to $50 per hour and produce 30 to 60 usable demonstrations per hour, so 500 demonstrations of raw operator time is roughly $600 to $700. The larger costs are rig hardware ($6,000-$10,000 open-source to $60,000-$80,000 commercial), the operator learning ramp, a 20-30 percent quality-filter discard rate, and senior-engineer QA at $60 to $100 per hour.
Why is a per-hour price a bad way to compare teleoperation vendors?
Because the hourly rate only describes the operator, which is the cheapest and most linear part of the cost. A $/hour number tells you nothing about throughput (usable demonstrations per hour), yield (how many episodes survive quality filtering), whether hardware and QA are inside the rate or billed separately, or whether delivery arrives in your target schema. Two vendors quoting the same per-hour figure can differ by several times in true cost once those variables are pinned.
What is the biggest hidden cost in collecting robot demonstrations?
The operator ramp and the discard rate. A new operator needs 4 to 8 hours of training before demonstrations are usable and 20 to 40 hours before they are consistently high quality, so short one-off collections pay for the learning curve every time they start cold. Separately, quality filtering discards 20 to 30 percent of episodes, meaning you pay operator and QA time for demonstrations that never reach training.
How many demonstrations do I need for imitation learning?
Fewer than most budgets assume, because demonstration count is a design choice tied to policy architecture and task difficulty, not a fixed input. ALOHA's ACT policies reach 80 to 90 percent success on fine-manipulation tasks from roughly 50 demonstrations per task, and Mobile ALOHA reports up to 90 percent gains from 50 demonstrations per task when co-training on existing static data. Pressure-testing the demand side — a more sample-efficient method or co-training on an existing corpus — cuts cost faster than any per-hour negotiation.
Is it cheaper to build a teleoperation pipeline or buy the data?
At small scale they converge. A representative 500-demonstration single-task project costs about $8,000 in capital plus $7,500 to $14,500 in time to build DIY on open-source hardware, while a managed collection service delivers the same order for roughly $8,000 to $15,000 in one to two weeks. The prices overlap, so the tie-breaker is calendar time and repeatability: a standing weekly need amortizes an internal pipeline, while a bounded one-off is usually cheaper and faster to buy.
Why is large-scale teleoperation data usually pooled across many labs?
Because breadth across scenes, embodiments, operators, and geographies is produced by aggregation, not by any single team. The DROID dataset's 76,000 trajectories took 50 collectors at 13 institutions twelve months to gather, and Open X-Embodiment was built by pooling 60 existing datasets from 34 labs into over a million trajectories. If your bottleneck is diversity rather than one proprietary task, sourcing existing data and reserving your own rig for robot-specific demonstrations is the economical path.
Looking for teleoperation data collection cost?
Specify modality, task, environment, rights, and delivery format. Truelabel matches you with vetted capture partners and helps scope consent artifacts and commercial licensing requirements before delivery.
Post a teleoperation data spec