Gemini Nexus: A Chrome Side Panel That Reverse-Engineers Gemini Web

The problem: one browser, too many AI tabs

Most browser AI extensions pick one backend. You get a Gemini extension, or a ChatGPT extension, or something that only works if you paste an API key. Gemini Nexus takes the opposite position: it ships provider drivers so the same side panel can talk to Gemini Web, the official Gemini API, OpenAI-compatible endpoints, OpenRouter, DashScope, Anthropic, and Zhipu. The README states the extension is aimed at browser-native AI workflows and lists nine provider entries, each with its own Base URL, API Key, and Model IDs fields. The audience is engineers and power users who already move between several model vendors and do not want a separate extension per vendor. The README also notes a tab-scoped side panel, so the assistant can be limited to the pages where it is wanted. That scoping detail matters more than it sounds: an AI panel that follows every tab becomes noise within a day.

How the provider driver layer actually routes requests

The repository layout puts provider drivers under services/providers, and the README names the files: web.js, official.js, openai_compatible.js, and anthropic.js. Several vendors share one driver. DeepSeek, OpenRouter, Qwen/DashScope, and Zhipu all route through openai_compatible.js, with provider-specific defaults layered on top. The README describes those defaults concretely: DeepSeek gets reasoning_content display, OpenRouter fetches /models and accepts provider routing JSON, DashScope uses enable_thinking and VL image input, and Zhipu sends native thinking toggle payloads. That is a real architectural choice. It keeps the codebase small, but it also means a bug in openai_compatible.js can affect four vendors at once, and vendor-specific quirks have to be expressed as conditionals inside one adapter rather than isolated modules. The official Gemini driver is separate (official.js), and the Anthropic driver implements the Messages API natively with extended-thinking stream display. Context handling is described as summary compression plus recent-turn trimming, which is the standard mitigation for context limits. The README does not publish the compression algorithm or its token budget, so how aggressively history is dropped is not something you can confirm from the documentation.

What the Gemini Web provider does, and why it is the risky part

This is the section to read twice. The README's Reverse Engineering and Data Flow Disclosure states that the Web provider accesses gemini.google.com by reverse-engineering internal RPC endpoints and extracting authentication tokens (atValue, blValue, f.sid) from page HTML. Those tokens are stored locally and reused to mimic browser requests, which is how the extension works without an official API key. The README says this approach likely violates Google's Terms of Service and may be considered unauthorized access. It also states requests go to gemini.google.com and push.clients6.google.com with your session credentials. Separately, the README discloses that for Gemini-generated images the extension removes embedded watermarks (metadata markers) to enable direct download, and that this strips attribution from AI-generated content. The authors describe both features as research/experimental and disclaim liability for misuse. Whatever you think of the engineering, the documentation is unusually direct about the legal exposure, and that candour is itself a signal about how the feature should be treated. If your Google account carries anything you would not want flagged, this is not the provider to enable.

Getting it running: build, load, configure

The README's badge row lists Vite, TypeScript, JavaScript, and Chrome Extension MV3, and the repository is JavaScript-primary with a manifest-v3 topic tag. The README does not print a full install command sequence, so the exact build invocation has to come from the repository's package.json rather than from the documentation. What the README does specify is the configuration surface after loading: each provider needs its own Base URL, API Key, and Model IDs, entered in extension settings. API keys are stored locally in Chrome extension storage, and the README states they are not transmitted to any third party beyond the chosen provider. Two toggles are called out by name: Gemini Web temporary chats, which keeps Web-provider requests out of Gemini Recent chats, and Google Search grounding for the Gemini API path. For OpenAI-compatible endpoints, the README says web search is available either through the Responses API web_search parameter or through Chat Completions web_search_options, depending on the endpoint in use. Since the default branch is main and the latest release is v5.3.0, pinning to a tagged release rather than tracking main is the safer path for a browser extension that holds session tokens.

Browser control, MCP tools, and what they imply

Beyond chat, the extension injects a floating toolbar and exposes browser-control tools built on the Chrome DevTools Protocol, with optional external MCP tools. The README describes two behaviours that show the authors have thought about the failure modes. Browser-control tasks are marked with Chrome native tab groups, and list_pages and select_page are kept focused on the controlled scope. In other words, the agent's view of the browser is deliberately narrower than the browser itself. External links open in new tabs so third-party pages do not fail to load inside the side panel. Image and screenshot input are supported. The README also notes that re-editing historical user messages and continuing from that point is enabled for API providers only, which is a concrete asymmetry: on the Web provider you cannot branch from an earlier turn. If that workflow matters to you, it effectively rules out the no-API-key path. The README does not document a sandbox boundary for the CDP-based tools, so treat browser control as a feature to enable deliberately rather than by default.

Where it is the wrong tool, and what to use instead

Three cases stand out. First, regulated or managed environments: the Web provider's token extraction and the watermark removal feature are both documented as likely ToS violations, which is a poor fit for a corporate browser profile. Second, anyone who needs a stable, contractually supported integration: the Web provider depends on internal RPC endpoints that Google can change without notice, and the README offers no compatibility guarantee. Third, anyone who wants a vendor-neutral agent runtime rather than a browser panel. For that last case, the natural alternative is a standalone MCP client or a desktop agent that connects to MCP servers directly. The difference in approach is architectural: Gemini Nexus puts the model inside the browser and reaches outward to MCP servers as an optional add-on, while a dedicated MCP client puts the tool protocol first and treats the browser as one more tool. If your work is mostly browser context (reading the page you are on, screenshotting it, driving tabs), Gemini Nexus matches the shape of the problem. If your work is mostly filesystem, shell, and repository tasks, a browser extension is the wrong container, and the extension's own README treats MCP as optional rather than central.

Maintenance, upgrades, and the MIT licence

The release cadence visible in the repository is brisk: v5.2.0 on 2026-08-22, v5.2.4 on 2026-08-24, v5.3.0 on 2026-09-03, with the last push to main on 2026-09-06. Frequent releases are useful when a provider changes an endpoint, and the Web provider is exactly the kind of integration that breaks without warning. The cost is upgrade churn: a Manifest V3 extension that stores API keys and session tokens in Chrome storage needs re-verification after updates, particularly around the storage and request paths. The README mentions that settings are preserved as much as possible across extension identity and local upgrade paths, which implies that preservation is best-effort rather than guaranteed. The project is MIT licensed, which permits commercial use, modification, and redistribution, subject to the licence text. MIT does not shield you from the provider-side terms: the README's ToS warning about the Gemini Web provider and the copyright note about watermark removal sit outside what any software licence can grant. This is a description of the licence terms, not legal advice; if the ToS exposure matters to your organisation, that is a question for counsel, not for the README.

Editorial conclusion

Adopt Gemini Nexus if you want a single side panel that can talk to Gemini Web without an API key and to official or OpenAI-compatible endpoints with one, and you accept that the Web provider and watermark removal are documented as likely ToS violations. Do not adopt it in a managed enterprise browser profile or anywhere a Google account is shared, because the extension stores session tokens (atValue, blValue, f.sid) locally and sends requests with your credentials. Before installing, read the README's Reverse Engineering and Data Flow Disclosure in full, then verify which provider driver your chosen endpoint actually routes through under services/providers.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yeahhe365/Gemini-Nexus on GitHub