Gemini 4 Argon: API-Fehler 403, 404, 429 und leere Antworten beheben

Prüfen Sie zuerst den Endpunkt und die unverarbeitete Antwort, bevor Sie einen neuen API-Schlüssel anlegen. Eine Anfrage an Gemini 4 Argon kann scheitern, weil der Client das falsche Schema sendet, dem Projekt Berechtigungen fehlen, die gewählte Ressource nicht existiert oder ein Kontingent ausgeschöpft ist. Eine leere Antwort kann auch bedeuten, dass Ihre Anwendung das falsche Feld ausliest oder die Interaktion noch läuft.

Diese Anleitung behandelt Googles Gemini Developer API. Die Beispiele für die Interactions API wurden am 23. Oktober 2026 mit der offiziellen Dokumentation abgeglichen. Sie belegen keinen Zugang über Vertex AI, einen OpenAI-kompatiblen Proxy, Ofox oder Antigravity. Die Beispiele beruhen auf der Dokumentation; die Diagnoseübung weiter unten verwendet lokale, synthetische Fälle und ist kein erfolgreicher Live-Aufruf von Argon.

Fehlt das Modell in der Modellauswahl einer App, beginnen Sie mit der englischen Anleitung zum Zugang zu Gemini 4 Argon. Ist tatsächlich eine API-Anfrage fehlgeschlagen, folgen Sie den Schritten hier.

App-Hinweis und API-Fehler zunächst auseinanderhalten

Eine Meldung wie „currently available to Ultra plan subscribers“ weist auf die Zugangsbedingungen eines Kontos oder Produkts hin. Daraus lässt sich noch kein API-Fehler mit HTTP 403 ableiten. Notieren Sie, wo sie erschien: Gemini-App, Antigravity-App oder CLI, AI Studio, eigenes Backend oder Drittanbieter-Client. App-Abonnements und die Konfiguration des API-Projekts müssen getrennt geprüft werden.

Erfassen Sie bei einem API-Fehler diese sechs Angaben, bevor Sie etwas ändern:

1. Host und Pfad der Anfrage, ohne Schlüssel oder Zugangsdaten in der Query-Zeichenfolge.
2. Genaue Modell-ID und Version des SDKs oder Clients.
3. HTTP-Status, Content-Type der Antwort und um vertrauliche Angaben bereinigter Fehlerinhalt.
4. UTC-Zeitstempel, verstrichene Zeit und Anzahl der bisherigen Versuche.
5. Gewähltes Projekt sowie Angabe, ob Streaming oder Hintergrundausführung aktiviert war.
6. Interaktions- oder Anfragekennung, falls zurückgegeben; teilen Sie diese nur über den geeigneten Supportkanal.

Eine HTML-Seite mit Status 403 von einem Unternehmens-Gateway erfordert eine andere Untersuchung als eine JSON-Antwort mit permission_denied. Ebenso belegt eine Logzeile mit status=500 nicht, dass Google HTTP 500 zurückgegeben hat: Suchen Sie die tatsächliche Antwort des vorgelagerten Dienstes. Wenn überhaupt keine HTTP-Antwort einging, prüfen Sie zuerst DNS, TLS, Netzwerkverbindung und Client-Timeout, bevor Sie einen API-Fehlercode zuordnen.

Mit einer Minimalanfrage die Fehlerquelle eingrenzen

Googles Argon-Schnellstart verwendet die Modell-ID gemini-4-argon am Interactions-Endpunkt. Entfernen Sie für diese Diagnose Datei-Uploads, Tools, den bisherigen Gesprächszustand und zusätzliche Generierungseinstellungen. Verwenden Sie dasselbe Projekt wie die betroffene Anwendung.

Die folgende Vorlage erzeugt eine kostenpflichtige Anfrage über Ihr eigenes autorisiertes Konto. Wir haben sie nicht gegen Argon ausgeführt. Sie benötigen curl und einen lokal bereits als GEMINI_API_KEY verfügbaren API-Schlüssel. Fügen Sie den Schlüssel weder in ein Ticket noch in ein Repository ein. Die clientseitige Grenze von 90 Sekunden dient der Diagnose und ist keine von Google zugesagte Antwortzeit. Wird sie erreicht, bleibt der serverseitige Ausgang unbekannt.

umask 077
curl --silent --show-error \
  --connect-timeout 10 --max-time 90 \
  --request POST \
  'https://generativelanguage.googleapis.com/v1beta/interactions' \
  --header "x-goog-api-key: ${GEMINI_API_KEY:?Set GEMINI_API_KEY locally}" \
  --header 'Content-Type: application/json' \
  --data '{"model":"gemini-4-argon","input":"Reply with the word OK."}' \
  --dump-header argon-headers.txt \
  --output argon-response.json \
  --write-out 'HTTP %{http_code}; elapsed %{time_total}s\n'

Die Anfrage wird bewusst nicht automatisch wiederholt. Sichern Sie die Antwort einmal und ordnen Sie sie dann ein. Der curl-Exitcode null bedeutet lediglich, dass die Übertragung funktioniert hat. Prüfen Sie HTTP-Status und Antwortinhalt, bevor Sie den Modellaufruf als erfolgreich werten.

Funktioniert die Minimalanfrage, aber Ihre Anwendung nicht, fügen Sie die Funktionen einzeln wieder hinzu: zuerst den Gesprächszustand, dann Dateien, dann Tools und zuletzt eigene Generierungseinstellungen. Halten Sie in einer kleinen Tabelle fest, welche Funktion welchen Status ergibt. Die erste Ergänzung, die wieder scheitert, grenzt die Ursache ein. Wenn Sie Schlüssel, Modell, Nutzdaten und SDK zugleich ändern, verlieren Sie diese Vergleichsmöglichkeit.

Scheitern beide Anfragen, richten Sie den nächsten Prüfschritt am selben Fehlerinhalt aus. Ein erfolgreicher Aufruf eines anderen Modells belegt nur, dass dieses Modell unter diesen Bedingungen funktioniert hat. Er bestätigt weder die Berechtigung für Argon noch dessen Kompatibilität mit einer bestimmten Funktion.

Zum Fehler den passenden nächsten Prüfschritt wählen

Die folgenden Codes stammen aus der Fehlerreferenz der Interactions API. Andere Protokolle können andere Feldnamen verwenden. Wenden Sie einen OpenAI-Parser für choices oder einen älteren Parser für candidates nicht ohne Anpassung auf diese Antwort an.

Dies sind Wege zur Eingrenzung, keine Garantie dafür, dass eine bestimmte Änderung jede Antwort behebt. Ein Proxy kann beispielsweise den ursprünglichen Fehler ersetzen. Sein angezeigter Status 404 belegt dann nicht, dass Google die Modell-ID abgelehnt hat.

400 und 404 nach dem Wechsel von einem älteren Gemini-Client

Notieren Sie die zusammengehörigen Protokollangaben: Host, API-Version, Endpunkt, Anfrageschema und Antwortparser. Vergleichen Sie die gesamte Kombination mit der Dokumentation des Anbieters. Nur den Modellnamen in einem alten Workflow auszutauschen, reicht für eine vollständige Migration nicht aus.

Für Googles Interactions API nutzt das Minimalbeispiel oben model und input. Senden Sie dort keinen OpenAI-kompatiblen Body mit messages. Google unterstützt weiterhin die ursprüngliche generateContent-API, deren Anfrage- und Antwortformate sich jedoch unterscheiden. Die Interactions-Übersicht mit Migrationshinweisen erklärt den Unterschied. Eine funktionierende ältere Integration muss nicht allein deshalb neu geschrieben werden, weil eine Fehleranleitung einen neueren Endpunkt verwendet.

Die Modellspezifikation von Argon nennt Text als Ausgabeformat. Bild- und Audioverständnis bedeutet nicht Bild- und Audioerzeugung. Außerdem nennt sie implizites statt explizitem Caching und keine Unterstützung für die Live API. Benötigt Ihre fehlgeschlagene Anfrage eine dieser nicht unterstützten Funktionen, wählen Sie ein Modell oder eine Schnittstelle, für die diese Funktion dokumentiert ist. Ein anderer Modellname fügt keine Fähigkeit hinzu.

Entfernen Sie veraltete eigene Sampling-Einstellungen, wenn Sie Migrationsfehler eingrenzen. Laut Googles Fehlerbehebungsanleitung ignoriert Gemini 4 eigene Werte für temperature, top_p und top_k mit entsprechenden Warnungen; ihre Ablehnung ist für eine zukünftige Version vorgesehen. Behaupten Sie daher nicht, dass diese Einstellungen heute stets einen 400-Fehler auslösen. Verlassen Sie sich auch nicht darauf, Argon-Ausgaben durch eine höhere Temperatur zu reparieren.

Erfolgskontrolle: Die Minimalanfrage funktioniert, und nach einer dokumentierten Korrektur funktioniert auch die erste zuvor fehlschlagende Zusatzfunktion. Speichern Sie beide bereinigten Nutzlasten. Liefert bereits die Minimalanfrage weiterhin 404, fügen Sie keine weiteren Funktionen hinzu. Klären Sie zuerst, welche Route, Modell-ID oder Ressource nicht zusammenpasst.

429: Lastspitzen von ausgeschöpften Kontingenten unterscheiden

Google setzt Ratenlimits pro Projekt durch, nicht pro Schlüssel. Ein zweiter Schlüssel aus demselben Projekt schafft daher kein zusätzliches Kontingent. Prüfen Sie in AI Studio die aktiven Grenzen für das tatsächlich verwendete Projekt und Modell: Anfragen pro Minute, Eingabetokens pro Minute, Anfragen pro Tag sowie gegebenenfalls ausgabenbasierte Limits.

Betrachten Sie Fehlerdetails und Nutzungsverlauf gemeinsam. Ein plötzlich gestarteter Stapel kann ein kurzfristiges Limit überschreiten, obwohl die Tagesnutzung gering ist. Ein ausgeschöpftes Tageskontingent lässt sich nicht durch einen weiteren Versuch einige Sekunden später beheben. Tageskontingente für Anfragen werden um Mitternacht pazifischer Zeit zurückgesetzt; das ist kein allgemeiner Rücksetzzeitpunkt für alle 429-Fehler.

Bei Lastspitzen reduzieren Sie zunächst die Parallelität und stellen Aufträge in eine Warteschlange. Sind große Prompts die Ursache, reicht eine geringere Anfragezahl möglicherweise nicht aus, um den Tokendurchsatz ausreichend zu senken. Ist ein Kontingent ausgeschöpft, pausieren Sie den Auftrag bis zum betreffenden Reset oder einer genehmigten Kapazitätsänderung, statt ihn immer wieder einzureichen.

Eine praktikable Wiederaufnahmestrategie braucht drei Regeln:

• Nur eine Komponente steuert Wiederholungen. Prüfen Sie das Verhalten des SDKs, bevor Sie es in eine weitere Wiederholungsschleife einbetten.
• Bei vorübergehenden Fehlern wachsen die Wartezeiten mit einer zufälligen Streuung. Begrenzen Sie sowohl die Versuche als auch die Gesamtdauer. Beachten Sie eine vom Dienst angegebene Wartezeit, sofern vorhanden.
• Dauerhafte Zugangs-, Nutzlast- oder Zahlungsfehler führen zum Abbruch mit einer hilfreichen Meldung. Bei ausgeschöpftem Kontingent wird auf Kapazität gewartet, statt das Wiederholungsbudget für vorübergehende Fehler aufzubrauchen.

Für einen kleinen interaktiven Auftrag könnten Sie höchstens drei Versuche insgesamt innerhalb von zwei Minuten festlegen. Das ist ein Beispiel für eine Anwendungsregel, weder ein Google-Kontingent noch eine Empfehlung für jede Arbeitslast. Stapelverarbeitung benötigt eigene Zeit- und Ausgabengrenzen. Googles Hinweise zu Wiederholungen unterstützen begrenztes Backoff; sie machen weitere Versuche weder kostenlos noch garantieren sie einen Abschluss.

HTTP 200, aber keine Antwort: Abschluss und Ausgabe prüfen

Prüfen Sie erfolgreiche Übertragung und erfolgreiche Aufgabenerledigung getrennt. Lesen Sie bei Streaming die Ereignisse weiter und behandeln Sie auch Fehlerereignisse. Ein erfolgreicher anfänglicher HTTP-Status belegt nicht, dass der Stream vollständig beendet wurde. Speichern Sie bei Hintergrundausführung die Interaktions-ID und fragen Sie diese Interaktion erneut ab, statt bei jedem Polling einen identischen neuen Auftrag anzulegen.

Die Interactions-Ressource enthält Ausführungsschritte wie Tool-Aufrufe und Modellausgaben. Verwenden Sie beim SDK-Schnellstart das dokumentierte Hilfsfeld output_text. Wenn Sie unverarbeitetes JSON auswerten, richten Sie sich nach dem Schema des jeweiligen Endpunkts und der Version. Prüfen Sie alle relevanten Inhalte der Modellausgabe, statt den ersten Array-Eintrag automatisch für die endgültige Antwort zu halten.

Gehen Sie bei leerem sichtbarem Text in dieser Reihenfolge vor:

1. Läuft die Interaktion noch? Eine wartende oder laufende Interaktion ist keine abgeschlossene leere Antwort. Behalten Sie ihre ID und prüfen Sie den Status innerhalb der Frist Ihres Auftrags.
2. Wartet sie auf ein Tool? Ein gültiger Funktionsaufruf ist ein Arbeitsauftrag an Ihre Anwendung und nicht unbedingt Text für den Nutzer. Validieren Sie die Argumente und führen Sie den vorgesehenen Tool-Ablauf aus.
3. Blockiert oder fehlgeschlagen? Bewahren Sie den gemeldeten Grund auf. Passen Sie bei einer Sicherheitsbeschränkung die zulässige Aufgabe an oder erläutern Sie die Beschränkung. Bezeichnen Sie sie nicht als Ausfall und versuchen Sie keine Umgehung.
4. Budget- oder Parserproblem? Vergleichen Sie Nutzungsdaten, Abschlussdetails und Rohantwort mit der Anzeige in der Oberfläche. Argons Ausgabebudget umfasst Denkprozess und sichtbare Ausgabe. Eine unüberlegt sehr kleine Ausgabegrenze kann deshalb eine Denkaufgabe beeinträchtigen. Eine Erhöhung verändert aber auch die möglichen Kosten; prüfen Sie zuerst die Ursache.

Googles Argon-Anleitung dokumentiert Hintergrundausführung für lange Generierungen. Übernehmen Sie eine solche Konfiguration nicht in einen kurzen „OK“-Test. Läuft nach dem Absenden echter Arbeit der Client in ein Timeout, kann der Server weiterhin daran arbeiten. Greifen Sie möglichst auf die bestehende Interaktion zurück und prüfen Sie das Risiko doppelter Ausführung, bevor Sie einen Ersatzauftrag starten.

Erfolgskontrolle: Ihre Anwendung unterscheidet wartende Ausführung, Tool-Aktion, abgeschlossene Textausgabe sowie fehlgeschlagene oder blockierte Ergebnisse. Sie darf diese Zustände nicht sämtlich als leere Erfolgsmeldung anzeigen.

Fehlerbehandlung lokal testen, bevor die nächste Anfrage Kosten verursacht

Diese synthetische Übung prüft die Entscheidungen Ihrer Anwendung, ohne Googles aktuelle Verfügbarkeit nachzubilden. Spielen Sie die folgenden Fälle bei deaktivierten Netzwerkaufrufen durch Oberfläche und Fehlerbehandlung:

Dies sind Testszenarien, keine vollständigen API-Antwort-Fixtures. Erstellen Sie Testdaten passend zu Ihrer SDK- und API-Version. Prüfen Sie, dass Logs weder Schlüssel noch private Prompt-Inhalte enthalten und dass eine einzige Nutzeraktion nicht versehentlich sowohl eine Wiederholung als auch einen Fallback-Auftrag auslöst.

Wann ein Modellwechsel sinnvoll ist und was der Support benötigt

Ein Ersatzmodell hilft bei einer dringenden Aufgabe erst dann, wenn Sie geprüft haben, ob es Eingabetyp, Tools, Ausgabeschema und Kontextgröße unterstützt. Verwenden Sie einen kleinen, auf die Aufgabe abgestimmten Abnahmetest, kennzeichnen Sie den Modellwechsel und verhindern Sie doppelte Seiteneffekte, etwa das zweimalige Versenden derselben Nachricht. Leiten Sie private Dateien nicht an einen anderen Anbieter weiter, ohne die dafür geltenden Anforderungen an den Umgang mit Daten zu prüfen.

Prüfen Sie bei anhaltenden 5xx-Fehlern den Dienststatus von Google AI Studio. Ein Nutzerbericht oder eine einzelne eigene fehlgeschlagene Anfrage belegt keinen plattformweiten Ausfall. Scheitert eine Minimalanfrage weiterhin, senden Sie dem Anbieter einen bereinigten Vorfallsbericht:

UTC-Zeit und Zeitzone:
Anbieter / Host / Endpunkt / API-Version:
Modell-ID / SDK-Version:
Projektreferenz (nur über privaten Supportkanal):
HTTP-Status / Fehlercode / bereinigte Meldung:
Streaming oder Hintergrundausführung aktiviert:
Interaktions-ID, falls vorhanden:
Verstrichene Zeit / Gesamtzahl der Versuche:
Ergebnis der Minimalanfrage:
Erste wieder hinzugefügte Funktion, die scheitert:
Erwartetes Ergebnis / beobachtetes Ergebnis:

Lesen Sie den englischen Leitfaden zu Argons API-Preisen, bevor Sie Ausgabebudgets erhöhen oder wiederholt Testanfragen senden. Bei der Modellwahl hilft der englische Argon-Vergleich. Ofox veröffentlicht diese Anleitung; die direkte Google-Anfrage oben belegt keine Verfügbarkeit von Argon über Ofox. Prüfen Sie den aktuellen Modellkatalog und das unterstützte Protokoll eines Anbieters, bevor Sie Ihren Workflow umstellen.