Deep Research Max cannot use a signed-in local browser session by default. Google lists deep-research-max-preview-04-2026 as an Interactions API agent code, powered by Gemini 3.1 Pro. Its tools run in Google’s service. To check a page that is only available in your Tabbit Browser login, hand the report to a local agent that can use Tabbit CLI, then stop at a named human-review draft.
A Reddit commenter testing Gemini Deep Research said it had “too much yapping and pretend to sound smart.” The comment does not identify the April Max API route, so it is not a test of this exact agent. It is a useful reason to keep source checks visible. (Original discussion)
Key takeaways
Deep Research Max is a managed research agent, not a normal Gemini chat model that a local client can freely wrap with tools.
Google documents Google Search, remote MCP servers, URL Context, Code Execution, File Search, and uploads for the Interactions API. Each private source must be explicitly connected.
A local Tabbit login is separate from those API tools. A cloud agent does not inherit it.
Use a bounded handoff: ask Deep Research Max for claims and public citations, then let a local client verify named signed-in pages.
Keep the final output as a separate named draft. A person checks the sources and decides whether to write to the workspace.
Which part can reach which source?
| Component | Where it runs | What it can reach | What it does not prove |
|---|---|---|---|
| Deep Research Max | Google Interactions API | Google Search and configured tools such as remote MCP or File Search | Access to a local Chromium profile or Tabbit cookies |
| Local agent client | Your computer, if configured that way | Model endpoint and tools available to that client | That the selected model route is the same as Deep Research Max |
| Tabbit CLI | Local Tabbit environment | Task tabs in the connected Tabbit Browser | That a cloud agent can call the local launcher |
| Website login | The Tabbit Browser environment you signed into | Pages the account is authorized to view | Permission to send those pages to an unapproved model provider |
Google describes Deep Research Max as an asynchronous research agent and documents its API preview through paid Gemini API tiers. The live model page labels deep-research-max-preview-04-2026 as an Agent code and points to the Interactions API. Check that exact identifier and account eligibility in the current Google AI Studio docs or project before spending API quota. Do not treat the agent code as a drop-in model name for OpenCode, Codex, or another local agent host. For a primer on the difference between a model and its tool-running client, see how agentic reasoning uses tools.
Pick a path by where the data lives
| Your source | Practical path | Boundary to check |
|---|---|---|
| Public web pages | Deep Research Max with its documented Google Search tools | Verify citations and dates against the original pages |
| Private system with an approved remote MCP server | Connect that server to the Interactions API, then scope its data | The server must be reachable and authorized; MCP is not your browser cookie jar |
| Page visible only after a local website login | Local agent plus Tabbit CLI | Use a client and model endpoint that can run local tools |
| Remote runner with no local bridge | Produce a short handoff packet for the user or local client | Do not claim the runner used the signed-in tab |
If your private source is already available through a Google-supported connected file store or your own remote MCP service, the API agent can work with that configured source. That is a different access path from taking over a local browser. Google's announcement describes remote MCP and file tools; its Deep Research Max API page gives the current agent code. Neither source documents a direct Tabbit CLI bridge.
Make a bounded handoff to a local browser task
First use Deep Research Max for the public research portion. Ask it to return a short claim list with source URLs and dates, and keep private information out unless the configured provider and tool are approved for it. A separate Reddit discussion describes a Gemini agent handling job research with a resume, but the user did not identify the exact model route. Treat that as a personal example, not a promise about privacy controls or Max behavior. (Original discussion)
Then install Tabbit Browser and the local Tabbit CLI guide. Sign in to the site yourself inside the Tabbit environment the CLI will reach. Set up a local client that can run tools and choose a model route that client actually supports. For example, in OpenCode the installed skill can be discovered as @tabbit; Pi documents /skill:tabbit, and other clients expose skills differently. Confirm three independent checks: the client loaded the skill, ~/.local/bin/tabbit-cli diagnose reaches the intended browser, and the target site shows your authorized login. The existing-browser connection walkthrough, CLI setup for Codex, and MCP versus CLI guide explain the client-side choices.
A local project fixture check on November 9 verified that a second named Tabbit task tab could read a test page after a first task signed into that same test environment. It returned the fixture heading and ID GEO-104. That verifies session reuse for the tested Tabbit environment only. It does not prove that the Google API agent can call Tabbit or that an external model and local client work together.
Use a read-only prompt like this in the local agent. In OpenCode, invoke the skill with @tabbit; use your client’s documented entry point elsewhere.
Use @tabbit in this local session. The attached Deep Research Max report is a list of claims to check, not a source of truth. Open only the signed-in pages I name. For each requested claim, record the page title, URL, visible date, exact field label, and a short supporting excerpt. Mark each item verified, unclear, or missing. Do not edit, submit, publish, or share anything. Save a separate document named "Deep Research Max handoff, draft 01" with a source table and a short list of conflicts. Stop with the draft open and mark it "Needs human review".Expected output: a separate draft where each checked claim points to an authorized page that a reviewer can reopen. The task tab is separate, so you can continue using your other browser tabs while it runs. If the client is remote and cannot reach the local launcher, return the claim list and let the user run this bounded local step. The first-task checklist and browser-agent security guide help define a read-only scope. See the browser-for-agent overview before granting page access.
Stop before writing to the source workspace
The useful division is simple: Deep Research Max collects and synthesizes the sources it can reach; a local agent checks browser-only pages; a person resolves conflicts and approves any edit. Do not chain the API report directly into an irreversible browser action. Keep the evidence table, the draft, and the source pages visible until review is complete.
A Reddit commenter who tried Gemini Deep Research reported a quality concern, and another described using a Gemini agent for job research. Neither thread verifies the exact Max route on a signed-in browser. No original community report of this exact local-browser pairing surfaced in the searches, so treat the handoff as a documented workflow design, not a tested Google-to-Tabbit integration. If your client cannot connect the local model and browser tool, stop at a human handoff rather than assuming the API agent can take over the tab.
FAQ
Can Deep Research Max read my local browser login?
Not by default. Its Interactions API tools run in Google’s service, while a Tabbit login lives in a local browser environment. A custom remote MCP server can expose authorized data, but it must be configured separately.
What is the current Deep Research Max API name?
Google’s model page lists `deep-research-max-preview-04-2026` as an Interactions API agent code. It is a managed research agent powered by Gemini 3.1 Pro, not a general chat model route.
Can I send private workspace data to Deep Research Max?
Google documents remote MCP servers, file uploads, connected file stores, and other tools. Use only a source your organization has explicitly authorized and your API integration has configured.
Can Tabbit CLI connect directly to Deep Research Max?
No official plug-and-play connection was verified. Tabbit CLI connects a local agent client to Tabbit Browser. A cloud research agent cannot reach that local browser unless a separately supported, authorized handoff or remote tool is built.
Which Tabbit skill command should I use?
OpenCode can invoke the discovered Tabbit skill with `@tabbit`; Pi uses `/skill:tabbit`. Other clients may expose a `/skills` list or their own syntax, so check the client rather than assuming `/tabbit` is universal.
How should I review the handoff?
Save a separate draft with source URLs, page titles, dates, and the exact fields checked. Reopen the sources in the browser, compare the draft, and leave any write or submit action for a person.