Improving the Newton MCP harness for simulation setup and tuning

The previous study showed that a live MCP makes photo-based calibration cheaper in tokens. This loop asks a broader question. Can the harness be tuned until it reliably helps on the setup and tuning work that earlier coding agents often failed at? The three tasks are rebuilt from earlier reports. One tunes a controller for reference-motion following (from the G1 whole-body-control report). One debugs a slipping grasp (from grasp-shake-drift and FeatherPGS). One calibrates a model against measurements from a real robot.

Each task starts from a runnable Newton example script with a realistic defect, together with a goal checked by a hidden verifier. The same agent (Claude Opus 5.5 in Claude Code, or GPT-6 Astra in Codex, both at xhigh effort) receives the same task in two conditions. In the MCP condition the script is already running live under python -m newton.mcp host. The agent can execute Python inside it, observe it, and reload the edited file, and it keeps its shell. In the no-MCP baseline it edits files and reruns scripts, so every run starts a fresh simulator process. Through h11, both trials of a pair started together on the same machine; from h12 they run one at a time, each from a fresh copy of the same compile-cache seed and inside its own sandbox. Budgets are 30 to 60 minutes depending on the task.

One iteration runs the pairs, reads the transcripts for friction (wasted turns, errors, source-code spelunking, redundant checks), and changes the harness. The change is committed as a new harness version, and the next iteration reruns the pairs. We report success, elapsed time (split into model and tool time), input and output tokens, API cost, and tool calls. Paired ratios below 1 favor the MCP.

Across 122 completed pairs, the MCP reduced elapsed time (geometric-mean ratio 0.87, 95% interval 0.81–0.94; faster in 77 pairs) and input tokens (0.98, 0.88–1.08; fewer in 66 pairs). Opus's API cost was 1.02× overall; GPT-6 Astra used fewer tokens in 39 of its 56 pairs (0.78×, 0.68–0.90). Of 246 verified trials, 228 passed. Three failures are iteration-6 Opus runs on the hard humanoid task; the other 6 are physical replays that failed the unseen episodes (3 with the MCP, 3 without).

The harness iterations moved these numbers. With h1, the MCP cost more tokens (1.19×) and saved little time (0.94×). h2 made it much cheaper for GPT-6 Astra (0.57× tokens, 0.69× time) but more expensive for Opus (1.63× tokens) through a tool-loading setting; h3 fixed that. With h3 (12 pairs, including second Opus replicates), the MCP was faster in 9 (0.76×, 0.60–0.94) and used fewer tokens in 8 (0.74×). With h4 (10 pairs, now including the grinding task), it was faster (0.80×), used fewer tokens (0.81×), and cut Opus's API cost to 0.78×. On G1 tracking, Opus took 220 s and $0.59 instead of 639 s and $1.16, and Astra 278 s and 0.44M tokens instead of 681 s and 1.7M. On grasp drift, Opus took 405 s and $1.20 instead of 698 s and $2.04.

The MCP did not win everywhere. On the SDF grinding task both conditions finished in about five minutes at similar cost. Astra's iteration-4 cube-toss MCP run used more tokens (2.3M vs 1.5M) after it broke its live session with the MuJoCo capture bug and spent turns restarting the host by hand, which drove the h5 changes. Iteration 5 (h5, 10 pairs) came out close to parity: 0.97× time and 0.94× tokens. Astra still saved tokens (0.71×), with G1 tracking at 273 s instead of 619 s. Opus's ratio rose to 1.24×, mainly because of two runs. In one grasp run, 900 of its 1,466 s went to a shell loop waiting on its own background fresh-process check (the MCP calls took 207 s). In one grinding run it chose more self-verification calls. Neither is a harness defect, but together they show how one agent-side detour can swing a five-pair iteration. Iteration 6 (h6) is running with two replicates of the harder humanoid task.

The hard humanoid task (iteration 6, h6). Gating the high5 clip changed the picture. GPT-6 Astra passed all four runs, with and without the MCP. Each time it wrote a whole-body inverse-dynamics balance controller from scratch, and it was faster and cheaper with the MCP in the first replicate (508 s and 0.9M tokens vs 719 s and 1.9M). Opus passed one of two runs with the MCP (root RMSE 3.3 cm, just inside the limit) and neither without it. The transcripts show why the Opus runs failed: they did not run out of ideas, but judged that their time was up. Three of the four Opus runs stopped after 11–16 minutes of a 60-minute budget, saying “I'm out of time to crack high5” or “Time's nearly up”; the one success also believed only ten minutes were left at minute 12. Agents see no wall clock, and a turn-heavy search seems to feel long to them. On the other iteration-6 tasks the MCP was faster or equal for both agents, and Astra's cube-toss run took 357 s and 0.54M tokens instead of 656 s and 2.5M.

Iteration 7 (h7): a clock for the agent. With the remaining budget in every MCP result and the start time in both prompts, all six pairs passed, and the MCP was faster in every one (0.64×, 0.51–0.80). On the hard humanoid task, Opus passed all three runs in both conditions. With the MCP it finished in 903–1,089 s; without it, in 1,370–1,669 s. Its token use and API cost were similar ($4.47 vs $4.18 per run on average), because the MCP runs used the time they now knew they had for more live experiments (up to 85 tool calls). Without the MCP, the agent now checked date -u and also kept working. Iteration-6's success gap therefore measured time awareness, not the MCP. On the other iteration-7 pairs, Opus's cube toss took 246 s and $0.44 instead of 611 s and $0.78, and Astra's grasp 229 s and 0.45M tokens instead of 388 s and 1.1M.

Verifier correction. Three iteration-7 hard-task runs first failed only on the unseen slower playback, with the robot upright but a joint RMSE of 0.14 rad. The G1 verifiers produced that playback by lowering motion.fps on an already-built example, so controllers that precompute a plan from their input clip (which the task allows) kept tracking a stale 30 fps plan. The verifiers now pass the time-scaled clip as an ordinary file through --motion. All 40 G1 submissions from every iteration were re-verified. Exactly those three changed (all to pass), and every other outcome, including the iteration-6 failures, stayed the same. The tables report the re-verified results.

Iteration 8 (h8). All eight pairs passed, and the MCP was faster in six (0.80×, 0.65–0.95), but Opus used more tokens (1.21×). Across the six hard-task pairs that ran with a clock (iterations 7–8), Opus passed every run in both conditions. With the MCP it averaged 1,039 s against 1,559 s, using 6.1M against 5.2M input tokens ($4.53 vs $4.21). The live loop makes each experiment cheaper in time, so Opus runs more of them: 54–87 tool calls with the MCP against 42–75 without. The visible clock has a similar side effect on easy tasks. After passing G1 tracking, one Opus MCP run noted “With time left, I'm briefly looking at why high5 falls (it's optional)” and spent 2.2M tokens against 0.9M without the MCP. The best real-robot model of the loop also came from an iteration-8 MCP run, at 0.092 rad on the 75 s held-out pendulum recording (the reference fit reached 0.131 rad).

Iteration 9 (h9): a real scene. All eight ABC station-twin runs passed, most with a wide margin (edge correlation 0.71–0.78, SSIM 0.68–0.71, color PSNR 19.2–20.4 dB against limits of 0.67, 0.64, and 17 dB), so the task does not separate the conditions. Time was mixed (0.86× overall): Opus took 796 s with the MCP and 1,540 s without in the first replicate, but 1,060 s and 749 s in the second, and Astra 1,841 s and 1,354 s, then 647 s and 1,154 s. The clearer signal is time to a first passing score on the given frames: Opus reached it after 401 s with the MCP and 1,131 s without; the restart run spent 600 s in a single camera-fit script, while the MCP run's longest fitting call took 40 s. Astra reached it at about the same time in both conditions (589 s and 646 s) and then kept refining for another 20 minutes with the MCP. Opus paid 1.35× more with the MCP, in more turns.

Iteration 10 (h10): calibrating a real arm. All eight ABC arm-replay runs passed, with held-out errors of 0.016–0.019 rad against a limit of 0.023 (the starter scores 0.0385 and the operator's reference fit 0.0212). The agents went beyond the reference: GPT-6 Astra fitted per-link gravity-compensation factors (1.09 on the upper links, 0.75 on the wrist) and a 21 ms command delay, validated on episodes it held out itself. The MCP was faster in two of four pairs (0.88× overall; Opus 634 s instead of 968 s in the second replicate, but 1,081 s against 1,065 s in the first). In this task about two thirds of each run is the same heavy batched rollout in both conditions (around 730 s of tool time in both Opus first-replicate runs), so a live session has little overhead to save.

Iteration 11 (h11): tuning a look in Blender. All eight ABC look-matching runs passed, most far inside the limits (per-region color error 4.3–24.1 against 33, color PSNR 19.5–20.8 dB against 18.5). Opus was clearly faster with the MCP: 379 and 334 s against 716 and 540 s (0.57×), at 0.69× the API cost. Astra took about as long in both conditions (708 and 869 s with the MCP, 647 and 876 s without) but matched the object colors much more closely with it (region error 6.6 and 5.2 against 24.1 and 18.3), and used 0.63× the input tokens. The agents did not use the MCP's built-in Blender backend. With the MCP they created the task's own Blender renderer inside the live session and kept it warm across turns. Without it, they ran the same renderer in scripts that started Blender afresh. The two best looks (Opus, both conditions) lit the white enclosure with a uniform white world, turned the directional lamps off, and calibrated one matte color per object, which beat the operator's reference look (region error 28.6). Two caveats: research agents of a parallel design workflow loaded the machine during this iteration, and one Astra MCP run was misclassified as an infrastructure failure because it printed the task file, which contains the token the runner looked for. It was rerun automatically; the original run, which ran concurrently with its partner, is the pair's trial, and the rerun (748 s, region error 7.6) is listed separately.

Each version is a commit on the Newton branch eric-heiden/newton-live-mcp, driven by what the previous iteration's transcripts showed.

h0 → h1. Iteration-0 agents wrote the same frame-by-frame evaluation loops in almost every call. They grepped the MuJoCo solver source to learn which contact parameters were in effect, and a missing import newton invalidated the scene. h1 added rollout(), solver_contacts(), health(), a preloaded newton, and non-invalidating errors for hosted scripts. It also added automatic CUDA-graph recapture after live attribute edits, and compiling reloaded scripts from source; a regression test had shown that a script edited within the same second could reload stale bytecode. Correction: an earlier version of this page said an iteration-0 agent's live shake-amplitude edit was silently ignored because it was baked into a captured graph. That was wrong: the example passes the amplitude to a kernel launched outside its graphs, so the edit took effect.

h1 → h2. In iteration 1, Astra's first call to solver_contacts() found the grasp's root cause directly: the fingers' higher geom priority imposes a soft material with a 0.2 s solref time constant on the cube. Opus still read solver source for the same fact; in h1 the helper was listed only in the server instructions, not in the task's host guide. MCP tool results were smaller than the no-MCP shell output (72k vs 110k characters on grasp drift), so the token overhead had to come from elsewhere. It came from about 2.4k tokens of tool schemas and instructions resent on every turn, and from about 10% more turns. h2 advertises only newton_execute and newton_rebuild with short instructions (about 0.8k tokens), names the deciding material in the contact report, lists the helpers in the host guide, and hosts two worker copies of the scene for parallel or background sweeps. To skip the tool-search round trip, it also set ENABLE_TOOL_SEARCH=false.

h2 → h3. Iteration 2 exposed three problems. (1) ENABLE_TOOL_SEARCH=false loads the schemas of every deferred built-in Claude Code tool, not just Newton's: Opus MCP trials started at 30k tokens instead of 15k. h3 marks only the Newton server alwaysLoad, which gives 14.9k with no tool-search round trip. (2) Checkpoints and resets restored every scalar attribute of the hosted example, so a look-ahead or gain the agent set before rollout(start=True) was silently reverted, and one sweep returned identical rows. h3 rewinds only the scalars that step() itself advances. (3) An Opus grasp session crashed with CUDA error 700 after live solver experiments. Reproducing it showed that h1's recapture was unsafe. Newton examples capture a graph around the solver's first step, and SolverMuJoCo allocates buffers during that step, so those buffers belong to the first graph. Recording a second graph around the same solver either segfaults or silently corrupts the simulation (a grasped cube ended 99 m below the table). A one-box scene fails the same way, and one eager step before the first capture avoids it. h3 recaptures only when example.solver has been replaced, which is safe. For other changes it reports that values inside the captured graphs keep their old values until a rebuild. recapture() refuses to run around the same solver. The grasp and G1 MCP trials of iterations 1 and 2 hit such recaptures (for example 10 times in the i2 Opus grasp trial). Their live numbers may have been corrupted, although their verified submissions were not affected.

h3 → h4. With h3, the MCP's first turn was still 2.5k tokens larger than the no-MCP baseline's. Part of that came from the host guide appearing twice: once in the task prompt and again in the server instructions. h4 adds --no-app-guide to the stdio bridge, and the harness uses it because its prompts carry the guide. Hosting was also extended to kinematic examples without a dynamics solver or second state (such as the grinding scene), and the host guide now says that non-array objects such as SDFs are not rewound by reset.

h4 → h5. Iteration 4 exposed three gaps. (1) Hosted examples run with a null viewer, so geometry an example draws itself in render(), such as the ground workpiece surface, was invisible to observe, and an agent plotted it with matplotlib instead. The host's viewer now records log_mesh calls, and color observations composite those meshes over the model's shapes by depth; auto-framing uses mesh bounds. (2) The MuJoCo capture bug struck again through ordinary task code. Astra called the task's own rollout() on the example's already-captured solver, and the live process could no longer allocate memory. An eager step on scratch states followed by solver.reset() prevents this even in the minimal repro, so the host process now warms every SolverMuJoCo this way; physics is unchanged (the grasp scene matches to seven digits). (3) With the CUDA context broken, the agent had to restart the host by hand. newton_rebuild(arguments={"restart": true}) now re-executes the host process, and the MCP client re-reads the connection file and retries when its server restarts. The host guide also recommends workers.map over submit for sweeps, because polling a future had cost an extra turn per sweep.

h5 → h6. The MuJoCo capture bug is now fixed where it originated. newton-physics/newton#4377 creates the solver's inverse shape mapping at construction instead of lazily inside the first (usually captured) step, with tests for discarded, retained, and replayed graphs. The loop branch merges that fix, drops the host's eager warm-up workaround, and goes back to re-recording an example's CUDA graphs after any cell that edits example attributes. As a result, kernel arguments baked into graphs pick up live changes again. With the fix, every earlier failing scenario (the one-box repro, and the grasp scene with its old graph dropped, retained, or replayed) now runs correctly.

h6 → h7. Because Opus misjudged elapsed time on the hard task, h7 gives MCP sessions a deadline (--deadline on the host, set by the harness to the trial budget), and every status in a tool result then includes time_left_s. To keep the comparison fair, both conditions' prompts now also state the task's UTC start time, so a script-only agent can check the clock with date; the MCP only makes the remaining time passive and ever-present.

h7 → h8. Profiling the long hard-task transcripts showed that newton_rebuild returned the full describe payload (application guide, operation list, limits; about 4.6k characters). One Opus run rebuilt 14 times, adding 65k characters that stayed in context for every later turn. Rebuild now returns a compact status of about 180 characters. h8 also carries the corrected G1 verifiers.

h11 → h12. Fair starts, a physical replay task, and new MCP camera tools. Both trials of a pair now start from the same per-task compile-cache seed (Warp, CUDA, GL, OptiX, and Mesa caches, built once by running the starter under every module name the conditions use) in fresh copies, inside a bubblewrap sandbox with a read-only home, private temporary directories, private CLI state, and the operator's histories, other trials, hidden data, and the study's harness code hidden; pairs run one trial at a time, and cleanup finds detached jobs through the sandbox's mount namespace. The MCP can mount a camera on a body (camera_body, e.g. a wrist camera with calibrated intrinsics) and project labeled markers of simulated points into simulated and recorded frames (overlay); contact markers now honor calibrated intrinsics. Newton fixes: MJCF fixed-joint chains are filtered like MuJoCo weld bodies (the YAM finger pads collided with their own wrist), and SensorTiledCamera renders convex hulls.

h12 → h13. Iteration 12 showed two sources of noise unrelated to the MCP. Which solver variant an agent happened to try decided minutes of its time: one MCP call that first tried MuJoCo's own contacts took 172 s, almost all of it compiling. The seed both conditions start from now also steps the starter with the elliptic cone and with MuJoCo's contacts, which brings that first use to 1.7 s. And one trial was ended by the API (“Selected model is at capacity”); the harness now records such endings and reruns the trial, which under one-at-a-time trials runs under the same conditions as its partner.

h13 → h14. The design study behind the next task found two MCP shortcomings, both now fixed. Filmstrips put every capture time in one row, and clients downscale images to about 1,568 px, so a 30-frame strip reached the agent at about 65×48 px per frame; filmstrips now wrap times into bands and pages sized for display and shrink frames only as far as needed. And only the MCP condition was told that Blender was available, although it is installed for both; both prompts now name both renderers, and the shared seed warms Blender's shader cache (first render 14 s cold, 1.4 s warm). The Blender backend also renders RealSense and OpenCV lenses now (it rejected them before), matching the sensor backend to within 0.5 px instead of 4–6 px at the image corners.

The system-identification task uses public measurements from the DFKI underactuated double pendulum (BSD-3-Clause). The robot has two quasi-direct-drive AK80-6 motors with 6:1 gearing, a 0.2 m first link, and a 0.3 m second link. Its fourteen design C.0 system-identification runs record measured joint angles, velocities, and motor torques. Runs 00–09 are given to the agent, while runs 10 (20 s excitation) and 11 (75 s, full swings, 300 Hz) are held out. The model replicates one pendulum per evaluation window as a separate Newton world, so a whole recording is evaluated in one batched SolverMuJoCo rollout (about 0.5 s on the study GPU).

The thresholds were set before any agent trial, from three reference parameter sets. The nominal starter misses badly. The published DFKI identification, mapped to a physically valid Newton model, roughly halves the error but does not pass. A direct Nelder–Mead fit of all twelve Newton parameters to runs 07–09 passes with margin. So the gates reward calibrating the simulator itself, beyond copying published numbers.

The agents solved this task quickly and in the same way in both conditions. They fitted the identifiable base parameters by linear least squares on inverse dynamics, then refined them with their own NumPy (Opus) or C++ (Astra) forward models under the multiple-shooting objective, and used Newton only to confirm. On a two-link system the simulator is not needed in the inner loop, so the live MCP has little to offer here. Its value should show on systems where the simulator is the only practical forward model, with contact or many degrees of freedom.

From iteration 3 a second real dataset is used where the simulator is the practical forward model: the ContactNets cube tosses (BSD-3-Clause), 570 hand tosses of an acrylic cube onto a wooden table tracked at 148 Hz (Pfrommer et al., CoRL 2020). The cube's size, mass, and inertia are measured and fixed. The agent calibrates contact behavior (friction, stiffness, damping, torsional friction, table height, solver settings) so that open-loop rollouts from each toss's first frame reproduce the recorded bounces, slides, and tumbles. Each toss is one Newton world, and a CUDA-graph rollout of all 400 training tosses takes about 2–4 s.

The thresholds were set before any agent trial. Published parameters do not transfer. The ContactNets friction coefficient with untuned stiffness halves the position error but leaves orientation unchanged. The MuJoCo fit of Acosta et al., mapped to Newton's contact model, is worse than friction alone, because stiffness and damping mean different things across simulators and timesteps. A Nelder–Mead fit of five Newton contact parameters on 200 training tosses passes with margin.

The loop so far measured tasks where a simulation is judged by numbers. The next phase targets tasks where the agent must also get the look right: modeling a real scene, such as the bimanual workcells of the ABC dataset, so that renders from a calibrated camera match real video, and then tuning its behavior against the recording. That puts the MCP's images under scrutiny, since a frontier model can only dial in what it can see.

A first audit of the h8 observations found three problems beyond plain aesthetics. (1) The MJCF importer hid every collision shape of a model that also has visual meshes, including world floor planes, which have no visual twin. The Unitree G1 therefore floated on a black void in every viewer and camera sensor. (2) MuJoCo's procedural checker textures were not imported, so such floors got an arbitrary palette color. (3) SensorTiledCamera always rendered every world. The MCP had to budget world count × width × height pixels to show one world, so in the 400-world cube-toss task, any observation above about 100 × 100 pixels was refused. All three are fixed in Newton itself, with regression tests. The camera sensor gained a world_ids option that renders only selected worlds; the 400-world scene now renders a supersampled 640 × 480 view in about 20 ms.

The observations themselves now supersample color 2×2 and resolve it in linear light on the GPU. They draw a sky gradient behind the scene and a checker of a reported round cell size (for example 0.25 m) on ground planes, which gives the model scale and motion cues. They fit the camera to the scene's projected extent rather than a loose bounding sphere. observe also accepts calibrated OpenCV intrinsics (focal lengths, principal point, distortion), so renders can be compared pixel for pixel with frames from a real camera.

Two heavier renderers were evaluated. Newton's ViewerRTX (the OVRTX path tracer) had broken with ovrtx 0.5, which renamed render variables and changed its DLPack interface, and it hung whenever a DISPLAY was set without a running X server. Both are fixed. It is now an optional MCP backend: observe(backend="rtx") renders the same camera and world with 16 path-traced samples in about 1 s per frame after a one-time scene export of about 20 s, against about 20 ms for the camera sensor. Blender 4.5 (Cycles on CUDA) renders a USD export of the same scene in about 5 s per frame.

In the research round's comparisons against real ABC frames, photographic rendering alone did not bring renders measurably closer to the real images. What mattered was a look the agent can tune (camera pose, light, colors) and a number to tune against. Two changes follow from that. The camera sensor gained ambient and light-color controls, and its lighting now follows the model's up axis; Y-up scenes used to be lit from below. The MCP workspace gained render() and compare_images(), which report PSNR, SSIM, and edge correlation against a reference frame and show mismatch, edge, or blend panels. A live Blender connection does not look necessary: USD export plus an optional RTX or Blender render covers the photographic case, and it keeps the agent's loop fast.

Replaying real ABC episodes in Newton turned up more importer and renderer gaps, now fixed with tests. MJCF geoms with zero alpha, such as the camera housings, rendered as opaque black and blocked the view of a camera pulled back by a fit. MuJoCo's binary .msh meshes, which the ABC scenes use, could not be loaded.

The first ABC task, the station twin (Table 1), starts from the nominal CAD model of the YAM station (Figure 3). The agent must fit the camera mount and the enclosure (the real one is narrower and deeper than the CAD), model the bin and the seven dishes on the table, and match the colors and lighting. The verifier renders five held-out frames between the given ones through the calibrated camera, with its own copy of the renderer, and scores them against the recording. Reference solutions set the thresholds. The starter scores 0.37 edge correlation, 0.53 SSIM, and 14.0 dB color PSNR. Fitting only the camera and the enclosure reaches 0.65, 0.63, and 15.1 dB. Adding the objects with fitted colors reaches 0.72, 0.66, and 18.2 dB. Iteration 9 runs this task in pairs, and its results will appear in Table 2.

Replaying the logs also exposed the real arm's controller. The measured torques fit a PD law on the command from one frame earlier (R² 0.82–0.98 on most joints), with gains of about 74 N m/rad on the large joints, against 40 in the ABC simulation model. This became the second ABC task, arm replay (Table 1), which iteration 10 runs in pairs.

The ABC tasks so far are building blocks: a fitted camera and station geometry (station twin), a calibrated arm controller (arm replay), and a tuned look (look matching). None of them yet asks whether the simulation physically reproduces an episode. The next ABC task replays a whole recorded episode with the arms driven by the recorded commands and requires the grasps and placements to work as in the video, verified over the entire rollout; it is being designed in a parallel workflow. Two general MCP tools were added for it: contacts_between(a, b), which reports per step how many contacts two shape sets have, the normal and friction force the solver applied, the slip speed, and the penetration (recordable over a rollout to tell a held object from one resting on the table), and a filmstrip that steps the simulation to recorded video times and scores each frame against the video through the real camera.

Blender as an MCP backend. The research round's Blender bridge is now an optional MCP backend. observe(backend='blender') renders with EEVEE ('blender_cycles' path-traces) through the same camera as the sensor, including calibrated intrinsics; object centroids agree with sensor renders to within 0.5 px. Newton stays the source of truth: one world is exported once to a long-running Blender process, and each render streams only shape and camera poses over a Unix socket (about 1 s per warm EEVEE frame on the shared GPU, 2–4 s at the real camera's 640 × 480 under load). A blender(code) helper runs bpy in the same process to edit materials, lights, and exposure. The backend is advertised only when Blender is installed. Figure 4 shows what it does and does not buy on the ABC twin.

The physical replay task. A survey of all 40 public ABC validation episodes chose place and organize the fake fruits in the fruit bowl (episode 7067ee1f). It lasts 9.4 s, with three separate grasp, lift, carry, and release events across both arms and no handovers. Ten more recordings of the same station, made minutes apart with the same fruits in other layouts, give held-out episodes that the agent never sees. Ground truth for the whole episode comes from the video: a top camera fitted to rendered robot outlines, color tracking gated by the robot's rendered silhouette, and the fruit following the gripper while held. A scorer built on it passes the true trajectory and fails every injected fault (no grasp, mid-carry drop, 5-frame lag, 2 cm noise, 1 cm bias).

A prototype shows that the replay works physically in Newton. The arms are driven only by the recorded commands, through position control with gains calibrated from the arm logs, and the fruits are free rigid bodies with real contacts. All three fruits are grasped, lifted, carried, and placed into the tray, and a second agent reproduced this in fresh runs and ensembles and found no hidden attachment. It also takes the right settings: grasps fail with MuJoCo's default pyramidal friction cone; the pear grasp only works with arm gravity compensation between about 0.7 and 0.875, because the simulated fingertips must reach below the fruit's equator; and the orange's 9 cm roll after release appears only with low rolling friction. Those are the things the agent has to discover. The starter, with the ABC simulator's defaults, holds none of the fruits.

Building the replay found two Newton bugs, both fixed with regression tests. The MJCF importer filtered collisions only between a joint's direct parent and child, not between bodies joined by fixed joints as MuJoCo does. As a result, the YAM gripper's finger pads collided with their own wrist and jammed the gripper half open, so every grasp failed under Newton's collision pipeline (e2bc4c6f). Separately, SensorTiledCamera did not draw convex-hull shapes (40d7e334). The verification also corrected two early claims. A contact-buffer overflow came from the prototype's own fixed limits, not from Newton's defaults, and Newton's automatic sizing handles the default contact gap. Deterministic mode works (SolverMuJoCo(deterministic=RUN_TO_RUN, disable_sensors=True)), so replays can be scored reproducibly.

The replay task is built and calibrated. The agent gets the main episode at about 30 Hz with its top and wrist videos, four more 10 fps recordings of the same station (fruit starts placed where the arm kinematics put the fingers at each real grasp, tray pose fitted to the first frame), 64 YAM arm logs for calibrating the arms, and fixed helpers for replaying, scoring, rendering through the real cameras, and summarizing contacts. The starter keeps the ABC simulator's defaults and holds no fruit. The hidden verifier imports only the submission's model, solver, and pipeline builders and runs its own replay of whole episodes in one batch of 44 worlds: the main episode 8 times (6 with jittered fruit starts), six unseen episodes 4 times each, the four training episodes twice (report only), and two negative controls in which the gripper never closes or all friction is 0.02, where no fruit may rise more than 1 cm. Thresholds follow a fixed rule from repeated reference and starter runs. The reference passes every fresh run, holding and placing 53–54 of 56 gated fruit copies on the unseen episodes, against 7 for the starter.

Two calibration choices needed judgment. One unseen pear is excluded: the real robot gripped it at the farthest reach in the data (0.58 m; the agent's episodes reach 0.55 m), and its gripper opening of 52 mm, the pear's full width, shows it was gripped at its widest point, while the recorded arm kinematics put the fingertips 31 mm above the pear's centre. No model calibrated on the agent's data can know how far the arm sagged there. The other two fruits of that episode stay gated. The unseen-episode arm-tracking limit is 0.0308 rad, without the rule's usual cap at 0.7 times the starter's error: with the cap it sat within 3% of the reference, and an audit found honest calibrations whose unseen-episode error runs up to 1.2 times their main-episode error.

Adversarial review hardened the verifier. Thirty-three cheat submissions (hidden welds, gravity compensation, drives, or springs on the fruit, extreme friction or adhesion, kinematic or oversized fruit, scripted motion, patched solvers or scorers, extra shapes on the hand, tray shelves, forged results) all fail. Eighteen more push allowed settings to their limits (contact gap, rolling friction, restitution, a sunken centre of mass, tray wedges); they pass only where the grasp itself still works and fail as soon as it is weakened. A separate fairness review did find one way to pass: the verifier runs the submission in its own process, so a 25-line build_model could read the run's authentication token from the call stack, write a passing result, and exit. The verifier now blocks frame, garbage-collector, raw-memory and code-object introspection, process spawning, and reads of hidden data by any code outside the standard library, the environment, Newton, and the verifier itself (a Python audit hook that cannot be removed); it rejects sources that use such names before importing them; and the parent process, which never imports the submission, recomputes every gate from the reported metrics. An in-process verifier still cannot be made airtight, so every trial is also scanned for introspection in the submission and for network downloads in the transcript, and flagged trials are reviewed by hand.

Iteration 12 (h12, four pairs, trials run one at a time). Six of eight runs reproduced the episode physically. Both Opus agents of the first pair found the same causes: MuJoCo's default soft contact, whose stiffness scales with the light fruit's mass, let the fingers sink through the fruit; the arms need per-arm drives fitted to the logged torques and only partial gravity compensation to sag like the real ones; and the grasps need an elliptic friction cone. Opus passed all four runs. With the MCP it took 0.72× the time (2,136 instead of 2,563 s, and 1,346 instead of 2,147 s) at 0.94× the cost; model time was about the same within each pair, and the MCP runs spent 447 and 717 s less in tools. The first MCP run's 1.3× input tokens came from more, shorter turns (229 instead of 184 requests at the same mean context), not from larger tool results. GPT-6 Astra took a different route in all four runs, MuJoCo's own contacts with an elliptic cone, and tracked the arms more closely than the reference (0.009–0.020 rad against 0.021). It passed one run per condition. Both failures stopped early, after 18 and 21 of 60 minutes, confident from the supplied episodes. Without the MCP, the replay lost every copy of one unseen episode that the reference holds (45 of 56). With the MCP, two copies of another unseen episode diverged numerically, and one copy squeezed the dark fruit 1.5 cm upward in the low-friction control (48 of 56). The unseen episodes and the negative controls did what they were built for: they separated replays that work from replays tuned to the episodes at hand. Full replays take seconds in both conditions, so the live session saves less here than on setup-heavy tasks.

Iteration 13 (h13, four pairs). With MuJoCo's contacts precompiled, the first Opus pair passed in both conditions: 1,188 s with the MCP against 2,199 s without (0.54×), with 53 and all 56 unseen fruit copies held and placed. The MCP run cost more, $6.18 against $4.59: it took 231 requests instead of 146. A faster loop invited more and shorter turns here and in the first iteration-12 pair (229 against 184), though not in the second (163 against 177). Its tool time was 324 s against 1,388 s; model time was about the same (858 and 811 s). The first GPT-6 Astra pair also passed in both conditions (52 and 54 of 56 unseen copies), and here the MCP did not help: 1,721 s against 1,472 s. Astra again did most of its work in the shell (91 other tool calls next to 25 MCP calls), its tool time was about the same in both conditions (467 and 429 s), and the MCP run spent longer thinking (1,247 against 1,042 s). The second Opus pair failed in both conditions, each one copy short of the unseen-episode gate (49 of 56) and on different episodes, after replays that passed every supplied episode. Here the MCP run was not faster (1,734 against 1,664 s) and cost 1.8× as much ($6.56 against $3.61): it made 239 requests instead of 110 and spent 1,064 s thinking against 580 s. In the second Astra pair, the MCP run failed the unseen episodes (47 of 56) after 1,264 s and the run without it passed (52 of 56) after 1,490 s. Over the eight replay pairs of iterations 12 and 13, success did not depend on the MCP: 5 of 8 runs passed with it and 6 of 8 without, and every failure was a replay that worked on all supplied episodes but not on the unseen ones. For Opus the MCP cut tool time to 0.46× but raised model time to 1.15× and input tokens to 1.45× (time 0.74×, cost 1.21×); for GPT-6 Astra, which ran most experiments as fresh processes from its shell either way, time (1.03×) and tokens (0.98×) were unchanged.

Choosing the next replay task. A design study with seven agents tested two candidates against the evidence. (A) A physical replay of “put the screwdriver in the bin” is feasible: an honest configuration (the gripper's real 50 N pinch, which the ABC simulator replaces by a 2.5 N pinch and inflated friction, plus stiff contacts) places it in 16 of 16 copies, and a public mirror holds 56 recordings of the same station, bin, and screwdriver. But as first proposed its gates did not reward physics: a weak grip with a fitted arm was held and placed as often as the honest one. (B) Scoring the fruit replay's look over the whole video failed outright: a flat colour per region, fitted in 7 s without looking at a single image, scored as well as the best tuned look, Blender scored lowest, the station looks the same in every episode, and a backplate photo beat honest physics on whole-frame metrics. The study therefore chose a redesigned (A): the decisive gate becomes in-hand rotation during the carry, which the real wrist videos fix (the real grasp is rigid in all 56 recordings) and which separates grip models cleanly (1.7° for the honest grip, 14.9° for the fruit task's fix, 36.5° for a one-line fix). Its stated expectation is a replication of the fruit result in a new physics regime, not an MCP advantage; a real MCP time effect would need a long episode where rewinding to a failing grasp saves tens of seconds. The same study found that MCP filmstrips were illegible in practice (a 30-frame strip reached the agent at about 65×48 px per frame) and that only the MCP prompt named Blender; h14 pages filmstrips to the displayed size and names both renderers in both prompts.

The screwdriver task is built. A build workflow of eight agents prepared the main episode, 4 training and 12 unseen recordings (chosen from 57 for verdicts that stay the same under six ways of constructing the ground truth: time step, bin floor, base correction, a cylindrical instead of tapered handle, bin position, and start yaw), a tapered handle fitted to how the measured grip width varies with grasp height across the 56 recordings (r = −0.93), the starter, a reference, and a copy of the hardened verifier with screwdriver, bin, pinch, stiffness, and material audits. Two design choices came from its measurements: the in-hand window ends before the gripper is commanded open (otherwise an honest command delay failed it), and each scene starts the screwdriver where it lay before the fingers pushed it (which cut the reference's finger-gap error from 4 to 0.8 mm). The held-out rate threshold is 0.9 rather than the calibration rule's 47 of 48, because the reference passes every copy and the rule left honest variants at the edge of noise; it still rejects the fruit-task fix (0.67) and a 10 N grip (0.75). Every one of 35 cheats and forgeries fails. An adversarial agent found one family of in-bounds settings that passes: a 20 N grip with soft contacts and the largest allowed torsional friction patch; it reproduces the rigid carry on unseen episodes, so the verifier, which can only check what is observable, accepts it. A second variant that also moved the centre of mass toward the grasp is now rejected by a bound on the centre of mass. The build also found an upstream MuJoCo Warp issue: with the default pyramidal friction cone, condim 6 contacts turn NaN in the first step at friction 0.002 (MuJoCo C stays finite); the goal text discloses that the starter's low-friction control diverges for this reason.

Iteration 14 (h14, the screwdriver task, four pairs). In the first Opus pair, both agents read the real clamping force off the gripper motor's logged effort (about 47–50 N per pad), stiffened the finger contacts, switched to the elliptic friction cone, and fitted per-joint arm gains and partial gravity compensation, and both replays passed every check they could run locally on the main episode and the four training episodes. With the MCP, Opus kept going for 971 s ($3.83) and its replay held, placed, and kept rigid all 48 unseen copies. Without it, Opus stopped after 444 s ($1.98) with a replay that lost every copy of one unseen episode and one copy of two others (42 of 48, under the 90% gate). The first GPT-6 Astra pair passed in both conditions, 1,209 s with the MCP and 1,331 s without (0.958 and 0.917 of unseen copies). In the second Opus pair both runs passed: 489 s with the MCP and 673 s without (0.958 and 0.917 of unseen copies). In the second Astra pair both runs passed again, but the MCP run took longer: 1,881 s against 1,345 s (0.979 and 1.0 of unseen copies). Over the four pairs, 4 of 4 MCP runs and 3 of 4 runs without it passed; the MCP took 1.19× the time, mostly because the one failing run without it stopped after seven minutes.

What agents use from the MCP. Across the 92 MCP-condition trials of iterations 0–14, agents made 1,998 MCP calls: 1,763 newton_execute (88%), 225 newton_rebuild, 8 newton_describe, and 2 calls of the structured filmstrip tool. Everything happened in Python cells inside the live session. The table counts the cells that used each helper and the trials in which it appeared at least once. Stepping and recording (rollout), live edits of model arrays and example attributes, reset, and the diagnostics (health, solver_contacts) carried most of the work; parallel worker sweeps appeared in about a quarter of the trials and checkpoints in about a fifth. Image tools were rare: observe in 11 trials, filmstrip in 8, compare_images never.

The live session did not replace the shell. MCP-condition agents still ran 426 scripts as fresh processes (1,424 without the MCP), edited files from the shell 450 times (1,246), and read Newton's source with grep, cat, or sed 864 times (1,914). Reading source was the most frequent single activity in both conditions, and about ten of the 59 failed MCP calls came from guessed API names (attributes that were renamed or never existed). Opus made 27 MCP and 12 shell calls per MCP trial; GPT-6 Astra 15 and 26.

Where the remaining time goes. A pass over all 184 transcripts (92 per condition) measured how MCP-condition agents spend their time: half in newton_execute cells, 27% in fresh-process runs of their own scripts, 14% editing files, and 7% reading Newton source. Agents trust a clean process for their final checks, but no tool runs one, so they wrote harnesses, polled logs, and in one run waited 949 s on runs that printed nothing. MCP agents also spent more time editing files than restart agents (90 s against 61 s per trial), because they retyped into the script what they had developed in cells. Edits that the solver silently ignores, such as MuJoCo actuator gains on actuators driven by joint targets, led several agents to wrong physical conclusions. Packing candidates as the worlds of one model evaluated 10–50× more candidates per second than one rollout per candidate, but agents found this by accident and rebuilt it by hand each time. Newton's functions for Jacobians, mass matrices, inverse dynamics, inverse kinematics, and per-world attribute edits were used in none of the 184 trials; agents called MuJoCo's CPU API in 32 trials instead.

Changes in h15. The Blender backend is removed from the MCP again: agents fitted looks from scores rather than renders, and a tuned Blender look matched real frames no better than the tuned sensor. Dictionary-valued rollout() probes such as contacts_between are now also returned as nested dictionaries, after three agents lost a turn indexing them. An error in agent code now rolls the simulation back to its state before the cell instead of leaving the session invalid, and a failed rebuild keeps the previous scene running. Rebuilds accept overrides of the script's constants. persist() and persist_source() write a live value, function, or class back into the script and check that the rebuilt scene reproduces it. Workers accept Python functions, follow rebuilds, restart after crashes, and run background jobs. fresh() runs the saved script in clean processes through a new headless Newton runner, python -m newton.examples.headless. solver_params() and a check after every cell report which values the solver actually reads and flag model edits that no notify_model_changed call applied. compare_images, rollout(plot=...), and the structured operations, which no agent used, are gone, and the guide states only what each tool does. The headless runner and the solver and health reports are public Newton utilities, and both conditions' prompts name them. Capabilities that would help agents without the MCP as much (batched candidates, whole-body kinematics, calibrated-camera geometry) belong in Newton itself, and their order depends on what the clean-plate tasks below show.

Broader tasks. Every task so far started from a scene that already existed in Newton, with assets and solver in place, so agents only tuned it. Two new tasks start from a nearly clean plate. In abc_scratch, the agent gets a handful of photos of the fruit-bowl episode, the robot's logs, the camera calibration, and the station's robot model without any objects, and has to recreate the objects, tray, and physics so that a replay grasps and places them as in the recording. In g1_mpc, the agent gets the G1 humanoid, three reference clips, and a plain PD baseline that falls, and has to develop a tracking controller, investigating model predictive control, verified on the given clips and two unseen ones. Both are built and audited: in each, a private reference solution passes the hidden verifier and the starter fails it, and dozens of shortcut probes fail. Iteration 15 runs both tasks with h15, one trial at a time, with 90-minute budgets.

Results on the clean-plate tasks (iteration 15). Eight pairs: two runs per task and model, with the order of the conditions swapped between them. On the G1 controller every run passed, and the MCP was faster in all four pairs (0.77–0.94×). Every agent built a model-based controller from scratch: both Opus runs wrote a sampling MPC (MPPI) that simulates 512 copies of the robot half a second ahead on the GPU every 10 ms, and GPT-6 Astra optimized each clip offline while the controller is built and tracked it with a short-horizon nonlinear MPC or ran a full-body iLQR MPC. On the scene from photos, 2 of 4 MCP runs and 3 of 4 restart runs passed, and time went both ways (0.54× to 1.94×). The second runs failed on margins and stated rules rather than on missing capability: an orange that came to rest about 5 cm from the real one in half of the copies (Opus, MCP), a tray drawn 4.3–4.7 cm past the real outline where 4 cm is allowed (Opus, restart), and a pear that rose 10.3 mm in the low-friction control where 10 mm is allowed, after the agent's own copy of the check had measured under 5 mm (GPT-6 Astra, MCP). Pooled over the iteration the MCP took 0.96× the time of restart, and Opus's cost was 1.17×. With one or two runs per cell, the spread between replicates is as large as the MCP effect on the scene task, so iteration 16 runs three replicates and measures time to first pass from workspace snapshots.

What the first half shows. A transcript analysis of the first eight runs (checked line by line by a second pass) finds that the MCP's advantage still comes from the live Python session itself: agents benchmarked a batched planner in the session before writing it into the file, found a planner/plant mismatch with a live probe, and toggled negative controls with one-line live edits instead of patch files. Most h15 additions went unused: fresh(), persist(), workers, background jobs, swap_solver, and diff_model had no uses, and the headless runner named in both prompts was used in none of the eight runs; agents again wrote their own copy of the verifier. h15 also cost about 215 s over the four MCP runs: two idle workers that the prompt never mentioned were rebuilt with every rebuild (119 s), a reset did not rewind the example's clock when cells stepped the example directly, a cell variable named result was taken as the return value, and a rollback missed a method the agent had rebound. All four tasks finished with margin (worst verified metrics at 0.30–0.79 of their limits), so pass rates cannot separate the conditions here. The clean-plate runs are 3.4–3.9× longer than the earlier tuning tasks, and most of the time goes into writing scene and controller code: abc_scratch is bound by thinking (tools blocked the agent 14% of the time with the MCP and 35% without), g1_mpc by simulation (65% and 69%). Six of eight runs used MuJoCo on the CPU and hand-wrote the same Newton↔MuJoCo state conversions, and all four scene runs hand-wrote pixel-to-world geometry.

Next (h16, being built). MCP fixes for everything above (workers start only when used, reset rewinds the clock, notes only for edits no notify call covered, rollback names rebound methods, the result trap removed, unused tools dropped from the guide). Newton capability for both conditions: running many candidates as the worlds of one model with per-world edits by label, a public Newton↔MuJoCo state bridge with a page on model-based control conventions, calibrated-camera projection and unprojection, label-to-index lookup, and cleaner health and solver reports. The branch also merges upstream Newton, so the MCP renders with the new SensorCamera. For measurement, the harness will copy each workspace every five minutes, out of the agent's view, and verify the copies after the iteration, so time to first pass becomes a measured outcome; iteration 16 runs three replicates per task, model, and condition.

Frontier agents solve these setup, tuning, and capability tasks with or without the MCP, once they know how much time they have. 228 of 246 verified trials passed. Three failures were Opus runs on the hard humanoid task that stopped far too early. The other 6 were physical replays (3 with the MCP, 3 without) that passed every supplied episode but not the unseen ones. After the harness began reporting remaining time, all twelve later runs of that task passed.

Harness details decide whether the MCP saves or costs tokens. The same live session went from 1.19× input tokens (h1) to 0.74–0.81× (h3–h4) through changes in how tools are advertised and loaded, what the helpers return, and how resets behave. One setting pushed Opus to 1.63× before it was reverted. Per-turn fixed context and extra turns explain the overhead, not tool output.

The MCP reliably saves wall-clock time; whether it saves tokens depends on how the agent spends that time. Across all pairs it was faster in 77 of 122 (0.87×), and on the long hard task by about a third. GPT-6 Astra turned the faster loop into fewer tokens (0.70×). Opus tends to turn it into more experiments, especially on long or open-ended tasks (1.10× tokens overall, but 0.97× API cost thanks to prompt caching).

Agents need a clock, and a clock changes their behavior. On the one task that required a long search, Opus repeatedly stopped after 11–16 of its 60 minutes because it believed its budget was spent. Reporting the remaining time with every MCP result, and stating the start time in the prompt, fixed that in both conditions, and all twelve later runs passed. The same visibility leads agents to spend spare budget on optional goals after passing. A harness can supply the clock, but only the task can say whether the spare time is worth spending.

For modeling a real scene, a score beats a prettier picture. Given a renderer that matches the verifier and a scoring function, none of the eight station-twin runs called observe, the RTX backend, or compare_images; every agent fitted the camera, geometry, and colors in loops over the score and looked at its own composites with show(). In a controlled comparison on the same twin and frames, Blender EEVEE with tuned exposure and per-object colors reached 18.6 dB color PSNR, 0.65 SSIM, and 0.69 edge correlation, against 18.2 dB, 0.66, and 0.72 for the tuned sensor. Untuned, Blender scored 14.5 dB, and exposure alone recovered 3.9 dB. Photographic rendering helps people judge a scene, but for agents fitting to real frames the gains come from tunable look parameters and a metric. The Blender look task confirmed this from the other side: agents kept the task's renderer warm in the live session rather than calling the MCP's Blender backend, and the MCP's gain came from that persistent process (Opus 0.57× time) and from more iterations at the same cost (Astra's object colors).

A live session saves overhead, not compute. When each experiment is dominated by setup, restarts, or inspection (G1 tracking, the station twin for Opus), the MCP saved a third or more of the time. When each experiment is a heavy batched simulation that costs the same in both conditions (the arm calibration), the times were close. The harness can only remove the per-experiment overhead.

On a physical replay, the MCP saved waiting but not thinking, and did not raise success. When a full replay takes seconds in a fresh process, the live session has little overhead to remove. Over twelve pairs on two replay tasks, 9 of 12 runs passed in each condition. Opus spent 0.60× as much time in tools with the MCP but used the faster loop for more and shorter turns (thinking time 1.23×), so it finished in 0.88× the time at 1.25× the cost; GPT-6 Astra worked from its shell in both conditions and saw no change (1.06×). What decided success was generalization: every one of the six failed replays passed all supplied episodes and lost unseen ones, in both conditions, and all six stopped with more than half of the hour left.

Given a numeric scorer, agents do not look at the simulation. In the eight screwdriver runs, after h14 had made filmstrips legible, given Blender the real camera lenses, and told both conditions about it, not one image reached an agent's context; a single run rendered the wrist and top views to files once. Agents read the decisive behavior (does the screwdriver turn in the fingers?) from the score the task provides, and the real-world information they needed (start poses, bin, timing) came as numbers in the scene files. Better rendering pays off only where the decisive information exists only as pixels, which these tasks, by design, never required.

Fair conditions take more than separate kernel caches. An audit of the harness, and an adversarial review of the fix with 36 agents, found these asymmetries and leaks:

• With per-trial caches, the MCP host compiled the starter's kernels before the agent started, outside its budget, while the restart agent paid the same compile inside its budget (27–95 s).
• The stated start time preceded host startup.
• Trials inherited the operator session's environment, including a cross-session messaging socket. Claude, but not Codex, loaded a home-directory AGENTS.md.
• Trials shared /tmp and could read harness records, including the condition label, as well as hidden verification data and the operator's CLI history, which named held-out scores.
• Concurrent trials could read each other's command lines, and in iteration 9 one agent did see the other model's fitting script.
• Detached jobs outlived trials.
• A run that used the MCP 38 times was misclassified as having no MCP tools, because it printed the prompt.

• Both conditions start from one compile-cache seed per task.
• A barrier starts both agents together.
• A sandbox gives each trial a private /tmp, a read-only home directory and tools, and hidden study data.
• The environment is scrubbed, and Claude cannot use cross-session tools.
• Cleanup kills leftover processes by trial and by sandbox namespace.
• Options reach the runner through hidden spec files.
• Timing-sensitive trials run one at a time.

A live session needs guards that a restart workflow gets for free. Three silent-divergence bugs surfaced only through agent use: settings reverted by reset, stale bytecode after a quick edit, and memory corruption from recapturing a CUDA graph around a warm solver. A live harness is only as trustworthy as its bookkeeping, and each fix has a regression test.

The MuJoCo capture issue was a Newton bug, now fixed at the source. SolverMuJoCo created a persistent mapping lazily inside its first step. Newton examples capture that step in a CUDA graph, and any second capture around the same solver then crashed or corrupted the simulation, on upstream main as well (repro in Section 9). newton-physics/newton#4377 creates the mapping at construction. Live tooling found this bug because it re-records graphs in ways that one-shot scripts never do.

Agent use surfaced more Newton bugs, now reported and fixed upstream. Beyond the capture bug, the trials and the task building hit thirteen Newton issues, filed as newton-physics/newton#4445–#4457. For example, MJCF bodies attached without a joint collided with their own wrist and jammed a gripper, floors vanished from imported MuJoCo scenes, the camera sensor skipped convex hulls and the back of cloth, heightfields rendered with holes, and ViewerRTX failed with the current ovrtx release. Ten pull requests with regression tests fix ten of them (#4458–#4467); the camera fixes target the new SensorCamera.

Explaining effective solver parameters saves investigation. Where an agent used the contact report, it found the grasp's root cause (finger priority overriding the cube's material) in its first call. Agents without it read solver kernels to reconstruct the same fact.

Verifiers need the same scrutiny as the harness. A G1 verifier changed the playback rate after construction and silently failed controllers that precompute a plan. It was caught only because an agent claimed to pass all clips and the verification disagreed. Re-verifying all 40 G1 submissions changed exactly the three affected outcomes.

This is an exploratory loop, not a registered study. The harness changes between iterations, three to seven pairs per agent and iteration cannot separate small effects from noise, and tasks are added as the loop goes. All pairs ran on one shared 4-CPU machine with a MIG GPU slice. Concurrent pairs control for load between conditions but not across iterations, and reference fits sometimes ran during trials.

Iteration 0 has no Astra trials. One iteration-1 Astra G1 pair was excluded because the operator accidentally terminated its live host while testing workers; it was rerun with the same harness. Live results in some iteration-1 and iteration-2 MCP trials may have been corrupted by the recapture bug described in Section 3; their verified submissions were not. Codex does not report API cost. Because every task so far is solvable in both conditions, these results say nothing yet about whether the MCP raises success on harder problems. Agent-side detours, such as a shell loop waiting on the agent's own background job, can dominate a single pair's time; they are kept in all aggregates.

Two harness properties change in h11. Through h10, all trials shared one Warp kernel cache and one CUDA JIT cache, so a condition could reuse kernels that the other condition, or an earlier trial, had already compiled. From h11, every trial compiles into its own empty caches. From h7 to h10, the MCP also reported the remaining task budget (time_left_s) in every result, while the restart condition saw only the start time in its prompt. That clock helped Opus finish the hard humanoid task, but it is a task-level aid rather than a simulation tool, so from h11 the MCP no longer reports time and both conditions get the same start time and budget in the prompt. Comparisons across that boundary should be read with this in mind.

Iteration 11 ran while research agents of a parallel design workflow used the same CPUs and GPU slice, so its absolute times are inflated and noisier than earlier iterations; pairs still ran concurrently.

The arm-replay starter script (iteration 10) had a race in its CUDA-graph rollout: a kernel read and advanced its step counter in the same launch. This left some recorded rows at zero and inflated the error that agents computed with the starter's own evaluate(). The verifier used its own host-stepped rollout, so the verified results are unaffected, but agents' in-session estimates were noisier than they should have been. The race is fixed (d3d14e48).

Through h11, conditions also differed in ways the audit found only later (see Findings): uncharged MCP host startup, inherited environment and messaging tools, a shared /tmp, readable operator history, and visible partner command lines. None of these is known to have changed an outcome, but iterations 1–11 should be read as run under looser isolation than later ones.

One iteration-12 trial (GPT-6 Astra without the MCP, second pair) was ended by the API (“Selected model is at capacity”) after 18 minutes and was rerun; its first attempt is kept in the records. Because every h12 trial runs alone on an idle machine, the rerun ran under the same conditions as its partner, and the pair is included. From h13 the harness detects such API failures and reruns the trial automatically.

Newton branch eric-heiden/newton-live-mcp: the MCP host and helpers are in newton/_src/mcp, and the loop harness, tasks, and verifiers in tools/mcp_evaluation/v4 (run_v4.py; dp_real/prepare_data.py, cube_toss/prepare_data.py, abc_twin/prepare_data.py, and abc_arm/prepare_data.py rebuild the data files from the public datasets; the ABC tasks use the ungated Voxel51 MCAP mirror of ABC-130k, Apache-2.0). Trial data: loop.json (every trial's metrics and paired ratios) and data/v4/loop-transcripts-iN.zip (one archive per iteration, for example loop-transcripts-i9.zip; prompts, specs, summaries, verifications, submitted scripts, agent transcripts, and host logs, with loopback tokens redacted). CUDA-graph recapture repro: mujoco_recapture_repro.py.