Fewer Tokens, Better Action: GPT-6 Astra Robot Agents with 14% Higher Success Rate but 65% Fewer Tokens
Ruiyang Si, Jianxin Bi, Shunyu Yang, Rui Ni, Wenbo Huang, Qiang Wang, Shulong Jiang, Duomin Wang, Xiuyu Li, Haiwen Feng, Zhen Dong, Daquan Zhou
cs.CV
2026-10-02
PyRUA-Lean writes Python cells that compose robot primitives, retry locally, and return only requested images: success 63.1%→71.7% on 700 tasks, 65% fewer input tokens.
VLM agents usually drive robots through tool calling: at each step the model reads the current observation and picks one primitive to invoke, whether a motion command, a perception query, or a grasp. That interface has two built-in costs. Any operation that depends on a previous result needs another model invocation, and intermediate results pile up in the conversation and get reprocessed on every later call. In systems like RPent, motion primitives also return several camera images automatically after each step. For tasks that loop through localization, motion, and recovery, most of the budget goes to model traffic even when the primitives themselves are reliable.
The paper asks a narrow question: with the same primitives and the same planner, what happens to success rate and token cost when the interface switches from tool calls to writing code.
PyRUA-Lean exposes the robot as a Python object named robo, with every primitive as a method. The agent submits code cells through a python(code) tool, the runtime executes them, and feedback returns to the model at cell end. Three mechanisms carry the design:
The recorded bowl-placement example makes this concrete. One cell replaces four baseline steps: it computes the bowl's base height from a world-coordinate map with numpy, derives a placement target, runs a guarded descent and release, and requests a camera image only if the task is still unfinished. That successful run returned five printed lines and zero images.
The design logic is plain. Dependency handling between operations never needed the model, so it moves into the runtime; and since the code decides what comes back, observation traffic is controlled at the source rather than filtered afterward.
700 paired simulated task instances (LIBERO-PRO, RoboTwin 2.0, RoboCasa365), both agents on the same GPT-6 Astra planner, the same frozen VLA policies, and equal budgets (40 LLM calls per episode, 100 for composite tasks):
| Metric | Tool calling (RPent) | PyRUA-Lean | Gap |
| Overall success | 63.1% | 71.7% | +8.6 pp |
| LLM calls per episode | 17.0 | 8.7 | 2.0× |
| Input tokens | 788k | 276k | 2.9× |
| Cost per episode | $1.63 | $0.74 | 2.2× |
Per benchmark, success moves from 83.0 to 94.0 on LIBERO-PRO, 60.0 to 69.2 on RoboTwin 2.0, 78.9 to 86.7 on RC365 atomic tasks, and 34.4 to 39.4 on composite tasks. PyRUA-Lean alone solves 96 instances; tool calling alone solves 36.
The paper decomposes the savings: on LIBERO-PRO the 4.48× token ratio is 2.55× fewer calls times 1.76× fewer tokens per call, so invocation count does most of the work. Ablations show the advantage survives removing VLA policies or operating guides; on RoboTwin 2.0 without VLA, code reaches 68.8% against 42.8% for tool calling. One counterresult matters: adding on-demand images to the tool-calling baseline drops its success from 83.0% to 68.5%, so selective observation only helps when tied to programmatic execution and replanning. A three-task RoboDojo pilot gives 26.7% versus 3.4%, with total tokens per success falling from 11.56M to 1.07M.
This is an interface paper and the finding travels beyond robotics: in any multi-step agent with expensive observations and dependent steps, having the model write code instead of calling tools one at a time can cut cost and raise success at the same time. It extends the CodeAct line of evidence to robot manipulation, where observations are images and primitives fail, and it treats inference cost as a first-class metric, which embodiment papers rarely do. The method itself is not new; code-based robot control goes back through Code as Policies. The contribution is the controlled measurement.
The authors list the hard ones: a single planner (GPT-6 Astra), one run per task instance, simulation only, and interfaces compared as wholes, so the separate contributions of composition, persistent state, and selective feedback are not isolated.
A few more things stand out. Gains are smallest on VLA-dominated tasks, where the initial prompt dominates input tokens and PyRUA-Lean's larger API description eats into the benefit; counting failed episodes, the cost advantage on RC365 atomic falls to about 1.1×. Of the 96 code-only successes, 52 correspond to the baseline exhausting its call budget, but the other 44 ended early in failure, and the authors concede some of those trace to VLA luck rather than better recovery logic. The token-budget curves in Figure 3 are retrospective cutoffs on recorded trajectories, not reruns. Both agents also run inside the Codex CLI, which compacts history near 272K tokens, so context management is not fully determined by the interface.