Gemini Robotics 2: what DeepMind's own numbers show

What Gemini Robotics 2 actually is

The naming is doing nobody any favours here, so, the plain version. "Gemini Robotics 2" is the family name and also the name of one specific model sitting inside that family. Three models shipped together on the same day, and each one does a different job.

This split matters, because it is the same architecture I would draw for any serious agent system. One model reasons about what to do, and it tracks whether the thing worked. A separate, faster piece does the executing. DeepMind is explicit that ER 2 "hands off motor execution to any given lower level vision-language-action (VLA) model," which is to say the planner stays deliberately agnostic about the hands.

One detail in the docs reframes the whole thing: ER 2 is built on Gemini 3.5 Flash. Not a Pro-tier derivative. Not a bespoke architecture either. It is a Flash-class model, with spatial reasoning and video moment finding and multi-robot orchestration tuned into it. Anyone who followed Gemini 3.6 Flash already knows roughly what the compute budget underneath looks like, and the Flash-Lite line tells the same story.

The pointing and coordinate work comes from the same lineage as Gemini's agentic vision. And if you are weighing the family as a whole, I keep a running Gemini alternatives list.

The whole-body claim is real, and worth being clear about. Previous versions drove a humanoid's upper body only, for table-top work. This one controls the legs as well. The demo prompt DeepMind published is "put the watering can into the green bin in the bottom shelf," and Apptronik's Apollo 2 walks over to the table, picks the can up, steps to the shelves and places it. The same model checkpoint also drives a Franka Duo fitted with two-fingered grippers, which is the more quietly impressive part of it.

The numbers DeepMind published on itself

Here is the full table, exactly as DeepMind reported it. All three skill groups run on one shared checkpoint, across three different robot bodies, and that is why the spread here is interesting rather than embarrassing.

Read the top and the bottom of the multi-finger group together, because that one pair is the whole story of where robot learning sits in 2026. Unscrewing a bulb is 92%. Screwing one in is 36%. Both use the same five-fingered, 22-degree-of-freedom SharpaWave hand, on the same robot. What differs is the motion. Unscrewing is loose and forgiving; screwing asks you to hold an alignment while you apply torque. One is a grab. The other one is a control problem.

The gripper group beats the hand group almost everywhere, and that is the second thing worth sitting with for a moment. A two-fingered Robotiq gripper on the Franka Duo hits 89.6% on precise insertion, while the anthropomorphic hand only manages 40% on a ziplock bag. More degrees of freedom bought worse outcomes on the fine work. At least for now.

And DeepMind said so itself. The chart caption reads: "While Gemini Robotics 2 achieves a medium to high success rate for whole-body and gripper-based dexterous tasks, the multi-finger dexterous manipulation remains challenging." Elsewhere on that same page: "our robots have more to advance in movement speed," with human-level dexterity framed as a goal instead of a claim.

Why one blended number would have hidden all of this

Average those five multi-finger tasks into a single figure and you land somewhere in the mid-forties, having learned nothing. You would not know the model is near-solved on one motion and barely functional on another one. You also would not know which task to avoid designing your product around.

This is not a robotics problem at all. It is the default state of AI marketing in every category, mine included, where one tier-1 deflection figure hides exactly the same spread. Move the numbers around yourself, and watch how easy the headline is to steer:

Try "Only the flattering 4" and out comes a number any marketing team would happily print. Same model, same day, the same lab. Nothing at all was fabricated to produce it. That is the trick, and it is available to every vendor that reports one figure.

The most interesting number is about humans, not robots

Buried in the ER 2 benchmarks there is a comparison DeepMind runs three ways over. It measures how well the reasoning model steers a downstream executor, and the executor is what changes: a real robot, then a simulated one, then a human tele-operator.

The same planner is 14 points better at directing a person than at directing a robot. The model is not worse in one of the cases. The human on the other end is just absorbing the ambiguity, recovering from a bad grasp, filling in whatever intent the instruction left out.

A Reddit commenter watching the demo footage got to the same place from the outside:

"The bottleneck seems to be software. So until we get ai good enough to pilot a robot, it's going to remain slow.

If you see robots piloted by humans, they are much faster."

u/dranaei, Reddit

This is the finding I would tape to a wall, and it is not really a robotics finding. It is the AI copilot argument with a number attached to it. A model that plans and then hands off to a capable human outperforms the same model driving the end effector by itself, and the gap is measurable. In support work that is the difference between an agent drafting a reply for somebody to send, versus an agent replying on its own. The honest answer on which performs better is the same as DeepMind's, that is the one with a person in the loop, until the per-task numbers say something else.

None of which is an argument against autonomy. It is an argument for knowing the number before you pick, and that number moves fast, fast enough that the best AI agents of six months ago are not the ones you would choose today.

The rest of the ER 2 comparison set is strong, and it is worth reporting fairly:

Progress classification is the widest margin anywhere on the page: 57.4% against the 46.2% of the best non-robotics model. The metric is "can you tell how far through a task you are," scored per frame into five buckets. Unglamorous, and it is exactly the thing an agent has to know before deciding whether to keep going or to ask for help. DeepMind also reports 91.3% accuracy on moment finding, with a 0.96 second mean absolute distance, at 4x the execution speed of larger model categories.

Worth noting too that this same 57.4% means it misjudges progress roughly four times out of ten. Best in class and still wrong that often, which is a normal state of affairs in this field. It is also exactly the sort of thing that a one-line "state of the art" claim erases.

The safety jump nobody is talking about

This is the number that made me sit up. I have not seen it covered anywhere yet.

Gemini Robotics ER 1.6 followed safety instructions 47.2% of the time. That model shipped in April 2026, so four months back, and it scored below Opus 5 and below GPT 5.6 Sol on both of the safety metrics. A robotics-tuned model, worse at robot safety than the general-purpose text models it got benchmarked against.

ER 2 fixes it hard, up to 97.9% and 93.0%. Good. The useful reading, though, is what the previous generation's number tells you about trusting a version label. "Latest robotics model from a frontier lab" was, until last week, a thing which followed a safety constraint less than half the time. DeepMind also shipped a new benchmark for this, ASIMOV-Agentic, published as a public dataset. It measures whether the reasoning agent will refuse an unsafe tool call, whether it can predict that a task is impossible, and then whether it asks a human for help when it is unsure.

Refusing, predicting failure, escalating when uncertain. That is a better description of a well-built support agent than most support AI documentation manages, and it maps straight onto escalation management. The handoff is its own discipline on top of that, and chat handover is the case most teams get wrong first.

Worth being precise on the limits here. The blog claims ER 2 is DeepMind's safest robotics model to date, but it publishes no numeric score for the ASIMOV-Agentic results themselves. Those sit in a separate safety technical report. And the developer docs are blunt on where liability lands: "it is your responsibility to maintain a safe environment around the robot."

What it costs, and the gotchas in the docs

Only ER 2 has a price on it. The two models that touch hardware have none at all, for the simple reason that you cannot buy them.

The price doubled. ER 2 is 2x ER 1.6 on both the input and the output, although the flat input rate means audio-heavy work sees a smaller relative rise than vision work does. The context window did not grow at all. There is a streaming sibling too, gemini-robotics-er-2-streaming-preview, at the same headline rate, with no batch tier and no caching.

Four things in the docs which will cost you an afternoon if you do not read them first:

1. An unrestricted API key gets a hard 403. Robotics is the one Gemini surface which refuses a default key, so go add restrictions in AI Studio before your first call.
2. The streaming endpoint caps image input at JPEG, 1 frame per second. Which sits oddly against all the real-time framing. A robot streaming camera frames at no more than one per second.
3. The streaming endpoint drops structured outputs and code execution. So the JSON-schema path belongs to the non-streaming model, and the agentic-vision path also.
4. The docs recommend a medium thinking level for latency, and the getting-started sample ships high. Copy-paste from it and you inherit the slow default.

There is also a privacy notice attached to these models which no ordinary Gemini page carries. Because the models "leverage video and audio data in order to operate and move your hardware," Google requires that you do not let identifiable people be present around the robot until they have been notified and have consented, and it asks for face blurring on top. Set that against the free tier's "used to improve our products: yes." A free-tier robot with a camera pointed at people is then a consent problem, not a quota one.

And one scheduling note worth putting into your calendar: gemini-robotics-er-1.6-preview shuts down on 31 August 2026. ER 1.5 was already retired back in April. So, two endpoints retired inside a year, and every current model code still carries a -preview suffix with no stable alias to pin to.

Adapting to new robots, and the multi-robot part

Gemini Robotics On-Device 2 is the piece I find the most quietly significant. It runs locally, it inherits the motion-transfer work from Gemini Robotics 1.5, and it adapts to a completely new bi-arm robot "with just a few hours of adaptation time, typically with less than 200 examples." New shapes, new sensors, degrees of freedom that do not match.

Fewer than 200 demonstrations to bring up a new robot body, that is the number which changes the economics of the field. The tasks in that grid ran on Dexmate, SO101 and Trossen platforms, none of them the flagship humanoid. One panel is a robot arm clicking an "I am a robot" checkbox, which I assume is a joke, and which I appreciate.

Multi-robot collaboration is the other new capability. Robots which communicate, recognise each other's physical strengths, then delegate between themselves. In the demo an Apollo 2 humanoid works alongside a Franka arm, with a monitor showing what the model sees.

DeepMind thanked Apptronik, Boston Dynamics and Agile Robots as partners, and in a separate demo a Boston Dynamics Spot fetches popcorn through orchestrated Spot APIs. On the hardware side: Apptronik raised a $520M Series A-X in February 2026, which takes its total near $1B. Worth to flag that Apollo 2 is a data-collection platform and not the commercial unit. The commercial one is Apollo 3, and it has no announced date. No published specs and no published price, from any of the four hardware vendors involved.

What practitioners actually said

The Hacker News thread hit 619 points and 553 comments, and it is the better read over any of the coverage. The most useful comment there came from someone who works on these models:

"Plus we have no good reliable accuracy testing data in most cases (most tests occur on a few demos, but that isn't a good representation of how must things work), popular benchmarks, such as libero have been saturated, and nearly everything gets 95% there, most companies and researchers have their own benchmarks here."

adityashankar, Hacker News

Saturated benchmarks, and everybody grading their own homework. That describes software AI evaluation too, almost word for word, and it is why OpenAI's own evaluation guidance leans so hard on building your own eval set instead of trusting a public leaderboard.

The sharpest criticism is not about the model at all. It is about the video grammar:

"This is why we need long continuous shots of robots interacting doing tasks, rather than the sizzle reels with 5 second shots. The long shots tell the true story of how far along the technology is, while the short shots make it look way more advanced than it really is. Still, great to see the progress being made."

u/edgroovergames, Reddit

One HN commenter went further than that, calling the demos "glorified pick and place with low success rates on a needlessly complex robot," and saying he preferred a competitor's openly tele-operated footage, because it sat closer to real deployment. Harsh. Not unreasonable either, given the 45.7%.

That 36% figure then got picked up as evidence for a broader argument:

"A 36% success rate on screwing in a light bulb means there's probably something to LeCunn's take that VLM/VLA models aren't going to be the thing powering tomorrow's robots, but only time will tell."

cowboy_henk, Hacker News

The best rebuttal came in one line, and it is the one I would bet on:

"It's still very early days. There are many benchmarks that LLMs scored 36% on just 18 months ago that they're now at 100% on."

heaney-555, Hacker News

And then a roboticist, explaining why "slow and careful" is a different problem class from "fast and fluid":

"An algorithm to fold tshirts 90% of the time is easy. The cloth hangs down by gravity and you can just look for right angles (corners), find their coordinates with binocular matching, and move them to meet each other. Getting 99%, or folding them quickly, so that the fabric is actually moving instead of just hanging still- incredibly, incredibly more complex."

hwillis, Hacker News

There was a fair amount of "didn't Figure already show this" in there too, which brings me to the comparison that actually matters.

Nobody else publishes this table

I went looking for the equivalent per-task numbers from every other lab in this space. Here is what is public, all of it.

DeepMind is the only one that put absolute per-task failure rates on its own launch page. Figure names dexterity tasks and shows a four-minute dishwasher run on video, without attaching a number to any of it. Tesla has never named an Optimus model, at all. Physical Intelligence does chart per-task rates, but against an RL specialist baseline, and with the values rendered client-side instead of stated.

So the honest read on Gemini Robotics 2 is not "Google's robot is behind." Google is the only one showing you where its robot actually is, and then getting criticised for the numbers it chose to disclose. That is a bad incentive. If it holds, the next lab just publishes videos.

What this means if you are buying AI agents

I do not work on robots. I build AI agents that handle support tickets, and this release did change what I think a vendor should be required to show me.

There was a customer, a Danish B2B vehicle-telematics team running about 200 tickets a month on Zendesk and scaling toward 2,000, whose agent started confidently telling customers "yes, we support your car model" for brands that were not in their database. The knowledge base said "we support all models." The bot believed it. Their own summary of that early setup was "trial and error in the beginning." That ticket type would have scored a hard zero on a per-task table, and in the blended number it was simply invisible. This is the ordinary failure shape in customer service automation, nothing exotic, and it is why hallucination prevention is a configuration question more than a model question.

Which is why every eesel rollout runs a simulation against the customer's own ticket history first. Pull a batch of resolved tickets, generate whatever the agent would have said, compare that against what the human actually sent, score it, then produce a gap report before a single live customer is involved. It is DeepMind's table, only built from your tickets instead of light bulbs. A CX lead at a DTC supplements brand put the requirement better than I can:

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Three things I would carry from this release into any AI agent purchase, physical or not:

1. Ask for the per-task table, not the headline. When a vendor quotes one deflection number, ask to have it split by intent or by ticket type. The spread is where the truth sits, and AI performance metrics are only useful at that granularity. Same thing applies to first contact resolution.
2. Test on your own history before going live. A benchmark run on someone else's tasks predicts nothing about your refund policy edge cases. Same instinct as adversarial testing, and the reason why evaluating agents beats trusting a demo.
3. Design for the 32% task, not the 92% one. Know which work the agent should refuse. Set confidence thresholds deliberately, keep the handoff clean. Preventing one confident wrong answer is worth more than a point of coverage.

That last one is the whole game. An agent that resolves 60% of tickets and then cleanly escalates the rest is a better product than one attempting 100% and being wrong on a fifth of them, and customers tell me so constantly. The cost per resolution maths works out better as well, once you price in the tickets that a bad answer creates.

If you want the fuller measurement picture, my writeup on customer service evaluation goes deeper than I can here, and so does the agent-versus-human cost comparison. And if you are still choosing a foundation model, which LLM suits support is a better starting question than any robotics benchmark.

Try eesel

If you are shopping for agentic customer service software, and you want the per-task honesty this post keeps arguing for, that is more or less what eesel was built to give you. It plugs into Zendesk or whatever helpdesk you already run, Freshdesk included. It learns from your macros and your past tickets. Then it runs a simulation over your real history, so you get to see the shape of its accuracy per ticket type before it ever replies to a customer.

The concrete difference: you decide which ticket types it touches and which ones it leaves alone, and you get approval and rejection counts per action instead of one deflection percentage. Gridwise saw 73% of tier-1 requests resolved in the first month, and knew which 27% were not. Pricing is per ticket, so you are not buying seats for an agent that only handles a slice of the queue.

Try eesel free, or just point it at a hundred of your old tickets and see what the gap report says.