Researchers from Peking University, the National University of Singapore, NVIDIA, and others improved both the success rate and the cost of the AI agents that drive robots by changing the interface rather than the brain. Instead of making the model pick one action at a time, they let it write short Python programs. With the exact same model (GPT-6 Astra) and the same robot primitives, success rate rose from 63.1% to 71.7%, and on tasks both approaches solved, it used 65% fewer input tokens. The key wasn't a "smarter model" but a different channel for telling the model what to do.
One common way to drive a robot today is to show a vision-language model (VLM, a model that reads images and text together) the camera feed and the robot's state, then have it pick an action primitive like "grasp" or "move." The problem is cost. In a tool-calling setup, the more a task depends on what just happened, the more you have to call the model again and again. Reach to grasp something, check whether the grip actually took, and retry if it didn't — each of those tiny decisions becomes its own model call.
On top of that, the observations pile up. In the RPent system the authors use as their baseline, every time an action finishes, several camera images and state values get automatically stitched into the model's conversation. With an image attached every turn, the context balloons fast, and that bloated context gets counted as tokens all over again on the next call.
Picture a line cook who phones the head chef after every single onion — "chopped it, what's next?" — and attaches a full photo of the counter each time. Even the trivial steps that need no judgment get escalated upstairs, and the phone bill (tokens) explodes.
The idea behind PyRUA-Lean (Python for Lean Robot-Use Agents) is simple. Don't make the model pick one action at a time; let it write a short Python snippet (a cell) instead.
The robot is exposed as a Python object called robo, and the model submits code through a python(code) tool. Inside that code it composes several actions, checks intermediate results with if, and retries on the spot when something fails. Because all of that branching and retrying finishes inside a single cell, the model isn't called again. When the cell finishes, only what the model needs to plan the next step comes back.
The second pillar is selective observation. Intermediate results produced while the code runs stay inside the runtime; they don't automatically barge into the conversation. If the model wants to see the scene, it has to call robo.show explicitly — only then does that image enter the context. Variables and helper functions stay alive across cells within an episode (a persistent namespace), so the model can reuse intermediate data in a later cell without ever piling it into the conversation.
The scene the paper walks through (Figure 2c) captures this nicely. In a task where a bowl has to be set down, a stretch that would take four model turns under tool calling (turns 14 through 17) is handled by PyRUA-Lean in a single cell. That cell computes the height to place the bowl directly from the scene's coordinate data (no action primitive hands it that value outright), lowers the bowl and opens the gripper when the condition is met, and requests an image only if the task isn't finished yet. On success, all that comes back is five lines of text — no image. Four round trips collapse into one.
The clever part is that this didn't create any genuinely new robot capability. PyRUA-Lean reuses RPent's robot stack and action implementations as-is, and the planning model is the very same GPT-6 Astra. The only thing that changed is the interface through which that capability is handed to the model. So this reads less like "a stronger model" and more like an experiment that gave the same model a better conversational channel.
Evaluation ran over 700 task instances in simulation. They took 40 tasks from LIBERO-PRO's four perturbed suites, 50 bimanual tasks from RoboTwin 2.0, and 50 tasks from RoboCasa365's Target50, each run across 5 environment seeds — yielding 700 pairs, or 1,400 episodes across the two agents.
Two numbers stand out. Under the same LLM-call budget, overall success rate rose from 63.1% to 71.7% (8.6 percentage points absolute, roughly 14% relative — the "14%" in the title is that relative figure). And looking only at instances both agents solved, PyRUA-Lean used 49% fewer LLM calls and 65% fewer input tokens. It raised the success rate while lowering the cost — notable, because those two usually trade off against each other.
As the authors trace it, the main source of the token savings is simply that the number of model calls dropped. Fewer calls means the context and images that rode along with each one shrink too. Per-episode cost in dollars for solved episodes was lower across every benchmark as well. What's interesting is that this efficiency held even without a VLA policy (a trained vision-language-action model) or an operating guide (RoboCasa365 has no guide at all). That means the savings come from the interface itself, not from some particular crutch.
A few things worth stating plainly. First, this is all simulation. The 700 are task instances in virtual environments, and this result alone can't settle whether the same gap would appear on real robot arms.
Second, the efficiency gain isn't the same size everywhere. The authors themselves note that on VLA-dominated tasks, the savings shrink. If a trained policy handles most of the motion in one shot, there just aren't many round trips left for code to bundle away.
Third, this interface leans on the assumption that the model can actually write decent code. The burden of computing coordinates and setting up conditionals shifts onto the model, and when the code is wrong, it throws an exception and has to be rewritten on the spot. The paper designed things so that even after an exception, the variables assigned up to that point survive in the namespace and can be recovered — but that also means the outcome rides on the model's coding ability.
Fourth, the comparison was run with cross-episode memory turned off on both sides. That's a deliberate choice for a fair interface comparison, but it also puts "which side benefits more once you accumulate and reuse experience" outside this experiment's scope. (The public excerpt doesn't include the concrete numbers on failure cases, so for that part you'll need to check Section 4.5 of the original.)
Picture an ONTLE AI PM handling a single customer request: "From the inventory system we've connected, pull just the items that are about to go out of stock and summarize them." It looks small, but the dependencies chain up. Check the connection is alive, pull the data, retry once if it comes back empty, filter down to only the items that dropped below the threshold, and turn that into a summary a person can read.
Build this the tool-calling way, and you tend to re-call the model at each step. "Connection confirmed, what's next?" "Data's in, what's next?" And in between, the raw responses (a hundreds-of-rows inventory table, say) pile straight into the conversation, driving up the tokens and cost of the next call. Even when a single request gets handled cleanly, the context gets messy and expensive.
The direction this paper points to is clear. For stretches where the decisions are obvious — "check connection → query → retry → filter" — don't ask the model one step at a time; bundle them into a single block of code that runs deterministically on the server. And when that block finishes, put into the context not the hundreds of raw rows but a result the PM can act on right away, like "7 items near stock-out, here's the list." When ONTLE redesigned the Park Seo-a PM, stripping away the "wide discretion where words and actions diverge" and running everything deterministically on the server atop a shared action service, that choice is exactly the direction this paper demonstrated with hard numbers in robotics. Use the model only to decide what to do; hand down how to do it as code. That's where the room opens up to cut calls and tokens together while holding the success rate steady.
One caveat rides along, though. Saying the efficiency comes from the interface means buying a stronger model to save tokens isn't the first move. What comes first is how you designed the channel the PM uses to handle a customer request.
No. The robot action implementations and the planning model (GPT-6 Astra) are kept identical to the RPent baseline; only the interface that exposes that capability to the model changed, from tool calling to Python code execution. It's closer to an experiment measuring how success rate and cost shift when you swap the channel while holding the ingredients fixed.
By the authors' tracing, the main source is the drop in the number of model calls. Condition checks and retries finish inside the code, so the model is called less, and fewer calls means the images and intermediate results that rode along with each call shrink too. On instances both agents solved, that was a 49% drop in calls and a 65% drop in input tokens.
No. The paper notes that on tasks where a trained VLA policy leads the work, the savings shrink, because there simply aren't many round trips left for code to bundle away. Conversely, the more a task requires repeated position-checking, moving, and recovery, the larger the gain.
The paper itself brings a thread from general agent research — the CodeAct line's idea that "composing tools in code is context-efficient" — over to robotics. The fact that the same principle held even on robots, where observations are images and failures are frequent, makes it directly relevant to designing work agents that stitch together many APIs.