Gemini 4 Argon in OpenCode: Einrichtung und aktuelle Grenzen

Gemini 4 Argon lässt sich in OpenCode über dessen nativen Google-Provider konfigurieren. Entscheidend ist das Verhalten nach der ersten Antwort: Behält der Client signierte Teile bei, gibt er Tool-Ergebnisse korrekt zurück und erkennt er eine Antwort zur Fortsetzung? Bei unserer Offline-Prüfung von OpenCode v1.19.0 wurden Text- und Tool-Nachrichten korrekt verarbeitet. Allerdings gab es Lücken bei der Fortsetzung langer Ausgaben und bei unterbrochenen Streams.

Diese Anleitung liefert eine Ausgangskonfiguration und grenzt genau ein, was die Ergebnisse belegen. Eine vollständige, mit echten Anfragen getestete Coding-Agent-Integration mit SeedRouter ist damit nicht nachgewiesen. Wenn du einen kleineren Client mit genau einer bewusst gestarteten Anfrage pro Runde suchst, nutze die Python-Anleitung für Unterhaltungen.

Gemini 4 Argon in OpenCode konfigurieren

Prüfe mit opencode --version die installierte Version. Die folgenden Ergebnisse gelten für den veröffentlichten Build v1.19.0, der am 14. Oktober 2026 getestet wurde. Ein neuerer Build muss separat geprüft werden. Eine Funktion im Entwicklungszweig belegt nicht, dass eine installierte Release-Version sie unterstützt.^[1]

Lege für die erste Prüfung ein leeres Projektverzeichnis an. Lade die OpenCode-Konfiguration in dieses Verzeichnis herunter. Der Abschnitt für die Verbindung lautet:

{
  "provider": {
    "google": {
      "npm": "@ai-sdk/google",
      "options": {
        "apiKey": "{env:SEEDROUTER_API_KEY}",
        "baseURL": "https://api.seedrouter.ai/v1beta"
      },
      "models": {
        "gemini-4-argon": {
          "name": "Gemini 4 Argon",
          "reasoning": true,
          "tool_call": true,
          "limit": { "context": 1048576, "output": 4096 },
          "options": {
            "thinkingConfig": { "thinkingLevel": "low", "includeThoughts": true }
          }
        }
      }
    }
  }
}

OpenCode unterstützt die Ersetzung von Platzhaltern durch Umgebungsvariablen in Konfigurationsdateien.^[2] Setze SEEDROUTER_API_KEY in deiner Shell, ohne den Schlüssel im Projekt zu committen. Die heruntergeladene Datei wählt außerdem google/gemini-4-argon, deaktiviert das Teilen und automatische Updates und erlaubt nur das read-Tool. Prüfe diese Berechtigungen, bevor du ein bestehendes Repository verwendest. Die Flags reasoning und tool_call beschreiben das Verhalten des Clients. Sie belegen nicht, dass ein bestimmtes Konto oder ein Dienst jede Operation unterstützt.

In dieser Konfiguration ist der Ausgabewert 4096 ein bewusst gewähltes Startbudget, nicht Argons offizielles Maximum. Auch Thinking verbraucht dieses Budget. Die Regeln für Kontext, Ausgabe und Fortsetzung findest du in der API-Referenz.

Mit einer kurzen Anfrage beginnen

Prüfe die Konfiguration und die aktuellen Preise. Führe anschließend Folgendes aus:

OPENCODE_CONFIG="$PWD/gemini-4-argon-opencode.json" \
OPENCODE_DISABLE_MODELS_FETCH=1 \
OPENCODE_DISABLE_AUTOCOMPACT=1 \
opencode run --model google/gemini-4-argon \
  "Explain a mutex in one sentence. Do not use tools."

Mit deinem Schlüssel wird daraus eine echte Modellanfrage. OpenCode kann fehlgeschlagene Versuche wiederholen oder während eines Agentenlaufs weitere Anfragen stellen. Eine Begrenzung der Ausgaben auf die Kosten eines einzelnen Aufrufs ist mit diesem Befehl nicht garantiert. Beende den Prozess, wenn die Antwort unvollständig ist oder sich Anfragen wiederholen. Für eine strikte manuelle Kontrolle verwende stattdessen das Python-Beispiel.

Der native Anfragepfad sollte auf gemini-4-argon:streamGenerateContent?alt=sse enden. Im getesteten Build sendete der Google-Provider seine Zugangsdaten in x-goog-api-key. Das unterscheidet sich von den cURL-Beispielen mit Bearer-Header in der allgemeinen API-Anleitung. Die Wahl eines generischen OpenAI-Providers erzeugt nicht dieselbe native Anfrage.

Was die Offline-Prüfungen belegt haben

Der Test verwendete die veröffentlichte CLI, eine lokal simulierte API und Dummy-Zugangsdaten. In acht Szenarien wurden 17 Loopback-Anfragen gestellt. Kein Modell generierte die Antworten, und die gemeldeten Tokenwerte waren künstlich festgelegt. Diese Beobachtungen beschreiben den Client, nicht die Modellqualität oder die tatsächliche Abrechnung.

Szenario	Beobachtetes Verhalten in v1.19.0
Nativer Textstream	Fügte getrennte Textereignisse zur erwarteten Antwort zusammen
Zweite Gesprächsrunde	Bewahrte die getesteten Thinking- und Textsignaturen in den Modellteilen auf
Lese-Tool mit Ergebnisrückgabe	Las eine temporäre Testdatei und gab ihren Inhalt in `functionResponse` zurück
`MAX_TOKENS`	Meldete einen Abbruch wegen der Längenbegrenzung und stellte in diesem Test keine weitere Anfrage
HTTP 400	Beendete sich in diesem Test mit einem Fehler, ohne die Anfrage zu wiederholen
HTTP 429	Wiederholte die Anfrage einmal; die nächste simulierte Antwort war erfolgreich

Der Test bestätigt, dass thinkingConfig gesendet wurde. Er belegt nicht, dass ein echter Dienst diese Einstellung angewendet hat. Dass eine synthetische Signatur im Verlauf weitergereicht wird, belegt ebenso wenig, dass eine echte Signatur in einer späteren Anfrage akzeptiert wird.

Warum lange Ausgaben zusätzliche Aufmerksamkeit erfordern

Argons CONTINUATION-Antwort erfordert die ursprüngliche Anfrage zusammen mit dem neuesten continuationToken auf oberster Ebene. Beim Fortsetzen dieser Generierung dürfen Teilausgaben nicht an den normalen Chatverlauf angehängt werden.^[3]

In unserem Test stufte OpenCode v1.19.0 CONTINUATION als unbekannt ein. Die nächste Anfrage ließ das Token weg und fügte die Teilantwort dem Verlauf hinzu. Auch als ein Stream nach einer Teilausgabe ohne Abschlussereignis endete, sendete der Client zusätzliche gewöhnliche Anfragen. Der simulierte Dienst beendete dieses Szenario nach sechs Aufrufen. Die Zahl sechs ist keine nachgewiesene Grenze für Wiederholungen im Client.

Diese Konfiguration ist daher keine verifizierte Lösung für Long Decode mit Argon. Eine erfolgreiche kurze Antwort löst diese Fälle nicht. Bevor du dich bei längeren Coding-Sitzungen darauf verlässt, wiederhole die relevanten Prüfungen mit genau der Clientversion, die du einsetzen möchtest.

Fragen zur OpenCode-Einrichtung

Umfasst das auch die Prüfung echter Tool-Aufrufe und der Abrechnung?

Nein. Einfaches Text-Streaming mit SeedRouter hat eine separate lokale Ende-zu-Ende-Prüfung bestanden. Diese OpenCode-Prüfung verwendete jedoch simulierte Antworten. Echte Tool-Auswahl, Signaturen, Medien, Kontoberechtigungen und Abrechnung müssen jeweils separat geprüft werden.

Kann ich stattdessen eine OpenAI-kompatible Konfiguration nutzen?

Das ist ein anderes Protokoll mit einem anderen Kompatibilitätsumfang. Diese Anleitung prüft native Gemini-Inhalte und Signaturen. Googles Dokumentation zu Long Decode schließt den OpenAI-kompatiblen Endpunkt von dieser Funktion aus.^[3]

Verhindert das Abschalten der automatischen Kontextkomprimierung auch Wiederholungen?

Nein. Komprimierung und die Wiederholung von Anfragen sind getrennte Verhaltensweisen. Die Umgebungsvariable im Beispiel garantiert keine feste Obergrenze für die Anzahl der Anfragen oder die Kosten.

Die nächsten Prüfschritte festlegen

Wenn du Gemini 4 Argon in OpenCode verwendest, beginne mit einem kurzen Textaustausch. Prüfe anschließend genau die Tool- und Verlaufsfunktionen, die deine Arbeit benötigt. Behandle Fortsetzung und unterbrochene Streams als getrennte Abnahmefälle. Halte die Modellseite und die native API-Referenz neben der Clientkonfiguration griffbereit, damit du Protokolldetails und aktuelle Preise leicht nachschlagen kannst.