Gemini 4 Hydrogen in Cline und OpenCode einrichten

Wähle für Hydrogen über Ofox einen OpenAI-kompatiblen Provider, setze die Base URL auf https://api.ofox.io/v1 und sende die Modell-ID google/gemini-4-hydrogen. In Cline CLI konfigurierst du den Provider direkt. In OpenCode V2 deklarierst du zuerst einen eigenen Provider und ein Modell und wählst sie anschließend aus. Eine Textantwort ist nur die erste Prüfung: Ein Coding-Client muss auch einen Werkzeugaufruf empfangen, eine Datei lesen und das Ergebnis an das Modell zurückgeben können.

Diese Anleitung behandelt Cline CLI 3.0.74 und OpenCode V2 2.3.0, geprüft am 13. November 2026. Sie trennt native Google-Zugangsdaten von Ofox-Zugangsdaten und enthält eine kleine Leseaufgabe, bevor du ein echtes Repository anschließt. Die Cline-Erweiterung für den Editor hat eine eigene Version und Oberfläche; die CLI-Befehle gelten nicht automatisch für jede Erweiterungsversion.

Ofox veröffentlicht diese Anleitung. Wir haben die veröffentlichten Clients mit einem lokalen Server ausgeführt, der synthetische Streaming-Antworten lieferte. Beide Clients lasen die Testdatei tatsächlich und gaben ihren Inhalt zurück. Wir haben keine kostenpflichtige Hydrogen-Anfrage ausgeführt, kein Kundenkonto validiert und weder Modellqualität noch Geschwindigkeit gemessen. Den unten beschriebenen Test gegen den echten Dienst führst du selbst aus, um die vollständige Funktion deines Kontos und Aufrufwegs zu bestätigen. Verlinkte Originaldokumentationen von OpenCode, Cline und Google sind auf Englisch.

Provider, Schlüssel und Modell als Einheit auswählen

Vermische nicht den Google-Modellnamen mit einem Ofox-Provider und trage keinen Ofox-Schlüssel beim Google-Provider ein. Auch ein lokaler Modellalias unterscheidet sich von der tatsächlich übertragenen ID.

Googles Empfehlung, für neue Integrationen Interactions zu verwenden, bedeutet nicht, dass der Google-Provider eines vorhandenen Coding-Clients diese API automatisch nutzt. Trage keinen Interactions-Endpunkt in das Base-URL-Feld eines OpenAI-kompatiblen Providers ein. Die jeweiligen Anfrage- und Antwortformate erläutert die Hydrogen-API-Anleitung.

Der für diesen Artikel geprüfte Ofox-Katalog nennt für Hydrogen OpenAI- und Gemini-Protokollunterstützung sowie einen Chat-Completions-Endpunkt. Dieser Eintrag beschreibt einen Integrationsweg, beweist aber nicht eigenständig sämtliche Clientfunktionen, das Werkzeugverhalten beim vorgelagerten Anbieter oder das Kontingent eines bestimmten Kontos. Nutze für den Ofox-Schlüssel die Anleitung zur API-Authentifizierung. Nachrichten-, Streaming- und Werkzeugfelder findest du in der Chat-Completions-Dokumentation.

Passende Version installieren und ein kleines Projekt vorbereiten

Bei OpenCode ist der Paketname wichtig. Die aktuelle offizielle Installationsanleitung installiert V2 mit @opencode/cli. Das ältere Paket opencode-ai gehört zu V1. Beide stellen den Befehl opencode bereit. Der Befehlsname allein sagt deshalb nicht, welche Konfigurationssyntax passt.

Für genau die hier geprüften Versionen:

npm install -g cline@3.0.74
npm install -g @opencode/cli@2.3.0
cline --version
opencode --version

Prüfe die offiziellen Installationsvoraussetzungen für dein Betriebssystem. Die Versionsbindung dient der Reproduzierbarkeit und verspricht nicht, dauerhaft die neueste Version zu liefern. Wenn du bereits OpenCode V1 nutzt, lies vor einer Änderung der globalen Installation die Migrationsanleitung von V1 zu V2. V2 kann den Befehl ersetzen, den dein bestehender Ablauf verwendet.

Offizielle englische OpenCode-Dokumentation, aufgenommen am 13. November 2026. Der Screenshot dokumentiert die Versionsgrenze, keinen Hydrogen-Modelltest. Originalseite zur Migration.

Erstelle für den ersten Werkzeugtest ein separates Verzeichnis. Ein eigener Git-Stamm macht auch die Projektgrenze eindeutig, wenn der Client nach Projektkonfigurationen sucht.

mkdir hydrogen-client-check
cd hydrogen-client-check
git init
printf 'Local test marker: HYDROGEN_CLIENT_CHECK_20261113\n' > fixture.txt

Verwende zunächst ein Projekt, das nur diese Testdatei enthält. Du willst einen einzelnen Lesevorgang beobachten, kein großes Repository prüfen oder eine lange Folge von Änderungen freigeben. Speichere den Schlüssel weder in opencode.json noch in der Versionsverwaltung. Das OpenCode-Beispiel liest ihn aus OFOX_API_KEY. Setze die Variable über deine übliche lokale Verwaltung von Geheimnissen und committe keine ausgefüllte Umgebungsdatei.

Hydrogen in Cline CLI konfigurieren

Die Cline-CLI-Referenz beschreibt Provider-Authentifizierung und eigene Modellangaben. Konfiguriere für Ofox den OpenAI-kompatiblen Provider mit der genauen Base URL und Modell-ID:

cline auth -p openai \
  -b https://api.ofox.io/v1 \
  -m google/gemini-4-hydrogen \
  -k "$OFOX_API_KEY" \
  --data-dir "$PWD/.cline-hydrogen"

openai ist das im Test verwendete CLI-Providerargument. Der gespeicherte Provider wurde zu openai-compatible normalisiert. Das eigene Datenverzeichnis trennt den Zustand dieses Tests von deinem gewöhnlichen CLI-Zustand. Behandle es als private lokale Konfiguration und schließe es aus der Versionsverwaltung aus. Der Befehl übergibt Zugangsdaten an den Client: Kopiere keine bereits aufgelösten Argumente in Logs oder Screenshots. Cline bietet alternativ eine interaktive Authentifizierung, falls diese besser zu deiner Umgebung passt.

Die Base URL endet bei /v1. Hänge nicht /chat/completions an; der Provider setzt den Anfragepfad zusammen. In unseren lokalen Mitschnitten ergänzte er /chat/completions und sendete die exakt konfigurierte Modellzeichenfolge.

Für den nativen Google-Weg verwendest du stattdessen einen Google-Schlüssel und die native Modell-ID in einem anderen Datenverzeichnis:

cline auth -p gemini \
  -m gemini-4-hydrogen \
  -k "$GEMINI_API_KEY" \
  --data-dir "$PWD/.cline-google-hydrogen"

Ergänze diesen Befehl nicht um die Ofox-Base-URL. Cline CLI 3.0.74 lehnte bei unserer Konfigurationsprüfung eine eigene Base URL für gemini ab. Das Speichern der nativen Konfiguration mit einem Dummy-Schlüssel gelang. Damit ist nur belegt, dass die CLI die Konfiguration akzeptiert, nicht dass der Schlüssel gültig oder Hydrogen für das Projekt verfügbar ist. Scheitert die erste native Anfrage, prüfe Google-Projektkontingent und Verifikationsanforderungen anhand der Hydrogen-Zugangsanleitung.

Starte nun den Ofox-Test aus dem Verzeichnis mit der Testdatei:

cline --data-dir "$PWD/.cline-hydrogen" \
  --auto-approve false \
  "Read fixture.txt using a file tool. Return its exact marker. Do not modify files or run shell commands."

Prüfe und genehmige den beabsichtigten Dateizugriff, wenn die Abfrage erscheint. Wir setzen --auto-approve false ausdrücklich, weil diese CLI-Version standardmäßig automatische Freigaben aktiviert. Dies ist eine interaktive Abnahmeaufgabe, kein unbeaufsichtigter Job. Für spätere Automatisierung solltest du passende Berechtigungen separat definieren.

Fehlt Hydrogen in der Modellauswahl, unterscheide die Auswahlliste vom Dienst selbst. Der geprüfte Cline-Quellkatalog enthielt Hydrogen nicht, während die CLI eine eigene Hydrogen-ID akzeptierte. Keine der beiden Beobachtungen belegt die Live-Verfügbarkeit. Verwende die genaue eigene ID, prüfe den gespeicherten Provider und untersuche die erste echte Antwort, statt ein ähnlich benanntes älteres Modell auszuwählen. Hintergrund zur Erweiterung liefert die Cline-API-Konfigurationsanleitung auf Englisch.

Eigenen Hydrogen-Provider in OpenCode V2 anlegen

Erstelle opencode.json im Testprojekt mit dieser vollständigen V2-Konfiguration. Sie nutzt die aktuelle Struktur für Provider und Modelle:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "ofox-hydrogen/hydrogen",
  "providers": {
    "ofox-hydrogen": {
      "name": "Ofox Hydrogen",
      "env": ["OFOX_API_KEY"],
      "package": "@opencode/ai/providers/openai-compatible",
      "settings": {
        "baseURL": "https://api.ofox.io/v1"
      },
      "models": {
        "hydrogen": {
          "modelID": "google/gemini-4-hydrogen",
          "name": "Gemini 4 Hydrogen",
          "limit": {
            "context": 1048576,
            "output": 65536
          },
          "capabilities": {
            "tools": true,
            "temperature": false
          }
        }
      },
      "compatibility": {
        "maxTokensField": "max_tokens"
      }
    }
  },
  "permissions": [
    { "action": "*", "resource": "*", "effect": "deny" },
    { "action": "read", "resource": "*fixture.txt", "effect": "allow" }
  ]
}

Halte drei Namen auseinander:

• ofox-hydrogen ist der lokale Providerschlüssel. Ein eigener Name verhindert Verwechslungen mit einem eingebauten Provider oder einer vorhandenen Anpassung.
• hydrogen ist der lokale Modellschlüssel. Zusammen ergeben sie die Auswahlzeichenfolge ofox-hydrogen/hydrogen.
• google/gemini-4-hydrogen ist modelID, also der Wert, den der kompatible Provider an Ofox sendet.

Kontext- und Ausgabewerte beschreiben dem Client die Modellgrenzen. Sie vergeben kein Kontingent und garantieren nicht, dass jede Anfrage das Maximum nutzen kann. Hydrogen teilt sein Fenster von 1.048.576 Tokens zwischen Eingabe, Denken und Ausgabe. Das Ausgabebudget von 65.536 Tokens umfasst Denken, nicht nur sichtbaren Text. Diese Höchstwerte sind keine unabhängigen Kontingente. Eine Ausgabegrenze ist außerdem keine gewünschte Antwortlänge. Beginne mit einer kleinen Aufgabe und prüfe den tatsächlich gemeldeten Verbrauch deines Aufrufwegs.

Zwei Kompatibilitätseinstellungen sind wichtig. temperature: false weist den Client an, diese Sampling-Steuerung nicht zu senden. maxTokensField: max_tokens entspricht dem in Ofox dokumentierten Ausgabetokenfeld. Ohne die Überschreibung verwendete unser OpenCode-V2-Mitschnitt max_completion_tokens; mit ihr nutzten die Hauptanfragen max_tokens. Belegt ist damit eine Änderung des clientseitigen Feldes, nicht die Ablehnung aller anderen Aliasnamen durch Ofox.

Die Berechtigungsregeln verbieten andere Aktionen und erlauben Lesen für Pfade mit dem Testdatei-Suffix. Sie sind bewusst eng für ein Projekt mit dieser einzelnen Datei, der Platzhalter kann aber auch andere Pfade treffen, die auf fixture.txt enden. Das ist keine Betriebssystem-Sandbox. Lies vor der Anpassung an ein echtes Repository, Schreibwerkzeuge oder Shell-Zugriff die OpenCode-Berechtigungsdokumentation.

Führe den Test mit explizitem Konfigurationspfad aus:

OPENCODE_CONFIG="$PWD/opencode.json" \
  opencode run --standalone --format json \
  --model ofox-hydrogen/hydrogen \
  "Read fixture.txt using a file tool. Return its exact marker. Do not modify files or run shell commands."

--standalone ist in der geprüften V2-CLI verfügbar. Ein expliziter Konfigurationspfad und die Modellauswahl erleichtern die Diagnose geerbter Einstellungen oder eines unbeabsichtigten Standardmodells. Bewahre die JSON-Ereignisse für die Prüfung auf. Entferne Zugangsdaten und private Pfade, bevor du sie weitergibst.

Die allgemeine OpenCode-API-Anleitung auf Englisch liefert breiteren Providerkontext. Verwende für dieses Beispiel durchgehend die V2-Konfiguration oben. Mische ihre Pluralfelder providers und permissions nicht in ein älteres V1-Beispiel.

Den vollständigen Dateizugriff mit Rückgabe prüfen

Die erwartete Antwort enthält HYDROGEN_CLIENT_CHECK_20261113. Der Text allein genügt aber nicht als Beleg: Ein Modell kann einen Wert aus dem Gespräch wiederholen, ohne die Datei zu lesen. Prüfe anhand der Werkzeugereignisse diese Abfolge:

1. Die Anfrage verwendet den beabsichtigten Provider und die genaue Modell-ID.
2. Das Modell fordert ein Lesewerkzeug für fixture.txt an.
3. Der Client führt es aus; sein Ergebnis enthält den Marker aus der Datei.
4. Der Client gibt das Werkzeugergebnis in der nächsten Modellanfrage zurück.
5. Das Modell erstellt daraus eine abschließende Antwort, ohne offenen Werkzeugaufruf oder Clientfehler.

Ändere für einen stärkeren Test den Marker in der Datei und starte eine neue Aufgabe, ohne den neuen Wert im Prompt zu nennen. Der zurückgegebene Marker sollte sich entsprechend ändern. Prüfe, dass keine Datei verändert und keine unerwartete Aktion genehmigt wurde. Das ist eine kleine Korrektheitsprüfung, keine Bewertung, wie gut Hydrogen eine Funktion in deiner Codebasis implementiert.

Unsere Prüfungen vor der Veröffentlichung belegen nur Folgendes:

OpenCode stellte während des Tests außerdem eine Hilfsanfrage. Gehe nicht davon aus, dass eine sichtbare Nutzeraufgabe genau einer abrechenbaren Modellanfrage entspricht. Prüfe nach dem Live-Test den tatsächlichen Kontoverbrauch. Wir verwenden weder lokale Laufzeiten noch synthetische Tokenzähler als Leistungs- oder Abrechnungsbeleg.

Die aufgezeichneten Cline-Anfragen mit eigenem Modell enthielten weder ein explizites max_tokens- noch ein temperature-Feld. Ein gespeicherter Modellname setzt also nicht automatisch dieselbe Ausgabegrenze wie im OpenCode-Beispiel. Prüfe unterstützte Clienteinstellungen und tatsächliches Anfrageverhalten vor größeren Aufgaben.

Versions-, Authentifizierungs- und Verlaufsfehler eingrenzen

Ändere jeweils nur eine Variable. Kläre zuerst, ob der Fehler beim Laden der Konfiguration, bei der Authentifizierung, bei der Textausgabe oder bei der Rückgabe des Werkzeugergebnisses entsteht.

Den ersten Versionsfehler haben wir mit V1 und dem V2-Berechtigungsarray reproduziert. Paketupgrade und Berechtigungsmigration sind unterschiedliche Schritte. Das passende ausführbare Programm beweist nicht automatisch, dass eine bestehende Projektrichtlinie ihre Bedeutung behält.

Geminis Dokumentation zu Funktionsaufrufen und Denksignaturen erklärt, warum ein mehrstufiger Werkzeugdialog mehr als ein Textprotokoll benötigt. Entfernt ein Client oder Adapter erforderlichen Modellzustand, kann der erste Schritt gelingen und der nächste scheitern. Siehe die Diagnose fehlender Denksignaturen bei Gemini-Werkzeugaufrufen auf Englisch. Der Artikel beschreibt das Fehlermuster, beweist aber keinen solchen Hydrogen-Fehler in einem der beiden Clients.

Die Gemini-API-Fehleranleitung hilft auch, Authentifizierung, Kontingent und fehlerhafte Anfragen auseinanderzuhalten. Sie wurde für Argon geschrieben. Vergleiche deshalb die tatsächliche Hydrogen-Antwort, statt modellspezifische Details unverändert zu übertragen. Erfinde niemals eine Signatur und verwerfe kein fehlgeschlagenes Werkzeugergebnis stillschweigend, um einen Signaturfehler zu umgehen.

Vor echten Coding-Aufgaben einen funktionierenden Ausgangspunkt sichern

Dokumentiere Paket und Version des Clients, Provider, übertragene Modell-ID, Base URL, relevante Konfiguration, Berechtigungen und die erfolgreiche Werkzeugspur. Zugangsdaten gehören nicht in diese Aufzeichnung. Notiere, ob es sich um einen lokalen synthetischen Test oder einen Live-Test handelt und welches Konto das Kontingent bereitstellt.

Nach erfolgreichem Dateitest beim echten Dienst kannst du in einem kleinen Repository eine Funktion ohne Änderungen erklären lassen. Erlaube anschließend eine einzelne überprüfbare Änderung und führe die passende Projektprüfung aus. So trennst du Routing und Werkzeugtransport von der Beurteilung deines Codes durch das Modell. Erfolgreiches Lesen beweist weder sichere Shell-Aktionen noch verlässliche Änderungen oder Kompatibilität mit jedem Plugin.

Wiederhole die kleine Abnahmeaufgabe zuerst, wenn du Client, Provider oder Modellversion wechselst. Nutze die Hydrogen-API-Anleitung für rohe Requests und den Vergleich von Carbon, Hydrogen und Argon für die Modellauswahl. Diese Entscheidung ist davon zu trennen, ob der konkrete Client den Werkzeugdialog abschließen kann.