Gemini Nexus: eine Chrome-Erweiterung, die Gemini Web per Reverse Engineering anbindet

Welches Problem die Erweiterung löst und für wen sie gedacht ist

Die Ausgangslage ist alltäglich: Man liest eine Seite, braucht eine Zusammenfassung oder eine Übersetzung, und wechselt dafür in einen anderen Tab. Gemini Nexus setzt stattdessen auf eine Seitenleiste, die den Seitenkontext direkt mitnimmt. Die README nennt als Zielgruppe niemanden explizit, doch die Funktionsliste zeichnet ein klares Profil: Menschen, die Gemini Web ohnehin im Browser angemeldet haben, keinen separaten API-Schlüssel verwalten wollen und trotzdem Werkzeugaufrufe, Bildverarbeitung und tab-basierte Steuerung brauchen. Für diese Gruppe ist der Web-Provider der eigentliche Anreiz, denn er kommt ohne Schlüssel aus und nutzt die bestehende Google-Sitzung. Wer dagegen nur einen Chatbot in einer Seitenleiste sucht, bekommt hier deutlich mehr Mechanik als nötig, inklusive Browsersteuerung und externer MCP-Werkzeuge.

Gemini Web ohne API-Schlüssel: der Reverse-Engineering-Kern

Der technisch interessanteste Teil steht nicht in der Funktionsliste, sondern im Abschnitt zu Datenfluss und Reverse Engineering. Die Erweiterung spricht gemini.google.com nicht über eine dokumentierte Schnittstelle an, sondern über interne RPC-Endpunkte. Dafür liest sie Authentifizierungstoken aus dem HTML der Seite aus, die README nennt konkret atValue, blValue und f.sid. Diese Werte werden lokal gespeichert und anschließend verwendet, um Browseranfragen nachzubilden. Die Ziele sind gemini.google.com und push.clients6.google.com; die Anfragen gehen mit den Sitzungsdaten des angemeldeten Nutzers an Google. Das ist ein Mechanismus, der bricht, sobald Google die Seitenstruktur oder die Token-Namen ändert, und die README sagt selbst, dass dieses Vorgehen wahrscheinlich gegen Googles Nutzungsbedingungen verstößt und als unbefugter Zugriff gewertet werden könnte. Wer diese Zeilen überliest, hat das Projekt nicht verstanden.

Anbieter-Treiber: neun Einträge, aber nicht neun Codebasen

Die Anbieterauswahl wirkt größer, als sie im Code ist. Laut README liegen die Treiber unter services/providers, und mehrere Einträge teilen sich eine Datei: OpenAI Compatible, OpenAI Official, DeepSeek, OpenRouter, Qwen/DashScope und Zhipu laufen alle über openai_compatible.js, während Anthropic eine eigene Datei anthropic.js bekommt und Gemini Web über web.js sowie die offizielle Gemini-API über official.js angebunden sind. Der Unterschied zwischen den Einträgen liegt damit vor allem in Voreinstellungen und Anpassungen: DeepSeek erhält Standardwerte für Chat Completions und eine Anzeige von reasoning_content, OpenRouter ruft /models ab und unterstützt Provider-Routing-JSON, Qwen nutzt einen DashScope-kompatiblen Endpunkt mit enable_thinking und Bildeingabe für VL-Modelle. Das ist ein bewusster Kompromiss: weniger Code, aber die Anbieterspezifika müssen in einem gemeinsamen Treiber untergebracht werden. Die README formuliert es als Adaption zur Laufzeit.

Kontextverwaltung und Browsersteuerung

Zwei Mechanismen tragen den Alltag. Erstens die Kontextverwaltung: Die README nennt Zusammenfassungskomprimierung und das Kürzen aktueller Gesprächsrunden, um Modellgrenzen nicht zu überschreiten. Zweitens die Browsersteuerung über das Chrome DevTools Protocol, ergänzt um optionale externe MCP-Werkzeuge. Dabei werden Steuerungsaufgaben mit nativen Tab-Gruppen markiert, und die Werkzeuge list_pages und select_page bleiben auf den kontrollierten Bereich beschränkt. Das ist eine sinnvolle Einschränkung, denn ohne sie würde die Steuerung über alle offenen Tabs laufen. Ein weiteres Detail mit praktischer Wirkung: Externe Links öffnen in neuen Tabs, damit das Laden im Seitenpanel nicht fehlschlägt. Für API-Anbieter lässt sich außerdem eine historische Nutzernachricht erneut bearbeiten und der Verlauf von dort fortsetzen; für den Web-Provider gilt das laut README nicht.

Einschränkung: der Web-Provider ist ein bewegliches Ziel

Die offensichtlichste Grenze ist die Abhängigkeit von internen RPC-Endpunkten und ausgelesenen Token. Ändert Google die HTML-Struktur, verschwinden atValue oder blValue, oder wird der Sitzungsfluss umgebaut, ist der Web-Provider nicht mehr funktionsfähig, bis der Extraktionscode angepasst wird. Genau hier liegt das Wartungsrisiko, und es ist kein theoretisches: Die Release-Historie zeigt Versionen im Abstand von wenigen Tagen bis Wochen (v5.2.0, v5.2.4, v5.3.0 zwischen dem 22. August und dem 3. September 2026), was zu einem Projekt passt, das gegen eine fremde Oberfläche arbeitet. Dazu kommt die Wasserzeichen-Entfernung bei Gemini-Bildern, die laut README Metadaten-Marker entfernt und damit Zuordnung und Signatur von KI-Inhalten streicht. Für Forschung und Experimente mag das vertretbar sein. In einem professionellen Redaktions- oder Compliance-Kontext ist es ein Ausschlusskriterium, unabhängig davon, wie gut die übrige Technik ist.

Installation und Konfiguration

Die README beschreibt den Build-Stack über Vite und TypeScript, ein Installationsrezept für Endnutzer enthält der vorliegende Auszug jedoch nicht. Wer die Erweiterung selbst baut, muss den Quellcode auschecken, die Abhängigkeiten installieren und den Vite-Build ausführen, bevor der entpackte Ordner in Chrome geladen werden kann. Klar dokumentiert ist dagegen die Konfiguration: Pro Anbieter werden Base URL, API Key und Model IDs gesetzt. Der API-Schlüssel liegt laut README lokal im Chrome-Extension-Speicher und wird nur an den gewählten Anbieter übertragen. Für Gemini Web ist statt eines Schlüssels ein angemeldetes Google-Konto nötig. Weitere Schalter: temporäre Chats für den Web-Provider, damit Anfragen nicht in den Gemini-Verlauf wandern, Google-Search-Grounding über die Gemini-API mit Quellenanzeige, sowie Websuche über die Responses-API (web_search) oder Chat Completions (web_search_options), je nach Endpunkt. Der Geltungsbereich der Seitenleiste lässt sich auf einzelne Tabs begrenzen.

Alternative: ein schlüsselbasierter Client ohne Web-Provider

Die naheliegende Alternative ist ein Assistent, der ausschließlich offizielle Schnittstellen mit API-Schlüssel nutzt, etwa der Gemini-API-Zugang über Google AI Studio oder ein OpenAI-kompatibler Client. Der Unterschied liegt nicht in der Oberfläche, sondern in der Herkunft der Antworten: Dort gibt es keine Token-Extraktion aus fremdem HTML, keine Nachbildung von Browseranfragen und keine Abhängigkeit von der Seitenstruktur eines fremden Dienstes. Dafür braucht man einen Schlüssel, trägt die Kosten selbst und verliert den Zugriff auf die aktuellen Chat-Modi der Weboberfläche, die die README als Modellliste des Web-Providers führt. Gemini Nexus versucht, beides zu verbinden, und dieser Versuch ist der Grund für die rechtlichen Vorbehalte, die das Projekt selbst formuliert.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

Das Repository steht unter MIT, die README verlinkt eine LICENSE-Datei. Das erlaubt kommerzielle Nutzung und Änderungen, verlagert aber die Verantwortung für die Nutzung der Web-Provider-Funktionen vollständig auf den Anwender; die Autoren schreiben selbst, dass sie die Funktionen zu Forschungs- und Experimentierzwecken bereitstellen und keine Haftung übernehmen. Das ist keine Rechtsberatung, sondern nur die Wiedergabe dessen, was im Repository steht. Der Wartungsaufwand hängt fast vollständig am Web-Provider: Solange Google seine internen Endpunkte stabil hält, ist der Aufwand gering; ändert sich etwas, muss der Extraktionscode nachgezogen werden. Vor einem Einsatz lohnt daher ein Blick auf die tatsächlich installierte Manifest-Version und die angeforderten Berechtigungen, auf die Domain-Allowlist für die genutzten Anbieter sowie darauf, ob die Dateien unter services/providers in der eigenen Version noch zu den in der README beschriebenen Endpunkten und Parametern passen.

Redaktionelles Fazit

Wer Gemini im Browser ohne eigenen API-Schlüssel ausprobieren will und die in der README eingeräumten Risiken gegenüber Googles Nutzungsbedingungen akzeptiert, findet hier einen funktionsreichen Ansatz mit MIT-Lizenz. Wer eine rechtlich abgesicherte Grundlage für den Produktiveinsatz braucht, sollte den Web-Provider und die Wasserzeichen-Entfernung deaktivieren oder das Projekt gar nicht erst einsetzen. Vor dem Ausrollen zuerst prüfen, ob die installierte Manifest-Version und die Berechtigungen zu den im Betrieb erlaubten Domains passen, und ob die Anbieter-Treiber unter services/providers in der eigenen Version noch dieselben Endpunkte ansprechen wie in der README beschrieben.

Offizielle Quellen

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