What Robot Data Collection Costs

"How much does a demonstration cost?" is usually the wrong question, because it invites an answer denominated in raw episodes recorded rather than episodes a training pipeline can actually use. Every number in this guide is explicitly illustrative — a structure to plug your own figures into, not a quote. For an actual number, see pricing.

The real cost drivers, in order

For most teleoperated data collection programs, cost breaks down in roughly this order of magnitude:

1. Operator hours — the loaded cost of the people running the robot, by far the largest line item in most programs.
2. Rig capital and amortization — the robot, sensors, and workstation, spread across their useful collection life.
3. Storage and egress — where the recordings live and what it costs to move them.
4. QA labor — the human or automated review that separates usable episodes from ones to discard.

This ordering is a pattern, not a law — a program using an expensive specialized rig at low utilization can flip the first two, and a program with heavy manual annotation can push QA labor above storage. Build your own model rather than assuming the ordering above matches your task.

Operator hours dominate the line item

Teleoperation is skilled, sustained work, and its cost scales with hours, not with episodes directly — episodes per operator-hour is the conversion factor, and it varies enormously by task complexity, interface quality, and operator experience. A contact-rich bimanual insertion task and a free-space pick-and-place task can differ by an order of magnitude in episodes produced per hour on the same rig, which means operator cost per episode differs by the same order of magnitude even at an identical hourly rate.

This is also the line item most sensitive to interface and workflow quality. Latency, awkward reset procedures between episodes, and unclear task instructions all reduce episodes-per-hour without showing up anywhere except a slower burn rate — see teleoperation for why round-trip delay specifically degrades operator throughput on contact-rich work.

Rig capital, amortized correctly

A rig's sticker price is not its cost per episode — its amortized cost is. Divide the capital outlay across either a fixed depreciation schedule or, more usefully for a collection program, the number of episodes the rig is expected to produce over its useful collection life before it's retired, upgraded, or reassigned. A rig used at low utilization amortizes slowly and pushes rig cost per episode up; the same rig at high utilization amortizes fast and rig cost per episode shrinks toward negligible. This is the main reason utilization, not hardware cost alone, determines whether owning rigs is cheaper than accessing them another way — a question this guide comes back to below.

Storage, egress, and QA labor add up quietly

Neither storage nor QA labor is usually the largest line item, but both are easy to underestimate because they scale with volume in ways that are less visible than an operator's timesheet.

Storage and egress costs scale with episode count and modality — multi-camera RGB and depth streams dominate file size, proprioception and force-torque are comparatively tiny — and egress specifically matters if training happens somewhere other than where data is stored. QA labor scales with however much of the review process is manual: automated checks (dropped-frame detection, gripper-state sanity checks) cost compute; anything requiring a human to watch footage costs a reviewer's hourly rate per episode reviewed, and that number belongs in the model just as concretely as operator collection time.

Cost per usable episode, not cost per episode

This is the pivot the whole model depends on. An episode that fails QA — a dropped sensor stream, an incomplete task, a mislabeled outcome — consumed the same operator time and rig time as one that passes, and contributes zero training value. Optimizing for raw episodes-per-hour without tracking yield can make a protocol look cheap while actually being expensive per unit of usable data.

The formula:

cost_per_usable_episode =
    (operator_cost + rig_amortization + storage_and_egress + qa_labor)
    / usable_episodes
 
usable_episodes = raw_episodes × yield_rate

Yield rate — the fraction of recorded episodes that pass QA and are usable for training — is the multiplier that makes or breaks this number, and it's worth tracking as a first-class metric alongside throughput. See dataset quality assurance for what actually drives yield up or down in practice.

A worked illustrative model

The figures below are illustrative — a plausible shape for a mid-complexity manipulation task, not a benchmark or a quote.

Operator hours (illustrative)

3 operators × 20 hrs/week at a $45/hr loaded rate ≈ $2,700/week

Throughput (illustrative)

~12 episodes per operator-hour → 720 raw episodes/week

Rig amortization (illustrative)

$12k capital over 24 months ≈ $115/week

Storage & egress (illustrative)

~150MB/episode at illustrative blended rates ≈ $5/week

QA labor (illustrative)

~$0.75/episode reviewed × 720 ≈ $540/week

Total illustrative weekly cost — roughly $3,360 — divided by 720 raw episodes gives roughly $4.67 per raw episode. At a 78% illustrative yield, usable episodes drop to about 562, and cost per usable episode rises to roughly $5.98 — nearly 30% higher than the raw-episode figure, entirely from discarded work. A protocol change that pushed yield from 78% to 90% without touching throughput or rate would cut cost per usable episode by more than the same effort spent trying to speed up operators. That's the argument for tracking yield as hard as you track hours.

Why the second 1,000 episodes cost less than the first 100

Two effects compound in the same direction as volume grows, both illustrative in shape rather than fixed in magnitude:

• Amortization spreads. Rig setup, initial calibration work, and operator onboarding are largely one-time costs. Divided across 100 episodes they're a significant per-unit add-on; divided across 10,000 they're close to zero.
• Yield improves with a refined protocol. Early episodes surface the ambiguous instructions, awkward reset steps, and edge cases that cause rejections. A protocol that's been iterated on — see data collection protocol — rejects less of what it produces, which raises usable-episode yield without touching the raw rate at all.

Neither effect is automatic. A task whose requirements keep changing never gets to amortize a stable protocol, and a program that doesn't review QA failures never learns what to fix. The scale effect is something you have to earn by holding the protocol still long enough to benefit from repetition, not something volume produces by itself.

Build vs. buy: the break-even question

Rig capital and ramp-up time are the two costs that an in-house program pays up front and a managed or outsourced provider absorbs for you, typically at a higher illustrated per-episode rate in exchange. Below some volume threshold, that trade favors buying: you never amortize the capital, and you skip the weeks or months it takes a new rig and operator team to reach steady-state yield. Above that threshold, in-house collection usually wins, because amortized rig cost per episode keeps falling with volume while a vendor's per-episode rate generally doesn't.

Where that threshold sits depends entirely on your own numbers — rig cost, expected episode volume, operator availability, and how quickly you can reach steady-state yield in-house. Build the cost-per-usable-episode model above for your own program, then compare it against a managed provider's published rates at your expected volume; see in-house vs. outsourced data collection for the fuller trade-off, and pricing for current illustrative plan structure rather than treating any number in this guide as one.