Can LLMs Debug Robots by Editing Their Weights?

GPT-6 Astra repaired a class of robot instruction failures by editing 65 rows of a pretrained policy’s token embeddings. The editing process used simulator feedback, with no gradient updates and no new robot demonstrations. On held-out instructions containing the edited tokens, success rose from 74.3% to 87.5%. The success or failure of each of the other 430 episodes stayed unchanged.

The robot could turn on a stove. This wording made it pick up a plate.

The task is to turn on a stove. The policy knows the familiar instruction turn on the stove. But when the same goal is expressed as activate the cooking appliances heat source, it picks up a plate and fails to finish within 300 steps.

After the weight edit, the same policy completes the task at step 78. The scene, instruction, random seed, and initial state are identical. Only the submitted weight values have changed.

Inspect the recorded frames and terminal checks

This is a narrow but useful kind of repair: making an existing behavior accessible through a description that previously sent the policy in the wrong direction. We wanted to find out whether an LLM could construct that repair directly in the model’s weights—and whether the effect would survive instructions it had not received feedback on.

From weight-space programming to a robot policy

Takehi and colleagues’ Sparks of Weight-Space Programming explored whether an LLM can inspect and write neural-network weights directly. We bring that experimental question to pretrained robot policies. The distinction matters: a robot edit must improve a sequence of actions in a closed-loop environment, while preserving behavior that already works.^[2]

Our main result uses the released π₀.₅ LIBERO checkpoint from OpenPI. π₀.₅ builds on a pretrained vision–language–action policy; the starting model has already learned from robot data. Our claim concerns the editing stage: Astra receives the checkpoint, the task specification, a persistent Python tensor workspace, and a limited forward-tool budget. It can inspect tensors, write replacement values, and request simulator rollouts or fixed-input probes.^{[1], [3], [4], [5], [6]}

Each language session allows 50 budgeted tool requests. A request can contain many episodes or probe inputs. Astra proposes which rows to change, chooses destination vectors and mixing coefficients, and checks those choices against practice feedback. Held-out evaluation happens separately, after the candidate is frozen; those outcomes are not returned to the editor.

The first encouraging result was insufficient. On 80 difficult goal paraphrases, the original policy succeeded 49 times. An early edit later reached 69/80 on that diagnostic batch. A fresh batch then revealed eight repairs and six regressions. Astra revised ambiguous lexical mappings and produced candidate F: the 65-row edit eventually submitted by session C.

The replay below shows how that decision developed. It keeps the original task, the actual code, and every tool response. You can also switch to a failure-recovery search whose final decision was to withdraw the edit. Intermediate scores use different samples, so they should not be read as a training curve.

What changed inside those 65 rows?

The instruction is split into tokens. Each token selects a row from an embedding table, and the policy uses the resulting vectors to condition its actions. Astra edits selected rows so that unfamiliar wording points toward task expressions the policy already handles. Examples include cooker → stove, basin → bowl, and fermented → wine.

For the stove example, the ▁cooking row becomes a mixture of its original vector and the ▁stove vector. The exact coefficient comes from the released edit recipe:

The instruction text still says cooking; the downstream policy receives a different numerical representation. Actions continue to be computed by the original policy. This row is one part of the complete edit. We did not isolate its contribution with a single-row ablation.

65 rows does not mean 65 parameters or 65 lines of code. The C edit changes 132,768 scalar values, or 0.00367% of the exported 3.62-billion-parameter checkpoint. The rest of the checkpoint remains fixed. Unlike an adapter fine-tuning procedure such as LoRA, the editor writes the replacement values without gradient optimization.^[13]

The lookup gives the intervention a precise boundary. If an instruction never reads an edited row, its text embeddings are unchanged. With identical observations and sampling noise, the remaining fixed network computes the same outputs. Full closed-loop rollouts are still necessary to test whether the changed representations help.

Does the edit work beyond the examples used to construct it?

We ran three separate editing sessions, A, B, and C, starting from the same original checkpoint. Their frozen edits were evaluated on the same 765 held-out paraphrases. All three improved task success; C was the strongest.

For C, successes increased from 660 to 704 out of 765: 48 previously failing episodes were repaired, and four previously successful episodes regressed. Among the 335 instructions that read edited tokens, success increased from 249 to 293, or 74.3% to 87.5%. Among the other 430 episodes, every binary success/failure outcome stayed the same. This last observation does not assert that all closed-loop trajectories were numerically identical.

The paired C effect has exact p = 1.31 × 10⁻¹⁰; all three primary effects remain significant after Holm correction within that three-test family. An earlier 200-episode subset had not shown significant improvement. The later test evaluated the unchanged candidates on the full, pre-existing held-out split. It was not a preregistered independent replication. Additional seed checks used practice data and did not improve uniformly.

How much of this is a learned vocabulary correspondence?

A natural explanation is that much of the benefit comes from identifying useful lexical correspondences. We tested that explanation alongside a matched random-direction edit. The replacement control uses the correspondences Astra discovered, but moves each selected row all the way to its destination instead of using Astra’s per-row mixture.

The random-direction control did not improve success. Full replacement recovered much of the gain, which supports lexical alignment as an explanation. C’s direct advantage over full replacement was not significant at the 0.05 threshold (20 wins versus nine losses on 763 valid pairs; p = 0.0614). This experiment does not establish superiority over an independently designed human lexicon, prompt rewriting, or fine-tuning.

The result also connects to a broader literature on editing pretrained models, including ROME, MEMIT, and MEND. Those methods study how to change behavior through parameters. Here, the distinctive experimental object is an LLM-constructed edit evaluated through robot task execution. The evidence supports a targeted repair; it does not identify the complete causal pathway from language to action.^{[8], [9], [10]}

The searches that did not produce a reliable repair

We release all 16 robot editing sessions. Under the paper’s decision accounting, the three language sessions kept their edits and showed significant held-out gains. Of the other 13 searches, 12 declined a candidate. The sole suffix follow-up counted as retained had no significant held-out improvement (p = 0.542).

In a failure-recovery search, for example, Astra found a way to make the gripper reopen more often. That internal change did not improve the task: practice successes fell from 213 to 208 out of 352. The final decision was to withdraw the repair. The recovery tab above lets you inspect this search directly.^{[11], [12]}

This is evidence about the decisions made in these particular searches. It is not a validated general classifier of which robot failures are repairable. A correlated internal signal can be changed without fixing the behavior that matters.

Some withdrawn candidates remain in the archive because an early harness bug prevented final cleanup code from running. The bug has been fixed. A file remaining on disk is not evidence that the editor endorsed it; the final decision, artifact, and subsequent evaluation must be read together.

A separate finding: evaluation formatting can change the result

During the FastWAM experiments, we found that an instruction’s appended metadata could strongly affect task success. On 210 matched episodes, FastWAM scored 70.0% with task-only instructions and 48.6% when metadata suffixes were included. The evaluated π₀.₅ aggregate was 88.6% under both formats, with nine repairs and nine regressions.^[14]

An early archived suffix candidate improved one held-out result, but the editor requested withdrawal and follow-up searches did not confirm a reliable repair. We report the formatting sensitivity as a separate observation, not as the main successful edit. World-action models such as DreamZero and E0.5 provide related context; they were not tested for suffix sensitivity in this study.^{[15], [16]}

What this first release establishes

Our answer is specific: an LLM can inspect a pretrained robot policy and construct a small weight edit that improves a class of lexical instruction failures. The evidence combines explicit parameter changes, matched robot rollouts, held-out paraphrases, preservation checks, replacement controls, and the searches that failed.

Our interpretation is that the edit makes some existing behaviors easier to invoke through language. Learning a new motor skill, generalizing the repair across many held-out seeds, and transferring it to a physical robot remain open questions. The base policy was already trained, and the editor used simulator feedback. All released robot results come from simulation.