Robotics Center / XEbench

Real policies.
Measurable dexterity.

Compare policies on the hardware they control. Measure task success and throughput against human teleoperation on the same embodiment.

01 / Policy performance

Leaderboard

Compare policy performance within the same task and protocol. Pick-and-place scores belong to the complete arm + hand embodiment.

Submit your run ↗

Example values for the leaderboard; these are not measured robot runs.

RankPolicy / versionEmbodiment · arm + handSuccess rate95% CIHuman-relative rateSuccesses / trialsRun durationSource
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

One policy.
Across the hardware.

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 ↗
RC analysis · controlled cohorts

Cross-body dispersion σ

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 σ.

σbody = √ mean((SRbody − mean(SR))²)

Official RC summaries use reviewed cohorts; community submissions do not become RC-verified results automatically.

02 / Cross-embodiment table

Same policy, same task, different hands.

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.

Full methodology ↗
Illustrative data

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.

Task reference videos

Human demonstrations of each task. Hover or tap to play. These are not recordings of the scored runs.

Select a cell for scenes, tasks, intervals and failures
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

Success. Speed. Transfer.

Human teleoperation = 100%
  1. One policyA frozen checkpoint, with every embodiment adapter disclosed
  2. N bodiesComplete arm + hand systems, each scored as a whole
  3. Fixed protocolSame task, scenes, trial count, time cap and scoring rules
  4. Three numbersSuccess rate, human-relative throughput, cross-body σ
The XEbench protocol. A policy fine-tuned differently for each body is reported as an adapted-policy comparison, not zero-shot transfer.
SR ↑

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 & protocol
HRT ↑

Human-relative throughput

Successful 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 throughput
σ ↓

Cross-body consistency

How 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 too
How is throughput compared with human teleoperation?

Measure 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.

What qualifies for the RC-computed rows?

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.

How should I read uncertainty, failures, and missing values?

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

Built around reproducible baselines

LLM controllers

Evaluate the complete observation → model → robot-action loop. Record the model revision, prompt, action adapter, and control frequency for each run.

These 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

One protocol per task

XEbench on GitHub ↗
Dexterous hand pressing the arrow keys in the LEFT, DOWN, RIGHT sequence

Hand + fixture · 20 trials

Arrow-key sequence

Press LEFT, DOWN, then RIGHT with three assigned fingers.

keypress-ldrSetup guide ↗
Dexterous hand playing three notes on a MIDI keyboard

Hand + fixture · 20 trials

Piano sequence

Play MIDI notes 60, 62, then 64 with even, medium force.

piano-seqSetup guide ↗
Robot arm and dexterous hand mounted above the pick and place benchmark work surface

Arm + hand · 30 trials

Pick and place

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

Make your run inspectable.

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 ↗

A full protocol run and public recordings are required. When online publishing is unavailable, you can download a validated submission file.