Shreshth Rajan, June 2026. · Code: roboticstt
I wanted to know whether sampling more robot actions and keeping the best one actually helps.
A robot policy picks its moves by sampling, so you can sample six and keep the best. Whether that works depends on two numbers: how much better the best of six is than the first of six, and whether anything can tell them apart.
Nobody measures the first number, because measuring it means knowing which option would have worked. In simulation you can know. Save the state, run one option, let the policy finish the episode, see whether it succeeded, and repeat for all six. That's a perfect scorer, and it gives you the ceiling.
I ran it on SmolVLA-450M on LIBERO-Object. The policy already succeeds 87% of the time, so there's nothing to fix. I made it commit more moves between replans and it fell to 23%.
Best of six, scored perfectly, succeeds 51% of the time; one sample succeeds 23%. That is a 28-point gap.
The gap shrinks as the policy gets worse. Blur the camera a little and it falls to 23 points; blur it a lot and it's 16. Selection needs a policy that fails most of the time but still succeeds sometimes, and that window is narrow.
Then I trained a real scorer: a frozen DINOv2 image encoder, separate from the policy's own vision, with a small transformer reading the six option sequences, trained on which ones worked.
# v[i] is whether option i ACTUALLY worked, from the simulator; all four see the same six options
perfect = v.max() # the ceiling
one_shot = v[0] # the policy acting once
averaging = v[argmin(dist_to_mean(options))] # keep the option closest to the average
scorer = v[verifier(image, options).argmax()] # keep the option the trained scorer likes
It never beat averaging in any condition — averaging just keeps the option closest to the mean of the six, and it was the only method that beat a random pick at all.
The scorer isn't weak: show it an episode and it ranks a failure above a success 88% of the time. But ranking episodes is the wrong question. Whether the robot succeeds right now is mostly about the situation it's in, not about which of six near-identical options it takes, and all six face the same situation, so a scorer reading the camera hands them all nearly the same number.
Ranking them would mean knowing which option beats the average, and I don't think that's learnable here. The six are independent samples from one distribution. Nothing you can see about an option predicts whether it works. Fast-WAM found the same thing from the other direction: world models buy almost nothing at test time.
One result is worth keeping. A model that spots failures 88% of the time is a cheap failure detector, and it belongs on stopping the robot rather than on choosing its moves.
A better world model won't change this. The bottleneck isn't telling the six options apart, it's that they're nearly identical to begin with. The experiment that would change my mind is widening them, with higher sampling temperature or separate sub-policies, which I haven't run.
Setup. Frozen SmolVLA-450M on LIBERO-Object, six options per decision, each run to the end of the episode for its real outcome. Moves committed per replan set the difficulty; a per-episode brightness shift sweeps competence. Scorer: frozen DINOv2 plus a two-layer transformer over the option, held out by whole decisions, reported as AUROC and out-of-fold selection with paired bootstrap intervals. One policy, one task suite, simulation, and fifteen informative decisions in the heavy-blur cell, so this is a ceiling rather than a survey. Formally each outcome splits as \(v(s,a_i) = V(s) + \delta_i\), where \(V(s)\) is the average success rate at that state and \(\delta_i\) is the option's edge over it; the scorer recovers \(V(s)\) and ranks at chance on \(\delta_i\). The 0.88 isn't an artifact of the blurred condition: an earlier run gave 0.54 because it labelled options by distance to the expert move instead of by outcome, and switching only the label brings the signal back. Code and outcome banks, reproducible on CPU: github.com/ShreshthRajan/roboticstt.