Karim Elmaaroufi1,2, Sarunas Kalade3, Yansong Wu4, Justin Svegliato1,
Graham Schelle3, Negar Mehr1, Sanjit A. Seshia1, Matei Zaharia1

1 UC Berkeley  ·  2 Embodied Science  ·  3 AMD  ·  4 Technical University of Munich

RHO: Your Coding Agent is Secretly a Roboticist

RHO (Robotics Harness Optimization) unlocks tool-enabled LLM coding agents to unleash their inner roboticist. Through reflective evolutionary search, it writes and rewrites a robot's control code in simulation until the code itself solves the task, reaching state of the art among Code-as-Policies methods.

99.00% Robosuite success, single-turn, with no corrective LLM code edits
0 human demonstrations needed
Scroll

Past research

Prior systems kept a language model in the loop to edit code during deployment

Recent CaP systems rely on iterative code generation loops at test time, often leaving them unsuitable for real-time robotics tasks.

66
LLM/VLM calls per trial, at the top end, in the prior CaP-Bench record on Robosuite (CaP-Agent0). Every call adds delay and inference cost.

Past research: a model in the loop

  • Corrects itself mid-rollout (multi-turn)
  • CaP-Agent0 issues up to 66 LLM/VLM calls at test time per trial
  • 68.29% to 24% without multi-turn scaffolding

Robotics Harness Optimization

  • Shifts the compute burden from test-time to training-time
  • Ships a readable repository you can inspect
  • Same action primitives, higher success rate

The idea

Let a coding agent write and rewrite the robot's code until it works.

RHO hands the job to a tool-enabled coding agent and lets it practice in a simulator through reflective evolutionary search: it edits, runs, and debugs whole programs against a scalar reward, keeping the variants that help. The end product is one self-contained multi-file code repository. Because the final product is just code, you can read it, debug it, and reuse it. (For experts: this relocates the model's expensive search out of deployment and into a one-time training phase, so on primitive-only benchmarks we chose to ship fixed Repositories-as-Policies, or RaPs.)

RHO system overview

Search over a robot repository at training time, deploy what it found

Search loop · one generation

1 · Run

A candidate repository runs training trials in the simulator through the benchmark's host services. It earns a reward plus execution traces and judge scores on what went wrong.

Runtime stack

Repository-as-Policy Python policy, LLM harness, or skill graph written by the coding agent
Host services benchmark-owned
Perceptionpose + grasp estimationtrain + deploy
Actionprimitives + IKtrain + deploy
Judge VLMscores rolloutstraining only
Simulator Robosuite · LIBERO · O3DE benchmark-owned

Unlike prior reflective optimization methods, which optimize only a single prompt, function, or delimited code region, RHO's optimizer, HELIX, searches over entire multi-file repositories at once. RHO points it at any robot-policy repository, whether Python policies, LLM agent harnesses, or skill graphs, with live robot-environment access (REaaS) isolated from the evaluator.

CaP-Bench Robosuite · same perception and motion primitives

Where the LLM compute lives

CaP-Agent0 calls language models while the robot runs: up to 6 turns of 11 LLM/VLM calls each, 113.6 s per trial. RHO calls them only during a one-time search; on CaP-Bench we deploy the searched repository as fixed code: 0 code-generation calls, 9.31 s per trial.

plays at 10× speed
CaP-Agent0LLM in the control loop
no training phase

up to 6 turns × 11 LLM/VLM calls = up to 66 calls

68.29%multi-turn success 113.6 smean per trial · 66 calls
RHOfixed code (our CaP-Bench choice)
Search runs once: a coding agent edits the repository and runs simulator trials 99.00% by generation 17 · 16.5 h · $20.50 of mutator tokens
RaP infer(env) → action robot

0 LLM code-generation calls in the control loop

99.00%single-turn success 9.31 smean per trial · 12.20× faster

99.00%: GPT-6.1 Sol mutator, best of two searches, on evaluation seeds never seen in search. Trial times are means over 20 cube-stacking trials; the RHO time uses the GPT-5.5 repository (70.00% success). The 66 calls are the maximum (all 6 turns) and are spaced evenly for illustration.

Show the underlying numbers (data table)
Deployment cost and success on CaP-Bench Robosuite.
SystemModel calls per trialMean trial time (cube stacking, N=20)Robosuite success
CaP-Agent0, multi-turnup to 66 LLM/VLM calls (6 turns × 11)113.6 s68.29%
CaP-Agent0, single-turnup to 11 LLM/VLM calls28.4 s24%
RHO, single-turn0 code-generation calls9.31 s (GPT-5.5 RaP)99.00% (GPT-6.1 Sol) · 70.00% (GPT-5.5)

30.00% 70.00%

With GPT-5.5, a single tool-enabled mutation with unlimited internal turns reaches 30.00% on Robosuite. RHO's repeated reflective search lifts the same model and tools to 70.00%. The search loop, not just the agent, does the work.

The proof

A frozen codebase, run single-turn, still reaches state of the art.

Click a task. Watch the robot run the code.

One single-turn execution of the GPT-5.5 repository: no visual-difference model and no LLM code-generation calls.

Cube lifting

reward 1.00

One single-turn execution of the GPT-5.5 repository: no visual-difference model and no LLM code-generation calls.

99.00% Single-turn success (693/700) with a GPT-6.1 Sol mutator, on evaluation seeds never seen in search.
12.20× Faster per trial than CaP-Agent0 (9.31 s vs 113.6 s), measured with the GPT-5.5 repository at 70.00% (490/700).
0 vs 66 0 LLM code-generation calls in the control loop, vs up to 66 LLM/VLM calls per CaP-Agent0 trial.

CaP-Bench Robosuite: 99.00% with one frozen repository

Per-task success (%) over 100 evaluation trials per task. Both RHO columns deploy the selected repository as fixed, single-turn code; CaP-Agent0 corrects its code over up to 6 turns. The GPT-6.1 Sol column is the better of two searches (the other reached 96.14%, 673/700); both train on seeds 101–125 and evaluate on seeds 1–100. This search reached 99.00% by generation 17, after 16.5 hours and $20.50 of mutator tokens. The rollouts above come from the GPT-5.5 repository.

Robosuite per-task success for RHO with GPT-6.1 Sol (best search), RHO with GPT-5.5, and CaP-Agent0.
TaskRHO GPT-6.1 Sol
single-turn, best search
RHO GPT-5.5
single-turn
CaP-Agent0
multi-turn
Cube lifting1009897
Cube stacking999898
Cube restacking985489
Nut assembly9710
Spill wiping100100100
Two-arm lift1005374
Two-arm handover998620
Overall99.0070.0068.29

CaP-Bench LIBERO-PRO: 64.33% on held-out perturbations, without demonstrations

LIBERO-PRO: per-cell success rate (%), higher is better

Dashed line = RHO overall average (64.33%). OpenVLA scores 0.00% on every cell (bars sit on the axis). Hover, focus, or tap a bar for the exact value.

Show the underlying numbers (data table)
Success across six perturbation types (object, goal, and spatial, each as a swap of initial object positions or a task-level change; 3,000 single-turn trials). With no corrective model edits, RHO outperforms the vision-language-action (VLA) models and the prior Code-as-Policies system.
64.33% RHO success (1930 of 3000), after 50 generations of search on unperturbed LIBERO with a GPT-5.6 Sol mutator.
0.00%OpenVLA
13.20%π0.5 average
18.03%CaP-Agent0
4.87× over π0.5 3.57× over CaP-Agent0 (same APIs) 0 demos used

End-to-end VLAs crater under LIBERO-PRO's perturbations (OpenVLA hits 0.00%), while RHO holds at 64.33%, 4.87× better than π0.5

This contrast is scoped to LIBERO-PRO (perturbed): task-level and position perturbations that test generalization beyond the standard LIBERO training distribution.

Same libero-spatial task ("pick the black bowl on the cookie box, place it on the plate"), same task-level perturbation; π0.5 fails, RHO succeeds.
RHO 64.33% 1930 / 3000
π0.5 13.20% 4.87× lower
OpenVLA 0.00% perturbed setting

On standard LIBERO, OpenVLA and π0.5 score 93.0% and 96.9%; under LIBERO-PRO's perturbations OpenVLA scores 0.00% and π0.5 scores 13.20%.

Watching the code teach itself

RHO search · CaP-Bench Robosuite · GPT-5.5 mutator

From near-zero to a working solver within 200 generations.

Keyboard: Tab to a point, ←/→ to scan generations, Home/End to jump, Esc to dismiss.

View the data as a table (87 accepted candidates)
Mean shaped reward per accepted candidate, by generation, with the best-by-validation running maximum.
candidategenerationmean rewardbest-by-validationnote
Per-task best-by-train mean reward vs generation

7 Robosuite tasks · 87 accepted candidates · the deployed solver is selected by validation at generation 134. These curves are best-by-train running maxima of mean shaped reward on the 10 training trial IDs, distinct from the held-out per-task success counts: five tasks reach training reward 1.00, two-arm lift plateaus near 0.73, and nut assembly stays near 0.06.

· ·

Lines are best-by-train running maxima, so each curve is non-decreasing. Hover, focus, or tap a line for the exact value. Keyboard: Tab to a line to hear its task and final reward; use the legend buttons to toggle lines. A full data table is below.

Show data table (all 87 generations × 7 tasks)
Best-by-train mean reward per task at each accepted generation.

RAI O3DE: RHO optimizes deployed robotic LLM harnesses too

Here the deployment is multi-turn: a language-model agent keeps running while the robot works. Rather than write standalone code, RHO optimizes the agent's harness: its system prompt and the bodies of its tools (the agent's control interface). GPT-5.1 runs inside the harness; GPT-5.5 is the mutator. On the hard held-out split, success nearly doubles from 23.45% to 44.27% (p < 0.001, 3-run average), while using 27% fewer tool calls and 20% less wall-clock time (single representative run; the sign holds under the 3-run average).

23.45% 44.27% held-out hard-split success
27% fewer tool calls 20% less wall-clock time
Before-and-after comparison of the GroupObjects task in the O3DE RAI environment.
GroupObjects: from total failure (0.00%) to 37.50% on the hard split, a zero-to-something unlock from repository-level mutation.
Before-and-after comparison of the CubeTower scene rendered in the O3DE RAI environment.
BuildCubeTower, before and after RHO optimization.
Before-and-after comparison of the MoveObjectsToLeft task in the O3DE RAI environment.
MoveObjectsToLeft, before and after RHO.
Before-and-after comparison of the PlaceCubes task in the O3DE RAI environment.
PlaceCubes, before and after RHO.

Graph-as-Policy: RHO optimizes skill graphs too

Graph-as-Policy (GaP) runs a policy as a directed graph of human-written skills. Starting from the 20-node grocery-packing graph in the GaP codebase (LIBERO, simulated Franka, 11 instructions), we ran two RHO searches of 50 generations each with a GPT-5.6 Terra mutator. Compose-Only may add nodes and rewire the graph but must use the skills as given; Compose-and-Edit may also rewrite the skills. Both searches learned to read the instruction: grasps per single-item task fall from 4.17 to 1.04.

Graph-as-Policy grocery packing: success, cycle time, and throughput for the starting graph and the two RHO searches.
GraphSuccess
100 trials
Cycle timeSuccesses / hrvs. starting graph
Starting graph67/100144.94 ± 95.94 s16.641.00×
RHO, Compose-and-Edit97/10068.03 ± 15.12 s51.333.08×
RHO, Compose-Only96/10039.44 ± 19.94 s87.635.27×

Throughput is successes per hour, following the GaP paper. All three graphs end a trial with the simulator's success check; Compose-Only calls it earlier. A real robot has no such oracle; without it, Compose-Only would be about 2.8× the starting graph. Search cost: $14.39 (Compose-Only) and $22.83 (Compose-and-Edit). Full setup and analysis →

Why rewrite the whole codebase

On Robosuite, mutating a full multi-file repository wins in fewer generations (200 vs 250), and far outperforms rigid structured representations (behavior trees and finite-state machines).

Multi-file repository (200 gen)
70.00%
Single-file stub (250 gen)
63.86%
Behavior trees
33.86%
Finite state machines
18.14%

Only the top two bars share the same backend (Codex GPT-5.5). The behavior-tree baseline used Claude Sonnet 4.6 and the finite-state-machine baseline used Qwen3.6-27B, so the gap to those two bars reflects model capability as well as representation, not a pure structure-only comparison.

Live simulator access helps; RHO's search gives the final push

Two GPT-6.1 Sol coding-agent sessions start from the same six-file scaffold with no task policies, the same robot API documentation, and feedback from the same 12 training trials across three task families. The only difference: one can run candidates against the live simulator (REaaS) before submitting. Each resulting repository is evaluated once on all seven Robosuite tasks over seeds 1–100 (700 trials), single-turn.

One session, no live REaaS
38.00% (266/700)
One session, live REaaS
73.00% (511/700)
RHO search
99.00% (693/700)

With the same GPT-6.1 Sol mutator, RHO's search closes the remaining gap: repeated sessions, the acceptance gate, and the Pareto frontier take one session's 73.00% to 99.00% (best of two searches) on the same 700 trials. The searches also trained on more trials (seeds 101–125) than the single sessions' 12. In the no-access evaluation, 34 trials ended in native simulator crashes; we replayed exactly those trials with the same policy, seeds, and evaluator and report their outcomes (13 successes).

Hardware

Trained in simulation, deployed unchanged on two real robots.

We deployed the GPT-5.5 repository evolved in Robosuite without changing its policy code. Only the perception and motion APIs are swapped for embodiment-specific implementations with the same interfaces.

14/20 Franka Emika Panda, cube lifting.
11/20 Franka Emika Panda, cube stacking.
17/20 Kinova Gen3 with a Robotiq gripper, lifting a computer mouse never seen in simulation.

A new robot and a new object

On the Kinova, three things change from simulation: the search used cubes, and this is a computer mouse; the mouse moves between trials and, in this trial, during execution; and the search used a simulated Franka.

Franka Emika Panda: lift a cube. Success, 3× playback.
Kinova Gen3: lift a mouse moved during the trial. Success, 3× playback.
Ten initial positions of the computer mouse overlaid on one camera frame.
Ten initial mouse positions on the Kinova, overlaid on one frame.

What's still hard

Kinova Gen3, failure (148 s, 3× playback): the mouse was displaced 12 cm two seconds into the trial.

Recovery strategies learned in simulation cover the failures seen in simulation. On real robots, perception degrades under different cameras and lighting, so real-world success can vary even when the program logic executes correctly: the Kinova lifts an unseen mouse in 17 of 20 trials, while the nominally simpler Franka cube lift succeeds in 14 of 20.

Per-task tradeoffs remain in simulation. The GPT-5.5 repository, used for the timing and hardware results, trails CaP-Agent0 on cube restacking (54% vs 89%) and two-arm lift (53% vs 74%).

Run it yourself

The output is just code. Read it, debug it, reuse it.

Cite

Karim Elmaaroufi, Sarunas Kalade, Yansong Wu, Justin Svegliato, Graham Schelle, Negar Mehr, Sanjit A. Seshia, and Matei Zaharia. "RHO: Your Coding Agent is Secretly a Roboticist." arXiv:2606.16458, 2026.

@misc{elmaaroufi2026rho,
  title         = {{$\rho$}: Your Coding Agent is Secretly a Roboticist},
  author        = {Elmaaroufi, Karim and Kalade, Sarunas and Wu, Yansong and Svegliato, Justin and Schelle, Graham and Mehr, Negar and Seshia, Sanjit A. and Zaharia, Matei},
  year          = {2026},
  howpublished  = {arXiv preprint},
  eprint        = {2606.16458},
  archivePrefix = {arXiv},
  primaryClass  = {cs.RO},
  url           = {https://arxiv.org/abs/2606.16458},
  note          = {Robotics Harness Optimization (RHO)}
}