Google ersetzt Antigravity Agent 05-2026: Was vor der geplanten Abschaltung am 5. Oktober ausfallen kann

Was Google angekündigt hat und welches Datum beobachtet werden muss

Die Gemini-API-Dokumentation verzeichnet die Veröffentlichung von `antigravity-preview-09-2026` am 17. September 2026 und stellt diese Version als Ersatz für `antigravity-preview-05-2026` dar, das zur Einstellung markiert ist. Die Änderung ist insbesondere für Teams relevant, die Agenten mit Tool-Ausführung bauen, und nicht nur für diejenigen, die vom Modell eine Textantwort anfordern.

Die Google-Tabelle zu Einstellungen nennt den 5. Oktober 2026 als frühestmöglichen Termin für die Abschaltung von `antigravity-preview-05-2026` und empfiehlt die Migration zu `antigravity-preview-09-2026`. Diese Formulierung ist wichtig: Die Tabelle entspricht nicht zwingend einer Bestätigung der konkreten Uhrzeit, zu der die Version für jedes Konto oder jede Umgebung nicht mehr verfügbar sein wird. Google gibt an, den genauen Termin vorab mitzuteilen.

Operativ sollte dies daher nicht so gelesen werden, als sei Zeit bis zum Ende dieses Tages garantiert. Vielmehr sollten die Tests vor diesem Stichtag abgeschlossen sein. Außerdem empfiehlt es sich, den aktuellen Stand der Einstellungsdokumentation unmittelbar vor dem Deployment zu prüfen, falls es Aktualisierungen, Verschiebungen oder Verfügbarkeitspräzisierungen gibt, die in den geprüften Informationen noch nicht enthalten sind.

Der Ersatz belegt für sich genommen keine Verbesserung bei Qualität, Sicherheit, Kosten, Latenz oder Autonomie. Die Quellen beschreiben einen Versionswechsel und Änderungen an der Tool-Schnittstelle; sie liefern keinen experimentellen Vergleich beider Versionen in diesen Punkten. Diese Unterscheidung verhindert, dass eine Kompatibilitätsmigration als nicht belegte Leistungsbehauptung dargestellt wird.

Zwei Migrationspfade abhängig davon, wie die Antwort genutzt wird

Google unterscheidet ausdrücklich einen einfachen Übergangsfall: einen Ablauf in einer Remote-Sandbox, der ausschließlich `output_text` oder `model_output` verarbeitet. Unter dieser Voraussetzung kann es laut Dokumentation genügen, die Zeichenfolge zu ändern, die den Agenten identifiziert. Das ist eine eng gefasste Bedingung: Sie setzt voraus, dass die Anwendung die während der Interaktion auftretenden Tool-Aufrufe weder selbst auswertet noch ausführt.

Der zweite Fall umfasst Integrationen mit höherem Kompatibilitätsrisiko: Agenten, die in einer lokalen Umgebung arbeiten, Anwendungen, die `function_call` empfangen oder verarbeiten, Systeme, die eine Aktionsspur rekonstruieren, oder Plattformen, die Argumente validieren, bevor sie eine Operation genehmigen. In diesen Fällen ist der Versionsbezeichner nur ein Teil der Migration. Der Consumer muss den Tool-Vertrag der neuen Version akzeptieren.

Daneben gibt es Zwischenfälle. Ein Dienst kann eine Remote-Umgebung verwenden und dennoch Events für Audits speichern, Metriken nach Tool-Namen erzeugen, Berechtigungsrichtlinien anwenden oder Tests mit simulierten Antworten durchführen. Wenn eine dieser Komponenten von bisherigen Namen oder Argumenten abhängt, muss sie als Trace-sensitive Integration behandelt werden, auch wenn das Endprodukt überwiegend Text anzeigt.

Bevor ein Fall als einfach eingestuft wird, sollte das Team feststellen, wo `output_text`, `model_output`, Funktionsaufrufe und Tool-Ergebnisse gelesen werden. Diese Prüfung sollte SDK-Adapter, Event-Warteschlangen, Protokolle, automatische Evaluatoren und interne Dashboards einschließen. Das Ausbleiben von Fehlern in der Konversationsoberfläche belegt nicht, dass es in unterstützenden Diensten keine Abhängigkeiten gibt.

Welche Vertragsänderungen eine Integration beschädigen können

Die Release-Note beschreibt Änderungen an Dateisystem-Tools. Dazu gehören Namensänderungen und eine PascalCase-Konvention für dokumentierte Argumente. Für einen Consumer, der Literale vergleicht, gegen ein striktes Schema deserialisiert oder Berechtigungen aus Feldnamen ableitet, kann diese Änderung zu Ablehnungen führen, obwohl die Anfrage an den Agenten weiterhin gültig ist.

Die Dateibearbeitung ist ein besonderer Bruchpunkt. Die Dokumentation der neuen Version beschreibt Ersetzungen über Zeilenbereiche, während die vorherige Version vollständige Umschreibungen verwendete. Ein lokaler Executor, der erwartet, den vollständigen Ersatzinhalt zu erhalten, kann eine begrenzte Bearbeitung möglicherweise nicht anwenden. Umgekehrt kann das Umwandeln einer Bereichsbearbeitung in eine vollständige Umschreibung ohne Kontrollen gleichzeitige Änderungen überschreiben oder Zeilenenden verändern.

Das Update führt zudem neue Tools für die Dateisuche ein. Ihre Existenz verpflichtet nicht jede Anwendung dazu, sie zu nutzen. Sie kann jedoch Allow-Lists für Tools, Autorisierungsmechanismen und Mocks beeinflussen, die nur die Operationen der vorherigen Version vorsehen. Ein System, das ein unbekanntes Tool standardmäßig ablehnt, kann eine Aufgabe stoppen, die zuvor mit einer anderen Abfolge von Aktionen abgeschlossen wurde.

Die exakten Namen und die Groß- und Kleinschreibung sollten nicht aus alten Beispielen abgeleitet oder ohne Test normalisiert werden. Der aktuelle technische Leitfaden zeigt Dateisystem-Tools als Funktionsaufrufe. Bei einer lokalen Integration muss der Vertrag Ende zu Ende überprüft werden: empfangenes Event, Validierung, Autorisierung, Ausführung, Serialisierung des Ergebnisses und Fortsetzung der Interaktion.

Tests zur Erkennung von Fehlern, die eine Textantwort nicht sichtbar macht

Der nützlichste Test besteht nicht darin, den Agenten zu fragen, ob er eine Aufgabe erledigen kann, sondern repräsentative Aufgaben auszuführen und jeden Schritt zu prüfen. Eine Mindestsuite sollte das Erstellen von Dateien, das Lesen von Inhalten, das Auflisten von Verzeichnissen, lokalisierte Bearbeitungen und die Suche enthalten. Wenn das Produkt Änderungen erlaubt, ergänzen Sie Fälle mit unzureichenden Berechtigungen, ungültigen Pfaden, fehlenden Dateien und Bearbeitungskonflikten. Die erwarteten Ergebnisse müssen sowohl die Ausgabe für Nutzende als auch Events und den finalen Zustand der Umgebung abdecken.

Erfassen Sie, soweit die Testumgebung dies zulässt, Traces einer vergleichbaren Stichprobe mit beiden Versionen. Es geht nicht darum zu verlangen, dass die Abfolge identisch ist: Neue Tools können sie verändern. Ziel ist zu prüfen, dass der Adapter jeden autorisierten Aufruf interpretieren und ausführen kann, dass die Ergebnisse im erwarteten Format zum Agenten zurückkehren und dass die Aufgabe einen korrekten Zustand erreicht.

Mocks verdienen eine separate Prüfung. Sie kodieren häufig den bisherigen Vertrag implizit: Funktionsnamen, Schreibweise von Feldern, Argumentstruktur oder den vollständigen Inhalt einer Datei. Ein Mock, der weiterhin nur den alten Vertrag akzeptiert, kann Fehler verbergen; ein übermäßig großzügiger Mock kann Aufrufe bestehen lassen, die der echte Executor ablehnen würde. Es empfiehlt sich, Simulationen aus erfassten Traces abzuleiten und negative Fälle beizubehalten.

Die Instrumentierung sollte die angeforderte Version, den Umgebungstyp, die empfangenen Aufrufe, die Autorisierungsentscheidung und das Ausführungsergebnis erfassen, ohne unnötig sensible Inhalte zu speichern. Diese Informationen helfen, ein Vertragsproblem von einer Berechtigungsverweigerung, einem Umgebungsfehler oder einer unerwarteten Modellantwort zu unterscheiden.

Kosten, Verfügbarkeit und Grenzen der möglichen Schlussfolgerungen

Die Preisdokumentation der Gemini Developer API gibt an, dass Antigravity Agent die Inferenz, einschließlich der Zwischentokens agentischer Schleifen, nach den Standardtarifen von Gemini abrechnet. Sie gibt außerdem an, dass die Umgebungsausführung während der Vorschau nicht berechnet wird. Daraus lassen sich die Kosten einer konkreten Arbeitslast nicht berechnen: Sie hängen von den Modellen, dem Token-Volumen, der Dauer und dem tatsächlichen Verhalten der Aufgaben ab.

Diese Information darf auch nicht auf Zugangskanäle übertragen werden, die die bereitgestellten Quellen nicht als gleichwertig beschreiben. Die geprüften Informationen beziehen sich auf die Gemini API und belegen nicht, dass Verfügbarkeit, Kontingente, Nutzungsbedingungen oder Zeitplan in Vertex AI oder über andere Wege identisch sind. Teams mit einer mehrkanaligen Abstraktionsschicht sollten den tatsächlichen Anbieter jedes Deployments bestätigen, bevor sie diese Nachricht als allgemeine Regel anwenden.

Die analysierte Dokumentation erlaubt die Schlussfolgerung, dass es für einen sehr konkreten Remote-Fall einen einfachen Wechselpfad gibt und dass es relevante Schnittstellenänderungen für Tool-Consumer gibt. Sie erlaubt nicht die Schlussfolgerung, dass alle Remote-Agenten gegen die Änderung immun sind, dass eine lokale Migration mechanisch abläuft oder dass beide Versionen bei jeder Aufgabe funktional gleichwertige Ergebnisse liefern.

Als praxisorientierte Maßnahme sollte dieser Ersatz vorrangig als Vertragsmigration behandelt werden. Das Ändern des Versionsnamens kann genügen, wenn ausschließlich die Textausgabe im von Google beschriebenen Remote-Szenario genutzt wird. In jeder Integration, die Tools beobachtet, validiert oder ausführt, sollte die Entscheidung auf Traces und Regressionstests beruhen, nicht auf der scheinbaren Kontinuität des Gesprächs.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.