Task success
Did the robot finish the task within its time budget? Report successful trials, valid trials, exclusions, and uncertainty together.
SR = successes / valid trialsPrimary outcome · per task & protocolRobotics Center / XEbench
Compare policies on the hardware they control. Measure task success and throughput against human teleoperation on the same embodiment.
01 / Policy performance
Compare policy performance within the same task and protocol. Pick-and-place scores belong to the complete arm + hand embodiment.
Example values for the leaderboard; these are not measured robot runs.
| Rank | Policy / version | Embodiment · arm + hand | Success rate | 95% CI | Human-relative rate | Successes / trials | Run duration | Source |
|---|---|---|---|---|---|---|---|---|
| Loading public results… | ||||||||
Only submitted measurements appear here.
Ordered by success rate within the selected task and protocol; ties share a rank. Each pick-and-place entry is an arm + hand system. HRT compares successful completions per minute against human teleoperation on that same system. Read uncertainty and training conditions before drawing conclusions.
The RC contribution
A single robot tells you how a policy performed there. A controlled fleet evaluation shows how much that performance changes with the body.
Read the publication rules ↗The spread in a policy’s success rate across eligible bodies, in percentage points. Read it with mean success and coverage: consistently low performance can also have a low σ.
Official RC summaries use reviewed cohorts; community submissions do not become RC-verified results automatically.
02 / Cross-embodiment table
Rows are arm + hand bodies, columns are policies. Click any cell for the scene → environment → task breakdown, reference video and failure types; click a body for its composition.
Scores are seeded demonstration values, not measured runs. Task reference videos are real footage. The table shows the format of an XE-Table release, not results.
Human demonstrations of each task. Hover or tap to play. These are not recordings of the scored runs.
| Body |
|---|
Loading the cross-embodiment table…
CITE XE-Table 2026.3 · FAMILY — · JUDGE rc-judge-v1 · n = runs · ILLUSTRATIVE
A cell with fewer than 40 runs prints insufficient (n=…) instead of a percentage; the σ row is one policy’s spread across bodies. Scoring, the n = 40 rule and the judge are documented on RC Instrument ↗.
03 / Measurement framework
Did the robot finish the task within its time budget? Report successful trials, valid trials, exclusions, and uncertainty together.
SR = successes / valid trialsPrimary outcome · per task & protocolSuccessful task completions per minute, relative to a human teleoperating the identical robot. Use the same task mix and timing rules.
HRT = 100 × policy rate / human rate100% = human rate · 50% = half the throughputHow much does success vary between bodies? Hold the task, scene distribution, checkpoint policy, and evaluation rules fixed.
σ = population SD of body success ratesRC cohort · report mean & coverage tooMeasure the policy and a human operator on the same embodiment, objects, task mix, fixtures, observation setup, and rules. For pick and place, the human teleoperates the same arm + hand system. Hand-only tasks use the same mounted hand and fixture.
For each run, throughput is successful task completions divided by total elapsed run time. Start timing at the first trial cue and stop when the last planned trial ends. Failed attempts, timeouts, recovery, and between-trial resets count toward elapsed time. Predeclare any excluded downtime and apply the same rules to both runs; do not time successful trials alone.
HRT (%) = 100 × (policy successes / policy elapsed time) / (human successes / human elapsed time)
100% matches the human’s completion rate; 50% is half; 200% is twice. This is a direct normalization to the human teleoperation baseline. Report success rate alongside it so readers can distinguish reliability from speed. A reference with zero successful completions cannot define the ratio.
Record the operator, experience, trial counts, timing scope, and exact hardware. Repeat sessions to estimate uncertainty; a single aggregate run cannot establish a throughput confidence interval. Keep object weights fixed for multi-object comparisons. The current submission format does not include full-run elapsed time or a matched human reference, so HRT requires additional run records.
Each release must identify its task, protocol revision, scene set, scoring rules, time cap, and included bodies. Freeze the policy checkpoint and disclose every embodiment adapter. If a body requires different fine-tuning, label that as an adapted-policy comparison; it is not a zero-shot transfer result.
The proposed publication floor is 40 valid trials per body × policy × task cell, collected through repeated complete protocol rounds. Publish all exclusions and their reasons. This is an eligibility floor, not a claim that 40 trials establishes statistical significance. Single 20- or 30-trial runs can appear in community results.
Cross-body summaries require at least three eligible bodies and use the intersection of eligible bodies across all policy columns in the selected controller group, so the displayed summaries share the same coverage. Report population standard deviation, mean success, the included body count, and the exact release manifest. HRT additionally requires complete-run timing and a matched human teleoperation reference for every included cell.
Only a reviewed RC release supplies the official matrix. Anyone can reproduce the calculations from its published records; submitting a run does not confer RC verification.
A dash means unmeasured or unavailable, never zero. N/A means the task requires an ability absent from that proposed configuration, such as three independently assigned fingers. An insufficient cell has too few valid trials for an RC summary.
Success-rate intervals use the 95% Wilson interval for independent binary trials. Correlated trials require episode-aware analysis before RC publication. Hardware-invalid trials must be justified and counted separately; policy errors, unsuccessful attempts, and timeouts remain in the denominator. Community completion times cover only trials with a reported time and are not a throughput score or ranking tie-breaker.
04 / Policy & controller families
OpenPI implementations. Record the exact checkpoint, fine-tuning data, and action adapter.
Vision-language-action ACT ↗Action Chunking TransformerA task-trained imitation baseline. Document demonstrations, training budget, and action space.
Imitation learning GR00T ↗NVIDIA IsaacN1.6 is the proposed reference version. Pin the model revision and embodiment configuration.
Robot foundation modelEvaluate the complete observation → model → robot-action loop. Record the model revision, prompt, action adapter, and control frequency for each run.
XEbench includes an arrow-key controller that requests one bounded finger action at a time. Other tasks require a task-specific controller.
LLM controller · gpt-6-astra Gemini ↗Google DeepMindA controller family for model-driven task decisions. Submit the exact Gemini model ID and the adapter that turns its responses into robot actions.
LLM controller · revision per run Claude ↗AnthropicA controller family for model-driven task decisions. Submit the exact Claude model ID, observation format, prompt, and robot action adapter.
LLM controller · revision per runThese are evaluation candidates; published scores require recorded runs on the specified embodiment. For controller integration, see the XEbench LLM controller and custom policy interface.
Three fixed tasks
Hand + fixture · 20 trials
Press LEFT, DOWN, then RIGHT with three assigned fingers.
keypress-ldrSetup guide ↗
Hand + fixture · 20 trials
Play MIDI notes 60, 62, then 64 with even, medium force.
piano-seqSetup guide ↗
Arm + hand · 30 trials
Evaluate the complete arm + hand system. Move a ball, cube, or marker from zone A into the tray: 10 trials per object.
pick-place-abSetup guide ↗Contribute a run
Upload the results.json written by XEbench and link recordings covering the complete run, including failures. Use DexData, Hugging Face, a public video playlist, or your own HTTPS host. MCAP is useful for synchronized telemetry but is not mandatory.
Standard runs use protocol version 0.1.0 and the full trial count shown above. Custom tasks must include a public task specification link and a complete fixed trial count.
The evidence lets readers inspect the task, timing, interventions, and outcomes. A highlight reel cannot establish a run’s success rate. Publication as a community result does not imply RC verification.
Full submission format ↗