Robots That Write Their Own Playbooks: ACE-CaP-0 Turns LLM Reasoning Into Frozen, Reusable Manipulation Programs at 92% Success

An agentic pipeline converts frontier-model reasoning into standalone robot programs via human demos on request and sim on demand. 92.1% success across 240 real-world trials, no human in the loop at runtime.

Imagine you're training a new cook. You could stand behind them every single shift, calling out each step — or you could watch them attempt a few dishes, step in to demonstrate the tricky flip, let them practice on a simulator when the stove is occupied, then hand them a printed recipe card they can execute alone forever. ACE-CaP-0 is Option B for robots. The paper's core mechanism is turning expensive LLM reasoning into frozen executable code that runs without further model calls, using two just-in-time resources: human demonstrations requested only when the agent gets stuck, and simulation invoked only when physical experimentation is too costly or risky. The committed claim: a coding agent can acquire reliable physical manipulation skills through a structured pipeline of real-world trial, selective human demo, and selective simulation — producing frozen Python programs that achieve 92.1% success (221/240 trials) across eight real-world bimanual and multi-object tasks, with mean execution times under 2.3 minutes. This is not a teleop system or a policy that phones home to GPT every cycle. The programs run with runtime perception and control but zero human or LLM involvement. Where does this sit on the ladder? The relevant comparison class is Code-as-Policies (CaP) from Liang et al. (2023) and its descendants — SayCan, VoxPoser, Progprompt — plus the growing literature on LLM-based robot agents (e.g., Inner Monologue, ReKep). Most prior CaP work demonstrates single-arm, single-object tasks with high dependence on either continuous LLM calls or carefully engineered primitives. ACE-CaP-0 advances along two axes: task complexity (bimanual coordination, multi-object alignment) and autonomy at runtime (frozen code, no LLM in the loop). The 92.1% number across 240 trials is strong for manipulation research, though it is self-reported on author-chosen tasks and not benchmarked against a community standard suite. Architecturally, this belongs to the code-generation agent family: a frontier LLM (the coding agent) iteratively writes and revises Python control policies that call into a perception-and-control API. The key structural choices are (1) Demonstrations on Request — the agent can ask a human operator to teleoperate a demonstration when it identifies a skill gap, and (2) Simulation on Demand — the agent selectively uses simulation to explore and test candidate policies before committing to physical trials. Both are invoked by the agent itself, not by a fixed schedule. The compute dependency is on the frontier model during policy development only; runtime is pure code execution on robot hardware. Integrity is the paper's weakest link. All eight tasks were designed by the authors. Success is judged by the authors. There is no community benchmark, no pre-registration, and no independent replication. The 240-trial count (30 per task × 8 tasks) is respectable for a manipulation paper, but the task selection itself could favor the method. The ablation studies — comparing variants with and without demonstrations, with and without simulation — are informative, but the strongest baseline would be a competing method (e.g., a pure RL policy, a behavior-cloning approach) on the same tasks, which is not provided. Code release status is not stated. The milestone question for CaP-style systems is task generality. ACE-CaP-0 demonstrates 8 tasks. The field needs to show that the same pipeline can handle 50+ diverse tasks without per-task human engineering — the threshold where frozen code policies become a practical alternative to end-to-end learned policies for industrial manipulation. We are at 8; the next real unlock is likely at 50–100 tasks with cross-task transfer of learned code primitives. The obvious experiment the authors did not run: deploying the frozen programs in a genuinely novel environment — different robot, different objects, different workspace geometry — to test how much of the 92.1% success is bound to the specific physical setup versus truly portable. The honest read is (a) this is expensive and logistically hard, and (c) it is likely the core contribution of the next paper in this line.