Robots Drop the Model From the Loop: Code Measures Its Own State and Hits 70.24% on 42 Bimanual Tasks
Synopsis
Robot policies no longer keep a model in the control loop. Vision-language-action models hid the state in their weights, and agent harnesses kept memory in a model context, so how an action was derived could not be fully inspected. Here the robot and environment state is written as code variables, the code measures it from camera images and proprioception, and every decision is computed from it; one program runs across all episodes of a task and reaches 70.24% success on RoboDojo's 42 bimanual tasks, 38.9 points above the best leaderboard method.
Interpretation
A robot no longer needs a model to decide at execution time; the policy is entirely code. Code variables hold the robot and environment state, and code logic computes each action from those variables, with the program frozen at runtime. Vision-language-action models previously compressed state and reasoning into weights, and agent harnesses kept task memory in a model context; both still query a model at each decision, and the same memory can yield different actions on different calls. On RoboDojo's 42 bimanual tasks the code policy reaches 70.24% success, 38.9 points above the current best leaderboard method at 31.38%, and above the strongest world action model at 29.64% and the strongest vision-language-action model at 27.96%.
The code measures the state itself instead of taking it from an external perception model or simulator ground truth. Camera parameters, robot meshes and object sizes are constants in the code; each frame projects the robot mesh into the image and masks it out, connected regions differing from the table colour become object candidates, and a known 3D shape is fitted near each candidate by searching position and yaw and keeping the largest overlap. Earlier code policies either had a model write new code online in each episode or took state from a segmentation model or simulator oracle, and those perception models are black boxes whose uncertainty the code does not control. Each measurement is stored as an object record with category, position, yaw, size and confidence in an episode-level state, and an object occluded by the arm keeps its last measured pose; the same program succeeds in 63% of episodes on measured state and 83% on oracle state, and each fixed measurement narrows that gap.
The library is layered, so a new task reuses, inherits or extends existing modules rather than rewriting them. Task programs specify subgoal order and task-specific decisions, while manipulation layers such as grasp, carry and place, plus perception and motion, are shared by all tasks. A vision-language-action model needs new demonstrations and retraining for a new task, and an agent harness builds task-specific memory that carries little across tasks. 83% of the code a new task runs comes from the shared library; on four tasks that had no program when the library was frozen, the code policy reached an average 47% success within 15 hours, while the strongest vision-language-action model reaches 4.7% on those tasks after training on demonstrations.
Perspective
All results are currently in simulation, and perception relies on RoboDojo's public camera parameters, robot meshes and object sizes, which would have to be measured again on a real robot, with contact parameters such as grip widths and carry speeds tuned again. The code policy targets settings that need stable execution of one task across episodes, and development ran on validation layouts, never on test layouts. The work frames itself as an exploration of the upper bound of code-only policies and notes that it can serve as a data engine for vision-language-action models and agent harnesses.
The work attributes the upper bound of the code policy to state representation and code logic: perception and contact errors account for 62% of failures, and incomplete logic plus poor code design for 37%. Generalization is the main weakness, since a small amount of task-specific logic is still needed; success is 54.1% on randomized layouts against 77.3% on standard layouts. Offline development takes time, and every new task carries a development cost. The authors partly attribute the drop on randomized layouts to programs being developed only on validation layouts, and note that the code itself does not depend on the scene.
