Nvidia releases Flora for robot video labels and rewards

Illustration, not documentary evidence of the event.
Nvidia has released Flora, an open system that divides robot videos into actions, describes those actions and scores execution and outcomes, according to the-decoder.com. Nvidia says it already uses Flora in training its GR00T models. For robotics teams, the useful question is which labeling jobs Flora can take on, given that its reported strengths differ across tasks.
The reported cost advantage is substantial but projected. Nvidia estimates $0.72 per video hour for Flora versus $88.49 for GPT-6 Astra, using an assumed GPU rental rate of $10 per hour for Flora. These are not production cost measurements. The quality results also resist a single winner: Flora performs well at locating action boundaries and detecting failed steps, while Astra leads on WGO-Bench overall, robot videos in DenseCaptionBench and rubric-based scoring. The researchers acknowledge that Astra also evaluates descriptions while appearing among the models being evaluated, which complicates interpretation.
For a team choosing an annotation pipeline, those results suggest separating action segmentation from description and judgment. Flora is a stronger candidate when the immediate task is finding short actions or identifying possible failures for review. A workflow that depends on precise descriptions or ranking whole trajectories should not assume the same advantage. The report gives a concrete reason: Flora sometimes divides longer actions too finely and, in one example, labels a robot wiping a plate as folding a napkin. A correctly located action can still receive an incorrect description.
The failure-detection tradeoff also changes how teams should use its output. Flora reportedly catches 53.3 percent of failed steps but falsely flags about 11 percent of normal steps. Consider an explicitly hypothetical batch containing 100 failed steps and 1,000 normal steps. Applying those reported rates gives approximately 53 correctly flagged failures, calculated as 100 × 0.533, and 110 false alarms, calculated as 1,000 × 0.11. Only about 33 percent of the resulting flags would identify actual failures: 53.3 ÷ (53.3 + 110). This is an illustration of how the proportion of failures affects review workload, not an observed result or deployment forecast.
That calculation supports a concrete operating choice: use failure flags to prioritize human review before treating them as automatic rejection decisions. Teams should count failed and normal steps in a representative labeled sample, then calculate how many valid detections and false alarms the reported rates would imply for their workload. Where failures are uncommon, reviewing false alarms could become a material part of the annotation job. Flora's projected compute price alone cannot establish the cost of producing labels a team is willing to use.