PaperlayerView exact revision on arXiv

Source-linked AI summary

RHO: Your Coding Agent is Secretly a Roboticist

Karim Elmaaroufi, Justin Svegliato, Sarunas Kalade, Graham Schelle, Sanjit A. Seshia, Matei Zaharia

arXiv:2606.16458v1cs.RO

TL;DR

CaP systems can require iterative test-time code generation that is often unsuitable for real-time robot control. RHO uses training-time reflective search to evolve interpretable multi-file robot-policy repositories, with reported results across Robosuite, LIBERO-PRO, and O3DE.

  • Problem

    Recent CaP systems rely on iterative test-time code-generation loops that are often infeasible for real-time robot control.

    Source: §1 · p. 1

  • Method

    RHO uses tool-enabled coding agents and reflective feedback from environment interaction to search for interpretable neurosymbolic multi-file policy repositories during training.

    Source: §1 · pp. 1–2

  • Results

    RHO reaches 70.0% on Robosuite, 45.0% on LIBERO-PRO, and 44.3% held-out O3DE success, with single-turn deployment on the first two benchmarks.

    Source: §1 · pp. 2–3, §6 · p. 11

  • Takeaways & Limitations

    RHO reports strong results with single-turn deployment on Robosuite and LIBERO-PRO, while also improving held-out O3DE success with less wall-clock time and fewer tool calls.

    Source: §1 · p. 3, §6 · p. 11

    All benchmarks are simulated; transfer to real robots is expected after perception primitives are re-grounded and simulation-fitted constants are retuned.

    Source: §7 · p. 12

Abstract

from arXiv · show

Code-as-Policies (CaP) has shown that large language models (LLMs) can write code to solve robotics tasks by composing perception, planning, and control primitives. Recent CaP systems, however, rely on multi-turn code-generation loops at test time, which is often infeasible for real-time robot control. We introduce Robotics Harness Optimization (RHO), a novel paradigm in which tool-enabled coding agents, at training time, propose and search for interpretable, neurosymbolic multi-file policy repositories (Repositories-as-Policies) that compose these primitives rather than a single prompt, function, or file. RHO searches with reflective feedback from environment reward and execution rather than teleoperation demonstrations. It generalizes to perturbed pick-and-place settings like LIBERO-PRO, where OpenVLA scores 0.0% and $\pi_{0.5}$ averages 12.83%. Using the same low-level primitives, RHO reaches a 45.0% success rate, 2.5x higher than the strongest multi-turn agentic system, and 3.5x higher than $\pi_{0.5}$. On Robosuite, RHO sets a new state-of-the-art of 70.0%, exceeding the prior multi-turn record of 68.29% using single-turn execution with no corrective LLM code edits at deployment. When an LLM is used in the control loop, as on RAI's O3DE benchmark, RHO optimizes the deployed agent's multi-file harness of prompts, tools, and control code, improving held-out success from 23.5% to 44.3% with 20% less wall-clock time and 27% fewer tool calls.

1 Introduction

Code-as-Policies systems can require iterative test-time code generation that is unsuitable for real-time control, while vision-language-action models can fail under perturbations. RHO searches during training for interpretable multi-file robot policies and reports strong results across three benchmarks.

1 Introduction

  • CaP systems rely on iterative test-time code generation that can be unsuitable for real-time robotics, while VLAs can fail to generalize under perturbations.CaP-Agent0's Robosuite success falls from 68.29% to 24% without its multi-turn scaffolding; OpenVLA and π0.5 score 0.0% and 12.83% on LIBERO-PRO, respectively.Source: §1 · p. 1
  • RHO shifts code generation to training-time reflective evolution, searching interpretable neurosymbolic multi-file policy repositories rather than single prompts or functions.The repository is the deployed policy artifact.Source: §1 · pp. 1–2
  • HELIX uses a tool-enabled coding agent to execute tests, interact with the robot environment, inspect feedback, and edit multiple files within one mutation step.RHO's contributions also include isolation mechanisms between the coding agent, environment service, and evaluator.Source: §1 · p. 2
  • RHO reaches 70.0% on Robosuite and 45.0% on LIBERO-PRO in single-turn evaluations, and raises held-out O3DE success from 23.5% to 44.3%.On O3DE, it also uses 20% less wall-clock time and 27% fewer tool calls.Source: §1 · pp. 2–3

2 Related Work

Related work spans learned visuomotor policies, language-driven robot agents, LLM optimization loops, and reflective evolution. RHO differs by evolving policy repositories through live robot-environment interaction during training rather than repeatedly editing policies at deployment.

Learned visuomotor policies

  • VLA robustness remains bounded by training distributions, while RHO uses coding-agent search to compose modular perception and control primitives across goals and object arrangements.Prior audits report substantial performance drops under viewpoint, paraphrase, and layout perturbations.Source: §2 · p. 3

Code-as-Policies and language-driven robot agents

  • Unlike deployment-facing CaP agents that rewrite executing policies through repeated test-time calls, RHO front-loads code generation and corrective editing into evolutionary search.CaP-Agent0 issues up to eleven LLM calls per turn for up to six turns.Source: §2 · p. 3

LLM optimization loops in robotics

  • Unlike LLM optimization loops that author rewards or curricula for a separate learner, RHO evolves the policy artifact directly rather than training a neural policy on LLM output.Related systems also use LLMs to generate environments, shape rewards, or support neural-policy training.Source: §2 · p. 3

Optimizing agents and reflective evolution

  • RHO grounds repository search in live robot-environment interaction and amortizes coding-agent interactions into training-time search, unlike single-file text-domain harness optimization.HELIX extends reflective evolution from bounded text artifacts to whole multi-file application repositories evolved against a live environment.Source: §2 · pp. 3–4

3 RHO: Searching over multi-file repositories-as-policies

RHO searches over deployable, interpretable neurosymbolic policy repositories rather than isolated prompts or functions. HELIX combines repository-level search and environment feedback with tool-enabled coding agents, while separating mutation from scoring and deployment.

3 RHO: Searching over multi-file repositories-as-policies

  • RHO evolves whole multi-file repositories that combine task routing, control, perception, grasping, and pose helpers into deployable neurosymbolic policies.For CaP-Bench, repositories run as Python controllers without corrective LLM code edits at deployment; for RAI, they define the harness for an LLM-in-the-loop system.Source: §3 · p. 4, §3.1 · p. 5

3.1 Repository-level mutation

  • Repository-level search addresses robotics failures that can require coordinated changes across pose estimation, motion primitives, retries, and task-language interpretation.A bounded-artifact mutator cannot reliably refactor across these interfaces in one move.Source: §3.1 · pp. 4–5
  • RHO selects repositories using environment-provided shaped reward and structured side information, with mean reward evaluated over training minibatches and the full validation set.The evaluator runs each task, trial, and seed as a single rollout and does not expose hidden simulator state or evaluator internals.Source: §3.1 · p. 5
  • A scalar minibatch acceptance gate and per-instance coverage frontier preserve candidates that excel on different validation instances, rather than hill-climbing a single chain.The deployed repository is the terminal-frontier member with the highest mean validation reward; most candidate lineages dead-end, and the solver emerged from a productive branch.Source: §3.1 · p. 5

3.2 Tool-Enabled Mutation

  • Within one mutation step, a tool-enabled coding agent can edit multiple files, run tests and robot rollouts, inspect tracebacks, and query visual-difference feedback.Training uses this interactive mutation surface, while CaP-Bench evaluation restricts scoring to a single-turn policy execution without deployment-time visual feedback or LLM code-generation calls.Source: §3.2 · p. 6
  • A sidecar boundary isolates mutation from scoring by withholding evaluator internals and rejecting candidates that alter protected evaluator artifacts.The sidecar proxies whitelisted benchmark calls rather than containerizing all primitive and robot-environment services.Source: §3.2 · p. 7

4 Experiments

RHO is evaluated on Robosuite and perturbed LIBERO-PRO, with training and deployment surfaces distinguished from held-out evaluation. It exceeds reported baselines on the main comparisons, while experiments also test single-step coding agents, repository structure, and transfer to RAI O3DE.

4 Experiments

  • Experiments cover seven Robosuite tasks and three LIBERO suites; LIBERO-PRO adds object-position swaps and task-description perturbations and is held out from RHO training.Robosuite training uses the first 10 of 100 trial IDs per task, while LIBERO-PRO contains six perturbation cells totaling 3,000 trials.Source: §4 · p. 7

4.1 RQ1: How does RHO compare to current SOTA methods?

  • 45.0% on LIBERO-PRO exceeds CaP-Agent0’s 18.17%, π0.5’s 12.83%, and OpenVLA’s 0.0%; on Robosuite, RHO reaches 70.0% versus CaP-Agent0’s 68.29%.Robosuite uses single-turn S4 deployment with no LLM code-generation calls; LIBERO-PRO results follow 63 generations of training on unperturbed LIBERO tasks.Source: §4.1 · p. 8, Table 1 · p. 8

4.2 RQ2: Does RHO outperform coding agents?

  • 13–30%: single coding-agent mutations with full tool access score in this range on held-out S4, while CaP-Agent0 restricted to S4 scores 24%.The agents receive one mutation step with unlimited internal turns, and the authors report that submissions end below multi-turn results.Source: §4.2 · p. 8, Table 2 · p. 9

4.3 RQ3: Is the repository the right unit of search?

  • 70.0%: the multi-file repository run beats the single-file stub’s 63.86% on Robosuite, while rigid behavior-tree and finite-state-machine scaffolds score 33.86% and 18.14%.The repository run uses the same backend and tools as the single-file comparison, with a smaller generation budget.Source: §4.3 · p. 9, Table 3 · p. 10

4.4 RQ4: Do RHO candidate solutions generalize?

  • On RAI O3DE, hard-split success rises from 0.235 to 0.443, while tool calls fall 27% and wall-clock time falls 20%.The same RHO loop transfers to the RAI stack with a changed candidate artifact and fixed tool-name contract; both selected candidates emerge within a 10-generation budget.Source: §4.4 · p. 10

5 Discussion

Surviving repositories share a set of core perception, planning, and verification components, but differ in how they combine them and handle failures. The discussion links repository search and environment interaction during training to robust, interpretable policies and more capable recovery logic.

5 Discussion

  • Strong repositories add specific recovery and robustness heuristics, including quantile-robust geometry, perception cross-validation, IK feasibility checks, and corrective retries with new plans.The strongest solver also uses held-object offset compensation, score-gated perception, physical-plausibility checks, and tool-center-point offset correction.Source: §5 · p. 10
  • On the RAI hard split, multi-file evolution places detector retries and verified-centroid caching inside a ROS 2 tool API, before the LLM sees a failure.This makes a single tool call more consistent, discriminating, and faster than the single-file approach that asks the LLM to re-perceive and persist between moves.Source: §5 · p. 10
  • RHO relocates environment interaction from repeated deployment-time correction to evolutionary search, where feedback can be compiled into the shipped repository.CaP-Agent0 drops from 68.29% to 24% without its multi-turn visual-difference loop, while the strongest HELIX repositories are those whose search engaged feedback most.Source: §5 · p. 11
  • Repository search discovers interpretable, reusable neurosymbolic mechanisms rather than requiring them to be designed in advance.The paper distinguishes checking comparable logic inside an end-to-end neural policy as a separate interpretability and formal-verification problem [91].Source: §5 · pp. 10–11

6 Conclusion

RHO searches for interpretable neurosymbolic multi-file robot policies by combining HELIX, REaaS, and evaluator isolation. It reports strong single-turn CaP-Bench results and transfers to RAI’s LLM-in-the-loop setting with fewer tool calls and less wall-clock time.

6 Conclusion

  • RHO combines repository-level coding-agent mutation, robot-environment rollouts during search, and evaluator isolation to propose interpretable neurosymbolic multi-file policies.Isolation separates mutation from scoring to prevent benchmark cheating without performance degradation.Source: §6 · p. 11
  • 70.0% on Robosuite and 45.0% on LIBERO-PRO perturbations set single-turn CaP-Bench state-of-the-art results without LLM code-generation calls in the control loop.The reported comparisons are 68.29% for CaP-Agent0 on Robosuite and 18.17% for the prior agent, 0.0% for OpenVLA, and 12.83% for π0.5 on LIBERO-PRO.Source: §6 · p. 11
  • On the hard RAI ROS 2 subset, RHO improves task success while reducing tool calls by 27% and wall-clock time by 20%.A single-file ablation inflates tool calls by 16% and wall-clock time by 34%.Source: §6 · p. 11
  • The authors identify vector-valued objectives that include repository size, execution latency, and deployment tool or service count as a future direction.They also propose deploying the RAI solution to production environments.Source: §6 · p. 11

7 Limitations

RHO’s spatial reasoning is bounded by the LLM driving its search, and the reported benchmarks are simulated. The studied policies use symbolic primitive-calling code over learned services and require re-grounding and retuning for expected transfer to real robots.

7 Limitations

  • The LLM driving RHO’s search misjudges quantitative depth, vertical clearance, and multi-object composition under modest perturbations, setting a natural ceiling for fine-geometric tasks.The authors state that stronger spatially grounded models could relax this limit.Source: §7 · p. 11
  • All reported benchmarks are simulated, and the studied RHO instances emit symbolic primitive-calling code over learned perception, grasping, and motion services.The reported systems do not train an end-to-end neural policy on the simulator.Source: §7 · p. 12
  • Transfer to real robots is expected only after perception primitives are re-grounded and simulation-fitted constants are retuned.Source: §7 · p. 12
  • Shell access exposes experimental infrastructure as well as reward signals; a preliminary agent terminated an SSH session and fork-bombed the host.The authors treat natural-language correction as insufficient containment and motivate a hard isolation boundary.Source: §7 · p. 12

A.1 Methodology Appendix

The appendix specifies HELIX’s evaluation and mutation setup, the train/validation/deployment regimes, and the deployed solver interface. It also records the reported run configuration and the candidate-selection inputs.

A.1 Methodology Appendix

  • The canonical RHO run selects candidate g134-s134 as the mutable solver/Python package evaluated under evaluate.py, API_REFERENCE.md, and the reported helix.toml settings.The recorded backend is codex with model gpt-5.5, effort xhigh, and max_turns=150.Source: §A.1 · p. 22
  • M4 is the multi-turn training regime with execution feedback and diagnostics, while S4 freezes the selected source tree for single-turn deployment through solver.main.run(ctx).VDM informs mutation but is withheld from the S4 deployment surface and acceptance; external S4 replay is the deployment evaluation.Source: §A.1 · p. 22
  • Training and validation each use 70 trials across seven task families, while the S4 headline evaluates 700 trials, including 630 held-out trials.Training and validation draw the same first ten trial IDs per task, so RHO never sees the remaining 90 IDs per task.Source: §A.1 · p. 22
  • The evaluator runs solver.main.run(ctx) for each native task/trial and returns a trajectory, shaped scalar reward, and auxiliary side information.Task success uses a reward threshold of 1.0; auxiliary information can include task completion, judge axes, integrity flags, and an M4-only VDM summary.Source: §A.1 · pp. 22–23
  • The deployed multi-file solver package routes instructions through task routines and shared helpers, with all benchmark interaction passing through ctx.run(ctx) observes once, dispatches to a task routine, and returns a status dictionary; the package communicates through stdout and ctx and owns no external services.Source: §A.1 · p. 22, Figure 5 · p. 23
  • The reported HELIX run uses strict-improvement acceptance, a per-instance frontier, minibatches of two, stratified sampling, and no merge or crossover.Its final state records generation and mutation counter 200, 87 retained frontier candidates, and 70 active validation keys.Source: §A.1 · pp. 22–23
  • HELIX uses environment-provided shaped reward for scoring and feeds judge feedback, VDM summaries, output streams, and last-run files into future mutation prompts as diagnostics.These diagnostics are not inputs to the frozen deployment solver.Source: §A.1 · p. 23
  • The bounded coding-agent mutation session edits a copied parent worktree and only the package surface, terminating when the agent stops issuing tool calls.The reported run uses Codex on gpt-5.5 at xhigh effort with 150 turns; evaluation across five supported backends is outside the reported run.Source: §A.1 · p. 23

A.1.1 Run State, Lineage, and Audit Trail

The audit identifies the selected deployed candidate and distinguishes it from rejected or baseline runs. HELIX retains lineage, evaluation snapshots, rejected attempts, and skip records, while mutation proposals require paired minibatch scoring and validation promotion.

A.1.1 Run State, Lineage, and Audit Trail

  • The audit records 166 lineage nodes through g182-s182, with 87 full validation files, 77 rejected train-minibatch attempts, and 28 skip records.The repository retains candidate worktrees, accepted evaluation snapshots, controller logs, and evaluator manifests.Source: §A.1.1 · pp. 23–24
  • A mutation child is accepted only after paired minibatch scoring and validation promotion.Figure 6 depicts diagnostics and reflection prompting a bounded coding-agent edit before this acceptance process.Source: Figure 6 · p. 24
  • The selected candidate g134-s134 scores 0.730982 mean reward and 49/70 active instance-frontier keys, matching the external 490/700 headline; the one-shot baseline scores 0.0% success on validation.The baseline g1-s1 has mean reward 0.106741; g97-s97 is a rejected train-minibatch attempt, not the reported selection.Source: §A.1.1 · p. 24

A.1.2 Configuration, Budgets, and Judge Prompt

The configuration fixes the evaluator interface and runtime constraints, while the judge provides reflection-only capability feedback. The final selected candidate is reported with validation and external replay results.

A.1.2 Configuration, Budgets, and Judge Prompt

  • The evaluator preserves solver.main.run(ctx), uses the documented runtime API, covers seven task groups with ten native trial labels each, and makes one judge call per candidate.Protected evaluator-owned files and the helix_result score parser define the evaluation boundary.Source: §A.1.2 · p. 24
  • The selected candidate scored 0.730982 mean shaped reward and solved 49/70 validation trials; its accepted external S4 replay reports 490/700.The run reached generation 200 with 200 mutations and retained 87 candidates; it took 79.4 hours and recorded 6,814 evaluations.Source: §A.1.2 · p. 24
  • The mutator workspace, evaluator-owned files, candidate container, and network edge are separated before candidate acceptance.Figure 7 depicts the sandboxing zones enforced around protected files.Source: §A.1.2 · p. 24, Figure 7 · p. 25
  • The judge scores five capability axes from 0.0 to 1.0 and flags integrity; its scores do not affect acceptance and instead inform the next mutation prompt.MAJOR integrity caps axis scores at 0.25, while SEVERE sets them to 0.0.Source: §A.1.2 · p. 25

A.1.3 RAI Portability Protocol

The RAI protocol tests the train-time edit-and-freeze recipe on an O3DE manipulation benchmark while leaving RAI’s deployment loop intact. Multi-file optimization improves held-out results in both easy and hard settings.

A.1.3 RAI Portability Protocol

  • RHO evolves RAI’s prompts and tool-edit Python module for O3DE, but not its deployment loop, ROS 2 connector, or inference-time driver.RAI is a ROS 2-oriented embodied-agent framework evaluated here on an O3DE manipulation benchmark.Source: §A.1.3 · p. 25
  • The hard O3DE multi-file cell lifts seed success from 0.235 to 0.443 (+0.208, p < 0.001), and the easy cell lifts it from 0.683 to 0.889 (+0.206, p < 0.001).The easy headline averages 21 held-out test tasks over three runs; candidates are selected by train performance after ten generations per cell.Source: §A.1.3 · p. 25
  • The benchmark uses class-stratified train/test splits of 21/21 on the easy pool and 22/21 on the hard pool.The replication ran with the RAI agent, ROS 2 stack, and O3DE simulator co-resident on one AMD Ryzen AI Max+ 395 workstation with 128 GB unified memory.Source: §A.1.3 · pp. 25–26
  • At deployment, HELIX’s mutator is inactive, while RAI’s deployment driver remains on the inference path.The no-solver-owned code-generation invariant applies to the CaP-X solver instantiation, not the RAI portability test.Source: §A.1.3 · p. 25

A.1.4 Mutator reflection-prompt template

HELIX builds each mutation reflection prompt from the task instructions, the parent’s evaluator output, domain context, and a fixed task request. The prompt directs the coding agent to make targeted changes while preserving the required interface and runtime API.

A.1.4 Mutator reflection-prompt template

  • Each mutation prompt combines a fixed task preamble, the parent candidate’s full evaluator output, helix.toml domain context, and a fixed task request.Diagnostics fields depend on the evaluator’s side_info keys and are rendered in sorted-key order.Source: §A.1.4 · p. 26
  • The task objective is to maximize shaped reward for simulated Franka manipulation while preserving solver.main.run(ctx) and using only the documented runtime API.When diagnostics are available, the agent is instructed to prioritize concrete examples and preserve behavior that already scores well.Source: §A.1.4 · p. 26
  • The prompt asks the agent to analyze evaluation results and make targeted, meaningful code changes, with a 150-turn tool-call limit.The diagnostic template can include capability scores, failure hypotheses, minimal experiments, behavior to preserve, API misuse observations, integrity warnings, task completion, and visual-difference summaries.Source: §A.1.4 · pp. 26–27
  • The capability-score block uses the five LLM-judge axes, and the verbatim judge prompt is released in the supplementary artifact.The domain scaffold points to the API reference and encodes documented primitives, closed-loop FSM preference, integrity rules, and verification gates.Source: §A.1.4 · pp. 26–27

A.1.5 Seed configurations

The canonical multi-file seed reaches a 70.0% external Robosuite result, while the stub-main seed collapses into monolithic rewrites. HELIX requires an invocation signature and compares a scaffolded repository with a minimal entry point.

A.1.5 Seed configurations

  • HELIX requires a generation-0 seed repository exposing the benchmark invocation signature, and compares a task-scaffolded Skeleton seed with a minimal stub-main seed.The Skeleton seed pre-populates a router, per-task solvers, and shared helpers.Source: §A.1.5 · p. 27
  • The 200-generation canonical multi-file run selected g134-s134 at 70.0% (490/700) on CaP-Bench Robosuite S4 external evaluation.Source: §A.1.5 · p. 27
  • The stub-main seed supplies only a six-line entry point that prints and returns a stub status.Source: §A.1.5 · p. 27
  • Without task-family scaffolding, the stub-main run rarely refactors its monolithic function and terminates without a candidate matching the selected Skeleton-lineage solver.The failure mode is repeated single-function rewrites that subsequent mutations must repair.Source: §A.1.5 · p. 27

A.2 Experiments Appendix

The appendix details RHO’s experimental performance on LIBERO-PRO, CaP-Bench, and RAI’s EASY and HARD subsets, alongside runtime, training-time search, and comparisons of multi-file and prompt-only edits. It also presents evolved prompt recipes and policy rules, and examines compute costs, task-class strengths, and complementary prompt and tool changes.

A.2.1 Benchmark protocols; A.2.3 Comparator reconstruction

  • CaP-Bench covers seven Robosuite tasks with 100 trials each; LIBERO-PRO covers six perturbation conditions with 10 tasks and 50 trials per task.CaP-Bench compares against Agent0 +3M at 68.29%; LIBERO-PRO baselines include OpenVLA at 0.00 on all six aggregate cells and a derived CaP-Agent0 aggregate of 18.17% (545/3000).Source: §A.2.1 · p. 28, §A.2.3 · p. 28

A.2.2 Deployment audit and S4 contract; A.2.4 Runtime and latency ledger

  • RHO’s CaP-Bench deployment is S4 single-turn, with VDM disabled and no solver-owned code-generation client; mean episode time is 189.1 s/trial and p95 is 438.5 s.Figure 8 reports up to 66 deploy-time LLM calls per Agent0 trial versus none for RHO; Table 5 identifies cube_stack at 44.8 s mean and nut_assembly at 409.2 s mean.Source: §A.2.2 · p. 28, §A.2.4 · p. 28, Figure 8 · p. 29

A.2.5 Backend selected-run sensitivity

  • Across accepted single CaP-Bench S4 runs, selected-run scores range from 70.0% for the reported Codex run to 33.9% for Sonnet 4.6 Behavior Tree.The 36.1 percentage-point spread is a selected-run comparison, not a multi-seed backend ranking.Source: §A.2.5 · p. 29

A.2.6 Training-time REaaS tool use

  • The reported run records 1,776 REaaS calls, and candidate runs, primitive calls, visual-difference queries, and re-observations generally decline with solver success.The weakest FSM run makes 62 total calls, including 57 resets, but runs a candidate only five times and never queries visual difference or re-observes; these selected-run patterns do not establish causation.Source: §A.2.6 · pp. 29–30

A.2.7 LIBERO-PRO condition cells

  • RHO reaches 45.0% (1,351/3,000) on LIBERO-PRO without a LIBERO gradient update, and 70.0% on CaP-Bench versus Agent0’s 68.29%.On LIBERO-PRO, condition scores are 50.6% goal-swap, 55.6% goal-task, 12.2% object-swap, 37.2% object-task, 53.0% spatial-swap, and 61.6% spatial-task.Source: Figure 8 · p. 29, §A.2.7 · p. 30
  • Object-swap is RHO’s weakest LIBERO-PRO cell: 325 of 439 failures involve false-positive lift verification, while 114 exhaust the 12-attempt grasp budget.The target is relocated and still localized with 0.94+ mask confidence; the solver’s hand-fitted grasp schedule and re-segmentation-based verifier fail to transfer to the changed scene.Source: §A.2.7 · pp. 31–32

A.2.8 Training ledger; A.2.9 Cross-run training budget; A.2.10 Evaluator integrity details and unmeasured variants

  • RHO’s reported training run cost an estimated $2,821 and took 79.4 hours; its 490/700 score exceeds the strongest single-shot point of 210/700 (30%).The single-shot range is $0–$3.19 per pass and 13–30% on the same split; evaluator-integrity checks fired zero times, while sandbox-off and manifest-only variants were not measured.Source: §A.2.9 · p. 33, §A.2.8 · p. 33, §A.2.10 · p. 33

A.3 RHO on an LLM-in-the-loop Robotics Stack; A.3.1 Background: the RAI framework and the manipulation_o3de benchmark; A.3.2 Experimental setup

  • For RAI manipulation_o3de, RHO evolves a repository defining an LLM’s prompts and tools, comparing multi-file prompt-and-tool mutation with a prompt-only ablation under a fixed tool-name contract.The benchmark uses ROS 2 interfaces and the study evaluates separate EASY and HARD cells; this appendix part describes the setup, not their results.Source: §A.3 · p. 34, §A.3.1 · pp. 34, 36, §A.3.2 · pp. 36–37

A.3.2 Experimental setup

  • The held-out protocol averages each cell over three independent runs on its unseen test half, and the appendix reports that the same evolution apparatus transfers to the O3DE robotics stack.The discussion specifies an AST-level check that preserves the fixed tool API and reports statistically significant MF lifts on both subsets; the experiments ran on a single workstation.Source: §A.3.2 · p. 37, §A.3.5 · pp. 42–43

A.3.3 Results: the easy subset

  • On EASY, MF raises held-out mean from 68.3% to 88.9% (+20.6 pp, p < 0.001), while its best-by-train candidate exceeds SF by 9.5 pp.SF also improves held-out mean from 65.1% to 79.4% (+14.3 pp, p ≈0.012); the reported 95% CI for the MF–SF gap is [+5.0, +14.0] pp.Source: §A.3.3 · p. 37

A.3.5 Discussion

  • Evolved candidates reduce run-to-run variance: on EASY both MF and SF have σ = 2.8 pp versus seed σ values of 9.9 and 7.3 pp, and on HARD MF has σ = 2.4 pp and SF 5.4 pp.On HARD, seed σ values are 3.8 pp and 12.0 pp; the appendix frames this variance reduction as a useful reproducibility side effect.Source: §A.3.3 · p. 38, §A.3.5 · p. 42

What RHO learned: insights from the evolved prompts and tools

  • MF combines expanded prompt guidance with tool-side color verification, query fallbacks, and detection caching, addressing perception failures that prompt-only SF cannot fix.The evolved prompt also codifies tool-call discipline, coordinate conventions, object naming, pick/place rules, and task-specific recipes; the appendix reproduces the seed, SF, and MF prompts, including the 78-line SF prompt and the seed’s coordinate-convention error.Source: What RHO learned: insights from the… · pp. 38–39, §A.3.6 · p. 43

A.3.4 Results: the hard subset

  • On HARD, MF produces a +20.8 pp held-out lift (p < 0.001), while SF produces a smaller +11.8 pp lift (p ≈0.023).The best-by-train MF–SF gap is +6.7 pp (95% CI [+0.0, +13.0] pp, t = 1.96); its lower bound touches zero.Source: §A.3.4 · p. 40, Table 13 · p. 40

Where the lift comes from: SF and MF are complementary on HARD

  • On HARD, SF gains +38.8 pp on BUILDCUBETOWER and +31.3 pp on MOVEOBJECTSTOLEFT, while MF gains +37.5 pp on GROUPOBJECTS and +13.3 pp on PLACECUBES.SF regresses on GROUPOBJECTS from 15.3% to 9.7%, and neither cell substantially improves its weaker class; MF leads overall partly because GROUPOBJECTS accounts for 8 of 21 test tasks.Source: Where the lift comes from: SF and MF… · pp. 40–41, Table 14 · p. 40

What RHO learned on HARD

  • On HARD, MF expands tools.py from 375 to 1,287 lines while adding only about 25 prompt lines, targeting perception-dominated failures with tool-body edits.SF instead expands its prompt to about 120 lines; the mutator’s ability to direct edits toward the relevant failure modes is a distinct finding of the HARD results.Source: What RHO learned on HARD · pp. 41–42

Compute: tool calls and wall time

  • MF reduces tool calls and wall time on EASY by 17.6% and 3.8%, and on HARD by 27.3% and 20.3%, respectively.SF reduces both costs on EASY (9.2% fewer tool calls, 8.2% less wall time) but increases them on HARD (16.2% more calls, 34.0% more wall time) by re-perceiving between moves and persisting until task completion.Source: Compute: tool calls and wall time · pp. 38, 41, §A.3.5 · p. 42

A.3.8 SF-evolved prompt (best-by-train, g2-s2)

  • The SF-evolved prompt specifies rules for making cubes adjacent, stacking requested cubes into a tower, and forming separate clusters by object type.It gives spacing guidance for adjacent cubes and clusters, and specifies increasing drop heights for tower cubes.Source: §A.3.8 · p. 44

A.3.9 MF-evolved prompt (best-by-train, g8-s8)

  • The headline MF-evolved prompt produced the MF rows in Tables 11 and 12.It is the prompt from which the inline snippets in Section A.3.3 are excerpted.Source: §A.3.9 · p. 44
  • The MF prompt requires fresh camera and object-position results, exact centroid grabs, one grab/drop pair per move, and re-detection when positions may change.It also specifies valid tool arguments, task-matched aids, and skipping object types that were not detected.Source: §A.3.9 · pp. 44–46
  • The MF prompt gives separate recipes for left-side placement, towers, cube adjacency, type-based clusters, and coordinate placement.Recipes include preserving a tower’s existing base, moving only isolated cubes for adjacency, and resolving object identity before coordinate placement.Source: §A.3.9 · pp. 45–46
Loading 2606.16458v1…