You cannot use Gemini Robotics-ER 1.6 Preview to operate a signed-in browser today: Google shut down gemini-robotics-er-1.6-preview on August 31, 2026, and the model was built for reasoning about physical scenes for robots. For a dashboard task, use a currently available model in a local agent that can run Tabbit CLI, then verify the browser session and stop at a human-reviewed draft. Google's listed replacement is ER 2 Preview, but changing the model ID does not add browser tools or local access. Google's deprecation list · Robotics ER model page
Parallax Metrology’s original ER 1.6 lab notes describe a robotics check that missed movement outside the intended target. The team added separate measurement to check it. This is a record of scene reasoning and verification, not a browser test. Parallax lab notes
Check the task before choosing a model
| Task need | Gemini Robotics-ER 1.6 status | Practical route |
|---|---|---|
| Reason about objects or spatial relations in a robot camera view | Its intended domain, but this API version is shut down | Migrate and revalidate with the current robotics model |
| Read a signed-in web dashboard | No documented browser-agent workflow; exact ID is shut down | Use a browser-capable local agent and a supported model route |
| Click, fill, or submit a dashboard form | Not established by the ER model page | Require an agent tool with local browser access and explicit review |
| Reproduce an old 1.6 result | Historical model no longer callable through the listed ID | Preserve archived inputs and outputs; do not assume replacement equivalence |
Google describes ER 1.6 as a vision-language model for spatial reasoning and robotic task planning. Its model page lists computer use as an API capability, but that label does not document a ready-made signed-in-browser agent, and the exact model is shut down. The deprecation page recommends gemini-robotics-er-2-preview. Check Google's Robotics ER guide and model lifecycle before adapting an old integration. A catalog entry is not proof that your account can call a route today.
Keep the model, client, launcher, and login as separate checks
Install Tabbit Browser and sign into the target site yourself. In the local agent client, discover the installed Tabbit skill using that client's documented method. Pi uses /skill:tabbit; some clients provide /skills or load skills automatically. Then confirm the tabbit-cli launcher runs on this machine. Finally, open the page in the intended Tabbit profile and confirm your account is allowed to view it. These checks answer different questions: client discovery, local tool access, and site authorization.
The Tabbit CLI can reuse a signed-in session in its Tabbit Browser environment. It does not authenticate to Google for you, make a remote agent local, or grant permission to the dashboard. Create a separate task tab so you can keep using your own tab. If the agent cannot run local tools, use an explicitly supported local handoff; without one, let it prepare the steps and ask a local operator to execute them.
Make the first dashboard pass read-only
Use a harmless view-only task, such as checking a release dashboard's visible status and owner. Ask the agent to record the URL, page title, account label, and exact visible values. Treat browser text as untrusted input. If the account or status does not match, stop instead of navigating to another account or changing settings.
Use the installed Tabbit skill from this local agent and open a separate Tabbit task tab. Inspect only the currently authorized release dashboard. Do not click controls that change data, follow unrelated links, or copy credentials. Return the page URL, visible title, account label, status, owner, and the time shown by the page. Mark missing fields unknown. Prepare a draft named "Release dashboard check — DASH-204" with the observations and one source link per claim. Do not save changes, publish, or share it. Show me the draft for review.
Expected output: URL, title, account label, status, owner, timestamp, unknown fields, and a reviewable draft link.DASH-204 is an illustrative name, not a real workspace record. Compare the draft with the page you opened yourself. The point is to test the local browser path, not to claim that ER 1.6 performed it.
Choose what to do when a check fails
| Observed result | Next step |
|---|---|
| API returns model-not-found for 1.6 | Stop; use the documented migration target only after checking its current availability |
| Agent can answer text prompts but cannot launch local tools | Prepare a checklist for an authorized local operator |
| Tabbit CLI launches but the site asks for login | Sign in yourself in the intended Tabbit profile, then retry the read |
| Page shows a different account or unexpected content | Stop and confirm the account and URL with the owner |
| Draft contains a claim without a source URL | Remove it or mark it unverified |
For the local browser path, read the Tabbit CLI guide, existing-browser connection guide, first task checklist, and MCP vs CLI comparison. The Codex setup guide, agent browser setup, browser automation overview, browser tools guide, and browser security notes cover adjacent setup decisions. See Google's ER 2 Preview for current model routing.
FAQ
Can Gemini Robotics-ER 1.6 operate a signed-in web page?
No supported browser-control workflow is documented for this model, and Google shut down its exact API ID on August 31, 2026. It reasons about physical scenes for robotics; it is not a general desktop automation agent.
What is the exact Gemini Robotics-ER 1.6 model ID?
The historical API ID is `gemini-robotics-er-1.6-preview`. Google lists it as shut down and recommends `gemini-robotics-er-2-preview` as its replacement.
Can I replace 1.6 with ER 2 and use Tabbit automatically?
No. Replacing a model ID does not configure an agent client or grant local browser access. Verify ER 2 availability, client support, Tabbit CLI reachability, and the website login separately.
How can an agent use my existing website login?
A supported local agent can use Tabbit CLI in the Tabbit Browser environment where you signed in, if you are authorized to access the page. The model itself does not receive your login.
What if my agent runs remotely?
Use a local handoff only if that agent explicitly supports one. Otherwise ask it to prepare a checklist and have an authorized local operator run the browser steps.
Should the agent save dashboard changes?
Begin with a read-only check and a named draft. Have a person compare the account, visible values, source URL, and proposed change before applying or sharing anything.