By Sarah Xiao 
At an internal Unitree test in October, a robot was set to painting. According to founder Wang Xingxing, it changed colours by itself and cleaned its brush between strokes — behaviour nobody on the team had written code for. Ten days earlier he had said something larger: that GPT-7 might “punch through” the embodied intelligence problem.
In the same month, Physical Intelligence and Dream Labs both opened robot-model APIs, and Google and NVIDIA published work in which general models participate in robot development rather than just controlling robots. Read together, these are not four announcements about the same thing.
What changed is not that large models can control robots. What changed is where capability comes from, how training work is divided between model providers and robot teams, and how the R&D loop itself runs. Each of those shifts is real, measurable, and — this is the part worth being careful about — only partly demonstrated.
One model, two tasks, a factor of ten
The cleanest evidence that a general model now supplies usable manipulation skill is also the least flattering.
Robocurve ran GPT-6 Astra on a YAM arm. Placing blocks into a bowl succeeded 19 times out of 20, at an average of 2.5 minutes per attempt. Inserting a puzzle piece into a slot succeeded twice out of 20, at 3.4 minutes per attempt. Same model, same hardware, same agent scaffolding. A tenfold difference in success rate, and slow in both cases.
That result maps onto a distinction DeepMind’s Gemini Robotics research lead Keerthana Gopalakrishnan made in October: coverage and proficiency are different problems. A model that can attempt more tasks is not a model that does each of them well. General knowledge helps with the long tail of situations; contact precision, speed and error recovery each need their own training and feedback.
The practical instruction for a robot team follows directly: measure what the off-the-shelf model already does on your task, then train only the failing part. The list of things you can stop building is real, and so is the list of things you cannot.
What the new APIs actually hand you
The π API beta, published on 13 October, offers data upload, hosted fine-tuning and cloud inference: you collect data with your own robot, call a foundation model, and adapt it. Dream Labs reports something stronger for Dream-1 — some dual-arm parallel-jaw robots that never appeared in training can be connected and tested without collecting robot-specific demonstrations.
The enabling condition is an action interface at the end effector rather than at the joints. The model outputs gripper position, orientation and opening; a local inverse-kinematics solver turns that into joint commands. Because the interface is shared, experience can cross bodies. Because the solver is local, the reach limits, joint limits and motion constraints of your specific arm stay your problem.
Dream-1 uses a world-action model that predicts video and action jointly. That helps transfer, but it does not make bodies equivalent: results on parallel-jaw dual arms do not automatically extend to dexterous hands, where contact is continuous and the action space is far larger.
Once you are inside an API, the remaining training work splits into three stages that the industry names inconsistently: pre-training, mid-training and post-training. NVIDIA’s EgoScale, published in February, is a concrete example — pre-train on human egocentric manipulation video, mid-train on aligned human-and-robot data, post-train on the downstream task. The alignment step exists precisely because hands and grippers differ in structure, viewpoint and action representation.
The data question is now specific
If the base model already covers a capability, collecting more of the same data buys little. The question becomes which specific gap you are filling.
Sergey Levine, a Berkeley professor and π co-founder, described the shift in an October interview: models start out dependent on demonstrations, and as competence rises, language guidance, autonomous trial-and-error and human video become more useful. A data mix that works today is not necessarily the mix that works at the next stage.
Egocentric human video is doing a lot of work in this transition because it expands scene and task coverage without occupying a robot — a robot-hour is expensive and does not scale quickly. But what is learned from a person has to be converted into a perception and action representation the robot can use, which is exactly what a mid-training stage like EgoScale’s is for.
FACT, published in October by Fei-Fei Li and collaborators, takes a different slice: force. Human manipulation recorded with force measurement is used alongside robot demonstrations during pre-training, and the model refines actions with force prediction after a coarse plan. The paper’s ablations support the contribution of that force information.
The general rule that comes out of all three: data value is measured by which capability gap it closes, not by hours. Missing scene coverage means collect more scenes; weak contact control means collect physical signals; an inability to recover from failure means you need failure-and-recovery episodes. Otherwise you are renting hard drives.
The feedback loop is the product
The more robots you deploy, the more real-world failures you can record. But raw logs are not training signal. They become signal when outcomes are labelled, corrections are captured, or rewards are constructed — and then fed back for retraining and re-testing.
π’s API describes the loop explicitly: upload data, fine-tune, run on the robot, decide from the failures what to collect next. The developer still organises that loop; connecting a robot to an API does not make it self-improving.
The mechanisms inside π’s earlier work show what the loop looks like when it is designed rather than improvised. π*0.6 (November 2025) used RECAP, combining demonstrations, human corrections during operation and autonomous attempts, with reinforcement learning on outcome signals — which turns failure into training data and lets post-training continue after deployment. π0.7 (April 2026) put robot data, human video and autonomous execution into one framework and conditioned on quality, speed and policy; the team distilled execution experience accumulated during RECAP into it. On laundry folding, coffee making and box folding, a single general model reached the success rate and throughput of specialist RL models trained for each task.
That is the most consequential claim in the whole stack: capability acquired on one task can flow back into the next generation of the foundation model, so the team that follows does less adaptation work. The caveat is that post-training does not disappear — new tasks, new hardware and higher quality requirements still land there.
Simulation expands the test, the robot signs it off
General models are also entering the development process itself: reconstructing scenes, generating training data, analysing failures, editing code, then testing the resulting policy on hardware. That improves a robot without calling a model at runtime.
Google’s 13 October Gemini 4 Argon robotics work showed Real2Sim reconstruction, physics calibration and simulation-assisted training. NVIDIA’s 21 October Isaac update described a reference pipeline combining Astra, Isaac and Cosmos for data generation, training and evaluation.
The thing to keep straight is that asset generation and physics calibration are different jobs. Generating a 3D scene quickly reduces set-up labour; making simulation useful for training still requires contact, friction and motion response to match reality. A physics solver with wrong mass and friction parameters will mislead training just as efficiently as no simulation at all. Simulation scales the experiment; the real robot supplies the calibration and the sign-off.
How to judge the next model release
Wang’s “GPT-7 punches through” remark is a personal prediction, not a release plan or a verified capability, and Unitree has not published the control architecture behind the painting demo — so which parts GPT-6 handled is unknown.
But the prediction is testable, and the test has three parts that should be reported together:
- Transfer. How much of the capability survives a change of task, scene or robot body?
- Extra training. How much new data and human debugging is needed to reach the same operational requirement?
- Task quality. Does it hold speed, stability and failure recovery, or only succeed once on camera?
A model that meaningfully moves embodied AI will need less task-specific adaptation while supporting reliable work across more tasks. Anything measured on one task, one robot and one afternoon of trials does not answer the question — including most of what has been published so far.
FAQ
Did GPT-6 really teach a robot to paint without new code?
Unitree described an internal test in which the robot changed colours and cleaned its brush without dedicated programs. The company has not published the control architecture or the failure rate, so the claim should be treated as a vendor description of a demo rather than a measured capability.
What is the difference between coverage and proficiency?
Coverage is how many tasks a model can attempt at all; proficiency is how well it performs each one. A general model can raise coverage quickly through semantic understanding while leaving contact-heavy tasks — insertion, wiping, assembly — well below usable success rates.
Why does an end-effector action interface help transfer between robots?
Because it expresses the action in a space many arms share: where the gripper should be, how it is oriented and how open it is. A local IK solver converts that to joint commands, so the model does not need to learn each robot’s kinematics — but reach, joint limits and dynamics remain body-specific.
If simulation gets better, do we still need real-robot data?
Yes. Simulation scales experiments and generates rare scenarios, but contact, friction and actuator response have to be calibrated against hardware, and the final acceptance test happens on the real robot. The realistic split is simulation for breadth, hardware for truth.
Is human video enough on its own?
No. Egocentric human data expands scene and task coverage cheaply, but it has to be mapped onto the robot’s perception and action space, and it does not contain the force and failure signals that contact-rich tasks need. It is a component of the mix, not a replacement for it.