Gemini Robotics On-Device 2 is a vision-language-action model designed to run locally on a robot. It takes text instructions, camera images and numerical proprioception such as joint or device state, then returns numerical robot actions. Google introduced the new model card on July 30, 2026 and positions the model for low-latency or network-constrained environments.
The essential distinction is output. Gemini Robotics ER 2 produces text and function calls for high-level planning; On-Device 2 produces actions for a particular embodiment. If those categories are unfamiliar, our VLA versus VLM comparison explains why a local VLA belongs closer to the control loop than a cloud reasoning model.
On-Device 2 is an action model, not a smaller ER 2
The name Gemini Robotics 2 covers models with different jobs. On-Device 2 is based on Google's on-device Gemma family and Gemini Robotics 1.5 technology. Its purpose is to map an instruction, visual observation and robot state to an action sequence. The output is numerical, which allows an application to pass proposed movement into a robot-specific execution and validation layer.
ER 2, by contrast, is a high-level embodied-reasoning VLM based on Gemini 3.5 Flash. It returns text and function calls and can supervise a longer workflow through video. The models are complementary in concept, but Google does not present them as a universal plug-and-play package.
| Property | Gemini Robotics On-Device 2 | Gemini Robotics ER 2 |
|---|---|---|
| Model type | Vision-language-action model | Vision-language model for embodied reasoning |
| Typical inputs | Text, images and numerical robot proprioception | Text, images, video and audio |
| Output | Numerical robot actions | Text and function calls |
| Execution location | Designed for local inference | Cloud-accessible through Gemini API and AI Studio |
| Current access | Trusted testers / waitlist | Public preview |
| Primary job | Embodiment-specific action generation | Planning, orchestration and progress monitoring |
Local inference addresses latency and connectivity
A cloud connection can be valuable for broad reasoning, but an action policy may need frequent observations and responses. Network variability introduces delay and can interrupt a task. Running the VLA on the robot or nearby hardware keeps model inference closer to sensors and controllers, which can improve responsiveness and allow some operation where connectivity is limited.
Local does not automatically mean real-time, private or safe. Performance depends on compute hardware, camera throughput and controller rate. Data may still leave the device for logging, updates or supervision. Our edge AI for robots guide covers local, cloud and hybrid trade-offs.
Text, vision and proprioception define the action context
The text instruction provides intent, such as placing an object in a container. Images show objects, obstacles and the robot's relationship to the scene. Proprioception provides numerical state that an image may not reveal reliably, including joint configuration or other embodiment-specific measurements. The model combines those inputs to generate numerical actions.
A production integration still needs an action representation that matches the robot. Joint targets, end-effector deltas and mobile-base commands are not interchangeable. Developers must normalize sensor data, align coordinate frames, set action bounds and convert the model's output into the controller's supported format.
Independent checks should reject movements outside the workspace, above speed or force limits, or inconsistent with current sensor state. These controls matter even when a policy performs well in demonstrations because small perception or calibration errors can become physical motion.
| Signal | What it contributes | Integration question |
|---|---|---|
| Text instruction | Task intent and constraints | Is the command unambiguous and permitted? |
| Camera image | Objects, geometry and scene changes | Are viewpoints, lighting and occlusion within training coverage? |
| Robot proprioception | Current numerical body state | Are units, timing and coordinate frames normalized? |
| Numerical action output | Proposed movement | What validator and controller convert it into safe execution? |
Google says new robots can be adapted with fewer than 200 examples
Google reports that On-Device 2 can adapt to a completely new robot with fewer than 200 demonstrations, described as a few hours of training data. If reproducible on a target platform, that would reduce one of robotics' largest costs: collecting and labeling enough embodiment-specific trajectories to make a general policy useful.
The claim needs its conditions attached. Fewer than 200 examples is a Google-reported result, not a service guarantee. The required data may change with task diversity, camera layout, gripper design, degrees of freedom and the gap between the new robot and Google's training distribution. A narrow tabletop skill is not equivalent to open-ended household manipulation.
Teams should ask what counts as an example and whether success holds across objects, operators and lighting. Even a small set can be expensive if it requires expert teleoperation.
Reported benchmark gains are promising but scoped
In its model card, Google reports a 53.3% final success rate for On-Device 2 on the SO101 setup, compared with 6.7% for its v1 baseline. On Dexmate, Google reports 75.6% versus 33.3%. These figures indicate a substantial gain within Google's evaluation, but they should be cited as company-reported results rather than independent field measurements.
A success percentage is only meaningful with the task set, number of trials, reset procedure and failure definition. Even 75.6% may be unsuitable for an unattended workflow if a failure can damage equipment. Conversely, a lower raw rate may still support a human-supervised research application where the model proposes actions and an operator approves them.
The right next step is a target-specific evaluation. Record per-task completion, intervention rate, near misses, recovery behavior and latency. Compare the adapted model with a scripted baseline and a human operator so that the benefit is measured against an actual alternative.
| Google model-card evaluation | On-Device 2 final success | v1 baseline | How to interpret it |
|---|---|---|---|
| SO101 | 53.3% | 6.7% | Google-reported result on a defined setup; not a universal robot rate |
| Dexmate | 75.6% | 33.3% | Google-reported result; target deployments require their own trials |
Access is limited to trusted testers
On-Device 2 is not generally available through the public Gemini API, and Google has not presented it as a downloadable consumer model. Interested organizations can apply to the trusted-tester program through the On-Device page. Access, hardware requirements, licensing and support conditions may vary by participant and are not fully defined on the public page.
This status affects procurement language. A team can research the model and prepare an evaluation plan, but it should not promise a shipping feature based on access it does not yet have. Ask Google what hardware target is supported, whether weights or a runtime are supplied, how adaptation works and what data or telemetry the program requires.
Developers who need public access today can experiment with the high-level Gemini Robotics ER 2 API, while continuing to use an existing local controller or VLA for action. That is a different architecture and should not be presented as a substitute for On-Device 2.
The model card sets clear limits on generalization and safety
Google notes limitations on out-of-distribution tasks and robots with high degrees of freedom. Evaluation focused primarily on standing bi-arm manipulation. Mobile manipulation, whole-body locomotion and other complex embodiments therefore fall outside the strongest evidence base. A result on a tabletop arm should not be transferred to a humanoid walking through a public space.
Hardware safety remains the responsibility of the complete system. Learned action policies can behave unpredictably, and a model cannot certify brakes, collision detection, payload limits or emergency stops. Test within a bounded workspace, use action limits and independent sensors, and keep the system away from safety-critical healthcare or transportation roles unless the entire application satisfies the relevant engineering and regulatory requirements.
At the strategy level, On-Device 2 shows why Google's physical AI program separates general planning from local action. Our Google physical AI map connects this model to ER 2 and the partner demonstrations without treating research access as commercial readiness.
Frequently asked questions
Can I download Gemini Robotics On-Device 2?
Google does not list a general public download or Gemini API endpoint. On August 6, 2026, access was offered through a trusted-tester waitlist, with program conditions determined by Google.
Does On-Device 2 work without the internet?
It is designed for local inference and network-constrained environments, so its action model can run close to the robot. A complete product may still need connectivity for setup, updates, logging or supervision, depending on the implementation.
Does fewer than 200 examples guarantee adaptation to any robot?
No. Google reports adaptation to completely new robots with fewer than 200 examples in its work, but the result depends on the embodiment, tasks, data quality and evaluation setup. Every target robot needs an independent test.
Official sources checked
- Google DeepMind: Gemini Robotics On-Device 2
- Google DeepMind: Gemini Robotics On-Device 2 model card
- Google: Gemini Robotics ER 2 announcement
- Google DeepMind: Gemini Robotics ER 2 model card
- Google DeepMind: Gemini Robotics 2 safety paper
Last checked: August 6, 2026