A benchmark post on OpenAI RoboCurve says GPT-6 Astra performed strongly on a simple robot-arm manipulation task, but it still stalled on a harder precision task. The comparison used the same pair of YAM arms, the same Inspect Robots agent policy and the same two tasks that were used in a previous Claude Fable 5 and 5.1 report: pick up a red block and place it in a bowl, then pick up a blue puzzle piece and slot it into a matching groove.
On the block-in-bowl task, Astra completed the job in 19 of 20 trials. The post says Claude Fable 5.1 managed 8 of 20 and Fable 5 only 1 of 20. Astra also finished faster, at 2.5 minutes per trial compared with 6.8 minutes for Fable 5.1, and the report estimates a lower cost per run as well, at $0.94 versus $2.12. The benchmark says the comparison was run in interleaved blinded pairs and that timers excluded thinking pauses.
The puzzle task tells a different story. Astra completed the insertion 2 times in 20 trials, exactly matching Fable 5.1. The report says both models reach the groove and then stall at the same final step, with estimated costs of $1.36 per run for Astra and $2.18 for Fable 5.1. That makes the result look less like a clean leap in robot dexterity and more like a model that is better at one class of movement while still running into the same final alignment problem on a finer manipulation task.
The methodology matters. The post says every trial was graded by a human on the highest stage it reached, so failures still counted according to how far they progressed. Large dots on the chart represent condition means and faint dots show individual trials. The report also says Astra used 80% fewer output tokens, which is a notable operational difference if the same level of performance can be achieved with less model chatter and potentially lower cost.
That said, the benchmark is still narrow. It is a two-task comparison on a single robot setup, not a general claim that the model can now handle robotics in the wild. What it does show is that the combination of a frontier language model and an established robot-policy wrapper can produce very different outcomes depending on task shape: the easy block placement looks close to solved, while the precision insertion remains stubbornly fragile. For teams building robot control systems, that is useful mainly because it draws a sharper line between what improved reasoning can help with and what still depends on high-precision motion control.
