Paper: *Coding Agents for Generalized Task and Motion Planning Problems* (arXiv 2609.30233, submitted 09-24). Code and all agent prompts are open-sourced.
Customs verdict first: the paraphrase circulating online is clean — 28 environments, 7 program synthesis methods, 980 programs × 100 held-out instances = 98,000 evaluation episodes, Claude Code at 82% vs. 47% for traditional planners (1.7×), novel non-prehensile strategies — all check out against the paper. But two key omissions exist, and they are the two most informative facts. More on those below.
What the paper does
TAMP (Task and Motion Planning) is a classic robotics headache: discrete decisions are tightly coupled with geometric, kinematic, and dynamic constraints. Traditional methods rely on hand-designed predicates, operators, samplers, and skills — every new domain needs experts to rebuild a round of components. Generalized TAMP aims to reuse planning results across instances, but existing approaches still demand heavy TAMP-specific engineering.
The paper's question is minimal: can off-the-shelf coding agents automate this? Give the agent a task description and simulator access, let it explore freely within a fixed synthesis budget — writing test code to probe the simulator, observing results, revising programs — then deliver a fixed program. Freeze it, run it on 100 unseen instances. Test time is pure program execution, zero LLM calls.
Three backends: Claude Code (Opus 5), Codex (GPT-5.6 Sol), Codex (GPT-6 Astra). The 28 simulated environments come from KinDER (25, four families: 2D/3D × kinematic/dynamic, with dynamic tasks including sweeping, pouring, and throwing) plus 3 PDDLStream domains, with object counts beyond the original benchmark's evaluation range. The sandbox is bare: only a Python interpreter with NumPy/SciPy — no internet, no motion planning libraries — forcing the agent to write everything end-to-end.
The numbers
- Across the 16 environments with comparison baselines, all three agent configurations beat the hand-designed traditional planner: Claude Code averages 82% (1.7× the planner's 47%), Codex GPT-6 Astra hits 95%, GPT-5.6 Sol 56%.
- As object counts increase, agent programs maintain high success rates with per-instance compute averaging an order of magnitude lower; planner runtime skyrockets and success rates drop.
- Agents also beat LLMGenPlan (the LLM generalization-planning baseline) and one-shot generation variants — the latter two baselines were even given environment source code.
- The +source-code setting (agent can read environment implementation) serves as a performance-ceiling reference.
The two omissions
First: Tom Silver is on the author list. The original author of PDDLStream personally participated in this study of "using coding agents to replace TAMP-specific engineering," and released the code. So this is not an external challenger raiding the gates — it's a handover experiment conducted by the core developer of the traditional TAMP ecosystem. The original benchmark's official implementation (predicates/operators/samplers/skills) runs on his specification. The author of the disrupted methodology personally refereeing the disruption — this kind of self-disruption is far more credible during a methodology transition than external attack.
Second: the top score isn't Claude Code's 82%, it's GPT-6 Astra's 95%. The circulating summary only mentions 82%; the actual leader is Codex with GPT-6 Astra. In our coverage this model has now appeared a third time: LIBERO-PRO 92.63%, VLN-CE 79.0%, and now TAMP at 95% — a three-peat across embodied/planning benchmarks, none of them its own vendor's official benchmark.
One paper self-assessment worth recording: the agent's autonomously discovered non-prehensile maneuvers and exploitation of environmental layouts are strategies not documented in the existing literature — the authors call this qualitative evidence "among the strongest in our study." The kind of output that reciting training data can't explain.
Two engineering details easy to skim past
One: the agent is required to commit the program to a git repo before every test — the paper uses this to replay every revision and trace how programs evolved during synthesis. The exploration process itself is fully archived. This design shares the same intuition as recent self-improvement work that "keeps the original discovery tree / keeps rejected edits": the evolution trajectory is an asset, not garbage.
Two: the answer to Q3 (what is the agentic advantage) lands on custom testing. In the StickButton environment, Opus wrote its own script to repeatedly call reset with different seeds, inspected sampled states, and saved edge cases like "the stick against the wall" and "the tall button," mixing them with typical instances to test its own program. Verification bandwidth isn't issued from outside — the agent earned it itself at compile time. Before the program was frozen and shipped, it had already been hammered by the agent's own tests.
An observation
What's most worth extending from this paper is its economic structure: all LLM tokens are spent at synthesis time; runtime is a fixed Python program with no LLM. Planning is compiled away once, rather than paying inference costs at every execution. This aligns with the recent "cheaper at inference time is better" pattern: multiple-choice questions collapse into closed sets, reflexive actions collapse into interface scoring — and here, planning collapses into program synthesis. Three collapses, one judgment: the unit cost of runtime intelligence determines the deployment ceiling.
Also, the bare sandbox (only NumPy/SciPy) shares the same interface philosophy as "just give the model an IPython": the tool menu converges to one language, and structure is carried by the code itself. 98,000 episodes show that in the planning domain, this convergence holds.
One concrete question to end on: how much do these frozen programs retain on a different simulator — the paper doesn't test it, leaving it to the next team.