DEV Community

Ahab
Ahab

Posted on • Originally published at indieseek.co

Gemini Robotics ER 2 vs Streaming Migration Checklist

#ai #robotics #programming #api

Gemini Robotics ER 2 vs Streaming: migrate before ER 1.6 shuts down

Quick answer

Google released two Gemini Robotics ER 2 preview endpoints on July 30, 2026:

  • gemini-robotics-er-2-preview for request-based embodied reasoning, structured outputs, code execution, tool orchestration, video-progress analysis, and batch work.
  • gemini-robotics-er-2-streaming-preview for a persistent Live API session that receives continuous sensor input and returns low-latency function calls.

Google will shut down gemini-robotics-er-1.6-preview on August 31, 2026. A standard migration can start with a model-ID replacement, but moving to Streaming is an architecture change: it requires a stateful WebSocket session, a receive loop, blocking robot tools, and reconnect handling.

Do not make the model your physical safety controller. Keep deterministic limits, emergency stops, collision avoidance, authorization, and human approval outside the model. Google's model card says the Robotics Models should not be used for safety-critical work where failure could cause injury or property damage.

model proposes an action
-> policy validates arguments and authority
-> independent safety controller checks the physical state
-> robot executes one bounded action
-> observed result returns to the model
Enter fullscreen mode Exit fullscreen mode

Who this is for

This guide is for robotics developers, embodied-AI teams, and agent builders already using ER 1.6 or evaluating ER 2 through Google AI Studio and the Gemini API. It is also useful if you need to decide between offline video analysis, request-based orchestration, and a live robot-control loop.

This is not a guide to the consumer Gemini app, the separate Gemini Robotics 2 vision-language-action model, or Gemini Robotics On-Device 2. ER 2 is the reasoning and orchestration layer exposed through the Gemini API; your robot API or action model still performs the physical action.

For general Gemini workload routing, see the Gemini 3.6 Flash vs 3.5 Flash-Lite migration guide. For evidence-bound agent completion, reuse the Goal evidence verification checklist.

Choose the endpoint by control loop

Both ER 2 endpoints accept text, image, video, and audio input and return text. Both list a 131,072-token input limit and 65,536-token output limit. Their execution contracts are different.

Requirement ER 2 standard ER 2 Streaming
Model ID gemini-robotics-er-2-preview gemini-robotics-er-2-streaming-preview
API shape Interactions API request/response Stateful Live API WebSocket
Best fit Spatial reasoning, uploaded video, planning, progress analysis, batch evaluation Continuous observation, reactive agents, multi-robot coordination
Function calling Supported Supported; physical actions must be BLOCKING
Structured output Supported Not supported
Code execution / computer use Supported Not supported
File Search / URL context Supported Not supported
Context caching Supported Not supported
Batch API Supported Not supported
Live API Not supported Supported

Use the standard endpoint when a task can be framed as one bounded observation and one bounded plan. Use Streaming only when the application genuinely needs a persistent feedback loop. Do not choose Streaming merely because “real time” sounds newer; it removes several standard-endpoint capabilities and adds session failure modes.

Account for the price change

Google lists the same standard token prices for both ER 2 endpoints:

Model / mode Paid input per 1M tokens Paid output per 1M tokens Batch
ER 1.6 standard $1 text/image/video; $2 audio $5 $0.50 / $1 audio in, $2.50 out
ER 2 standard $2 for text/image/video/audio $10 $1 in, $5 out
ER 2 Streaming $2 for text/image/video/audio $10 Not available

For text, image, or video workloads, ER 2 standard is a 2x per-token increase over ER 1.6 standard. Audio input remains $2 per million tokens, while output doubles. ER 2 standard batch restores a 50% discount; Streaming has no batch lane.

Measure cost per accepted robot task, not per API request:

accepted_task_cost =
  (input_tokens * input_rate + output_tokens * output_rate) / 1_000_000
  + retries
  + failed-action recovery
  + sensor and robot runtime
Enter fullscreen mode Exit fullscreen mode

A cheaper token path that causes repeated grasps or ambiguous tool calls is not cheaper operationally.

Migrate ER 1.6 in two lanes

Lane A: standard endpoint replacement

Freeze a representative fixture set before changing the model. Include clear and ambiguous images, short and long videos, one multi-step plan, one tool call, and one refusal or out-of-policy instruction. Then replace only the model ID:

from google import genai

client = genai.Client()
response = client.interactions.create(
    model="gemini-robotics-er-2-preview",
    input=[
        {"type": "image", "uri": "", "mime_type": "image/jpeg"},
        {"type": "text", "text": "Locate the marked container and return normalized [y, x] coordinates."},
    ],
    generation_config={"thinking_level": "medium"},
)
print(response.output_text)
Enter fullscreen mode Exit fullscreen mode

Compare spatial accuracy, task-success detection, tool arguments, latency, token use, and accepted-task cost against ER 1.6. Google's docs recommend medium thinking as a latency/performance balance; treat that as a starting point, not a universal optimum.

Lane B: Streaming architecture

Streaming uses a persistent session. The documented sensor contract is raw 16-bit little-endian PCM audio at 16 kHz, JPEG images at no more than one frame per second, and text. Video frames alone do not trigger a reasoning turn; send a text or audio prompt when the model should inspect the scene.

Declare every physical action with "behavior": "BLOCKING". The receive loop must execute one tool call, return its observed result, and let the model decide the next step. Add a timeout, cancellation path, reconnect policy, and a maximum action count. A network retry must never silently repeat a completed motor action.

Put a deterministic action gate in front of the robot

The model can plan; it cannot establish that an action is physically safe. Validate each tool call through four independent gates:

  1. Authority: Is this user and session allowed to invoke the named tool?
  2. Schema: Are position, speed, force, workspace, payload, and timeout within hard limits?
  3. State: Do current sensors, interlocks, and collision checks permit the action now?
  4. Confirmation: Does the action cross a human-approval boundary, such as entering a shared area or handling a fragile object?

Use deterministic robot firmware or a certified controller for emergency stops and motion limits. The model should receive a structured rejection such as outside_safe_workspace, not a bypass around the gate. The approval and confidence checklist offers a reusable pattern for keeping suggestions separate from authorized actions.

Eight migration acceptance tests

Test Pass condition
ER 1.6 fixture replay ER 2 meets the pre-declared accuracy and accepted-task threshold without hidden prompt changes
Endpoint capability probe Standard-only features never route to Streaming, and Live sessions never route to standard
Blocking action order The next physical tool call is not issued before the prior tool response arrives
Lost connection after actuation Reconnect reconciles an action ID and physical state; it does not repeat the motion
Out-of-range arguments The deterministic gate rejects the call before the robot SDK receives it
Stale or ambiguous frame The system asks for another observation or stops; it does not guess a physical target
Cost and latency envelope Tokens, first-action latency, total task time, retries, and accepted-task cost stay within limits
Privacy and shutdown drill Identifiable-person data follows notice/consent rules, and the service can fall back or stop before August 31

Also verify API-key restrictions. Google says unrestricted API keys are rejected for Robotics ER requests with 403 Forbidden; use a restricted server-side key and never ship it in robot firmware or a client app.

Copyable rollout record 

gemini_robotics_er2_rollout:
  checked_at: "2026-08-01T18:00:00+08:00"
  old_model: "gemini-robotics-er-1.6-preview"
  target_model: "gemini-robotics-er-2-preview | gemini-robotics-er-2-streaming-preview"
  route: "request | streaming"
  sdk_version: ""
  fixture_count: 12
  accepted_tasks: 0
  p95_first_action_ms: 0
  p95_total_task_ms: 0
  mean_input_tokens: 0
  mean_output_tokens: 0
  accepted_task_cost_usd: 0
  controls:
    deterministic_motion_limits: true
    emergency_stop_tested: true
    duplicate_action_reconciliation: true
    human_approval_boundary: ""
    privacy_notice_and_consent: true
  rollout: "hold | canary | enabled"
Enter fullscreen mode Exit fullscreen mode

Common mistakes

Treating ER 2 as the motor controller. ER 2 returns text and tool calls. A separate robot API, VLA, and safety layer execute and constrain movement.

Changing the model ID and API architecture together. First prove the standard ER 2 replacement on frozen fixtures. Evaluate Streaming as a separate lane.

Using non-blocking physical tools. The robotics Live API supports only blocking function calls for physical actions. Parallel motor commands require an explicit deterministic coordinator outside the model.

Ignoring duplicate actions on reconnect. A delivered tool call, a completed physical action, and a lost response can otherwise produce a dangerous replay.

Collecting people on camera without a data boundary. Google's Robotics documentation requires notice and consent when identifiable people may be captured and recommends minimizing personal data, including face blurring where practical.

Calling a preview model production-safe. Preview availability and an impressive demo do not replace your hardware validation, risk analysis, or legal and safety review.

FAQ

When does Gemini Robotics ER 1.6 shut down?

Google's deprecation table lists August 31, 2026, with gemini-robotics-er-2-preview as the recommended replacement.

Is the Streaming endpoint always better?

No. It adds a Live API feedback loop but does not support Batch, caching, code execution, File Search, structured outputs, or URL context. Choose it only for continuous sensor-driven tasks.

Can I use non-blocking function calls for robot movement?

No. Google's robotics streaming guide says physical actions must use blocking behavior, and only blocking function calls are supported in the robotics Live API.

Does ER 2 directly control a robot?

Not by itself. It produces reasoning output and tool calls. Your robot functions, action model, motion controller, and safety system carry out and constrain the physical work.

Can ER 2 be used in safety-critical environments?

Google's model card says users should not use the Robotics Models for safety-critical work where malfunction could foreseeably cause death, injury, or property damage. Treat that as a hard product boundary, not a disclaimer to route around.

Sources

Top comments (0)