Cell F14 of the spreadsheet a VLA startup sent us in January read cost_per_usable_hr = $71. Two rows down sat the scaling plan: 12,000 usable hours by July, up from the 500 they had collected on an internal ALOHA-class cell before their policy plateaued. At $71 per usable hour, the plan cost $852,000. The approved budget in the adjacent column was $560,000. The engagement began, literally, as a request to make F14 say something else.
The gap behind that cell was not caused by anything exotic. Their single rig sat idle 60 percent of the day. Their rejection rate was 31 percent because task specs lived in a Slack thread. And every hour they collected was premium bimanual teleop, even the hours that existed only to teach the visual encoder what countertops look like.
This is the most common shape of scaling problem we see, and it carries the thesis this case study argues: data budgets are rescued by operational variables, rejection rate, modality mix, and rig utilization, not by rate negotiation. Names and identifying details are removed at the client’s request; every number is from the actual program ledger.
What follows: the starting cost baseline, the three changes that moved it, the month-by-month rejection curve, and the final economics. If you are scaling any demonstration data program past a few thousand hours, at least one of these three changes applies to you.
Key Takeaways
- Starting point: $71 per usable hour, 31% QA rejection, one under-utilized rig. Ending point: $46 per usable hour, 11% rejection, 12,100 usable hours delivered.
- Fix 1: a written, versioned task spec cut rejection from 31% to 14% in five weeks. Cost: about a week of engineering time.
- Fix 2: a 65/35 modality split (egocentric pretraining at $22/hr blended, teleop post-training at $44/hr blended) cut the blended rate by 29%.
- Fix 3: two-shift rig utilization dropped amortization per hour from $11 to $5.
- Total spend: $557,000 against a $560,000 budget. The policy’s task success rate improved 19 points on their internal eval.
The Baseline: Why $71 per Usable Hour Happens
A cost baseline is the fully loaded spend per QA-passed hour at the start of an engagement, and it is almost always worse than the team believes because rejection losses hide inside it. The startup quoted their internal cost as “about $49 an hour.” That was spend divided by raw hours. Divided by usable hours, it was $71.
Their baseline decomposed like this:
| Line item | Their baseline | Notes |
|---|---|---|
| Rig amortization | $11/raw hr | One ~$26k cell, single shift, idle 60% of the day |
| Operator labor | $29/raw hr | Two part-time operators, still early on the learning curve |
| QA review | $9/raw hr | Manual review, no automated pre-checks |
| Raw total | $49/raw hr | The number they quoted internally |
| Rejection rate | 31% | Ambiguous specs, no calibration checklist |
| Usable total | $71/usable hr | $49 / (1 - 0.31) |
Nothing in that table is negligence. It is what a research-grade pipeline looks like when a training run suddenly demands production volume. The ALOHA hardware itself was fine; a roughly $20k bimanual rig is a proven design (https://arxiv.org/abs/2304.13705). The economics around the hardware were the problem.
Fix 1: A Versioned Task Spec Cut Rejection by More Than Half
A task specification is a written, versioned document defining episode start states, success criteria, camera framing requirements, and reset procedures, and it is the highest-ROI artifact in any capture program. Theirs was a Slack thread and tribal memory. Operators guessed, and QA rejected the guesses.
We replaced it with a two-page spec per task family: exact object sets, start-state photos, an explicit success predicate, and a pre-episode calibration checklist. Rejections got tagged with a reason code so the spec could be patched weekly.
The rejection curve over the program:
| Month | Rejection rate | Main rejection driver |
|---|---|---|
| Jan (baseline) | 31% | Ambiguous success criteria |
| Feb | 22% | Camera framing drift |
| Mar | 14% | Occluded end-effector |
| Apr | 12% | Long-horizon task failures |
| May to Jul | 11% | Steady state |
Total cost of the fix: roughly one engineer-week plus 30 minutes of weekly maintenance. Effect: every subsequent dollar bought 29 percent more usable data. No other intervention in this program came close on ROI.
Fix 2: Stop Buying Premium Hours for Non-Premium Jobs
Modality staging is the practice of assigning cheap capture modalities to pretraining objectives and reserving teleoperation for action-supervised post-training. The startup was training their visual encoder on $49-per-hour bimanual teleop footage. The encoder did not care that the footage had action labels; it needed diverse pixels of hands, objects, and scenes.
We restructured the volume: 65 percent egocentric human video for representation pretraining, collected across 40+ real kitchens and workspaces at a blended $22 per hour, and 35 percent bimanual teleop for post-training at a blended $44 per hour. This mirrors what the public record already suggested: cross-source mixtures train stronger generalists, which is the entire premise of Open X-Embodiment’s 1M+ trajectories across 22 embodiments (https://arxiv.org/abs/2310.08864) and DROID’s 76k episodes across 52 buildings (https://arxiv.org/abs/2403.12945).
Blended raw rate after the split: $29.70 per hour, a 29 percent reduction against their all-teleop plan. Their ML lead’s initial worry, that ego data would not move policy metrics, resolved in evaluation: the encoder pretrained on the ego corpus reached the same downstream success with 22 percent fewer teleop post-training hours. The cheap data made the expensive data go further.
Fix 3: Utilization Is a Pricing Decision
Rig utilization is the fraction of available hours a capture station spends collecting, and it directly divides your amortization cost per hour. One cell on one shift with 60 percent idle time was charging them $11 per hour just for hardware.
Changes: we added a second shift on their existing cell, stood up two DexSet production cells in parallel, and scheduled resets and calibration into shift handovers instead of collection time. Amortization dropped to $5 per hour. Operator throughput also compounded, as it always does; our operators improve 30 to 50 percent over their first 200 hours, and by April the program’s episodes-per-shift was up 41 percent against baseline.
The Final Ledger
Program economics are only credible as a closed ledger, so here is the whole thing:
| Item | Plan (their original) | Actual (restructured) |
|---|---|---|
| Usable hours target | 12,000 | 12,100 delivered |
| Blended raw rate | $49/hr (all teleop) | $29.70/hr (65/35 mix) |
| Rejection rate | 31% | 11% steady state |
| Cost per usable hour | $71 | $46 |
| Language annotation | not budgeted | $10/usable hr on teleop subset ($42,400) |
| Total spend | $852,000 projected | $557,000 actual |
Against their internal eval suite, task success improved 19 points over the plateaued January checkpoint. We do not claim the data mix deserves all of that credit; their team shipped model improvements in the same window. We do claim the counterfactual: at $71 per usable hour, the volume that enabled those experiments would not have fit the budget.
Every formula behind this ledger, including the cost-per-usable-hour tables and the rig amortization model, is published in our robot training data costs and pricing guide.
What Transfers to Your Program
A transferable lesson is one that holds regardless of embodiment or task list, and this program had three. Write the task spec before you scale, because rejection rate is the multiplier on everything. Split modalities by training objective, because encoders do not need action labels. And treat utilization as pricing, because an idle rig is a fee you pay for nothing. None of these require our involvement to implement. They do require someone to own cost per usable hour as a weekly metric.
Apply This Playbook to Your Program
Ready to scope your data program? Talk to our team.
Frequently Asked Questions
How many usable hours does a VLA program actually need?
It varies by task breadth and model scale, but the programs we run for post-training typically land between 5,000 and 30,000 usable teleop hours, on top of larger and cheaper pretraining corpora. Budget from your eval targets backward, not from a round number.
What rejection rate should I consider healthy?
With a versioned task spec and calibration checklists, 10 to 15 percent is a realistic steady state in our pipelines. Above 25 percent, fix your spec before you buy another hour.
Does egocentric pretraining data really reduce teleop needs?
In this program, encoder pretraining on egocentric video reached equal downstream success with 22 percent fewer teleop post-training hours. Results vary with task overlap, but the direction is consistent across our engagements.
What did the client’s cost per usable hour end up at?
$46, down from a $71 baseline: a 35 percent reduction from spec discipline, modality staging, and rig utilization combined, with no reduction in QA standards.
Can I replicate this with an in-house team?
The task spec and utilization fixes, yes, immediately. The modality split needs access to egocentric collection at scale, which is harder to stand up internally; that is typically where teams engage a provider.
Planning your own scale-up?
The Robot Training Data Costs and Pricing Guide contains every benchmark and formula used in this program. Or book a scoping call and we will baseline your current cost per usable hour in one session.
