Google hat den KI-Agenten im Terminal komplett neu geschrieben: eine Go-Binärdatei, und agy ist der Einstieg.

Mit einem Modell im Terminal gemeinsam Code zu schreiben ist keine neue Idee, aber Google hat den Zugang dazu geändert. Auf der Entwicklerkonferenz im Mai 2026 zog das Unternehmen seine verstreuten Entwicklerwerkzeuge unter einer einzigen Marke zusammen, und Antigravity CLI ist der terminalförmige Teil davon. Laut offizieller Ankündigung wurde der ältere Kommandozeilendienst, der kostenlose Einzelnutzer sowie Abonnenten der oberen beiden Stufen bedient hatte, Mitte Juni 2026 eingestellt; seither führt der Weg zu Googles Agenten aus einer Shell über diesen neuen agy-Einstieg.

Das ist nicht das alte Projekt unter neuem Namen. Sobald es läuft, ist es erkennbar eine andere Art von Werkzeug.

Eine Go-Binärdatei, keine Laufzeit vorab

Der Vorgänger war ein Node-Projekt, was bedeutete, dass zuerst eine Laufzeitumgebung vorhanden sein musste. Antigravity CLI wird als kompilierte Einzeldatei in Go ausgeliefert, sodass weder mit einem Paketmanager gerungen noch eine eigene Sprachlaufzeit daneben aufgebaut werden muss. Die unmittelbare Folge sind ein schneller Start und sehr wenig, wovon es abhängt.

Beim ersten Lauf wird eine Anmeldung mit einem Google-Konto verlangt, und die Zugangsdaten landen im Schlüsselbund des Systems, also im jeweiligen Speicher der drei Plattformen. In einer entfernten SSH-Sitzung gibt es keinen Browser zu öffnen, deshalb wird ein Autorisierungslink ausgegeben; man schließt die Anmeldung im Browser der eigenen Maschine ab und fügt den Code zurück. Die offizielle Dokumentation behandelt diesen Ablauf als vollwertigen Weg und nicht als nachgereichten Notbehelf, was für alle zählt, deren Arbeit auf einer entfernten Maschine liegt.

Ein Agentenkern, geteilt mit der Desktop-App

Antigravity hat inzwischen vier Gesichter: eine Desktop-Anwendung, dieses Kommandozeilenwerkzeug, ein SDK für den programmatischen Aufruf und eine IDE. Der offizielle Blog sagt es klar: CLI und Desktop-Version laufen auf demselben Agenten-Gestell und teilen ihre Einstellungen. Praktisch heißt das, eine auf der einen Seite eingestellte Rechtegel gilt auf der anderen sofort, und niemand pflegt zwei Erlaubnislisten.

Daraus folgt, dass Verbesserungen überall gleichzeitig ankommen. Wird die Werkzeuglenkung oder die Planungslogik im Kern aufgewertet, erhalten beide Oberflächen sie am selben Tag, und keine Kommandozeilenversion wartet auf eine Portierung. Sitzungen sind standardmäßig nicht gemeinsam, aber eine im Terminal eröffnete Sitzung lässt sich in die Desktop-App ziehen und dort fortsetzen.

Ein führender Agent vorn, Unteragenten parallel

Hier unterscheidet es sich am deutlichsten von früheren Kommandozeilenagenten. Die Dokumentation beschreibt eine mehrsträngige, asynchrone Architektur: langlaufende Builds, breite Codesuchen und Änderungen über viele Dateien werden an parallele Unteragenten oder Hintergrundaufgaben ausgegeben, statt das Terminal zu blockieren. Man kann weiter Code schreiben, eine neue Frage stellen, Dateien durchsehen, während die Hintergrundstränge ihre eigene Prüfung fahren.

Verwaltet werden diese Unteragenten über ein /agents-Panel, dessen Liste Kennung, Rolle, Zustand und den aktuell ausgeführten Schritt zeigt, mit einem vollständigen Denkprotokoll eine Ebene tiefer. Braucht ein Werkzeug eine Freigabe, blinkt die Statuszeile: Eine Tastenkombination springt aus dem laufenden Gespräch direkt in die Details des nächsten wartenden Unteragenten, eine andere gibt frei, ohne den Bildschirm zu verlassen. Eigene spezialisierte Agenten lassen sich ebenfalls definieren, für feste Rollen wie Codereview oder Continuous Integration.

Die mitgelieferten Schrägstrichbefehle sind um die Frage herum gebaut, wie viel Autonomie man abgeben will. Einer ist ein Modus mit freier Hand: Ziel übergeben, der Agent zerlegt es, genehmigt seinen eigenen Umsetzungsplan und arbeitet, bis das Ziel erreicht ist. Ein anderer dreht die Richtung um und lässt den Agenten so lange nachfragen, bis die Anforderung klar ist, bevor er etwas anfasst, was zu unscharfen Grenzen oder zerstörerischen Schritten passt. Ein dritter verwaltet Zeitpläne, entweder als einmalige Verzögerung oder als wiederkehrendes Intervall, etwa stündlich zu prüfen, ob der Build noch durchgeht.

Die Terminal-Sandbox: verschlossen, bevor es losgeht

Eine KI Befehle auf der eigenen Maschine ausführen zu lassen, braucht eine Bremse. Die Sandbox hier leiht sich die Isolation, die das Betriebssystem ohnehin mitbringt, und spart damit die Kosten einer zusätzlichen Schicht aus virtueller Maschine oder Container, sodass der Start praktisch unbemerkt bleibt.

Konkret steuert jede Plattform ihren eigenen nativen Mechanismus bei: eine Sandbox-Einrichtung unter macOS, eine Jail unter Linux, einen App-Container unter Windows. Ist sie in den Einstellungen aktiv, laufen die Befehle des Agenten abgeschirmt in der isolierten Umgebung und getrennt vom echten Dateisystem.

Die Werkzeuggestattungen sind in Stufen einstellbar. Die Voreinstellung fragt vor jeder Aktion, die System- oder Projektdateien betrifft, und kann den Befehl dabei gleich dauerhaft erlauben. Eine strengere Stufe gibt nur lesende Werkzeuge frei. Eine dritte erlaubt automatische Ausführung, aber ausschließlich innerhalb der Sandbox. Die letzte lässt alles durch und gehört in ein Repository unter Versionskontrolle. Ein Arbeitsbereich muss außerdem gesondert als vertrauenswürdig bestätigt werden, und der erste Besuch eines Verzeichnisses stellt genau diese Frage.

Kostenlos nutzbar, aber das Kontingent kennen

Die persönliche Nutzung beginnt bei null. Die kostenlose Stufe ist kein befristeter Test, sondern ein dauerhaftes Grundkontingent, und sie ist funktional nicht beschnitten: die Kernmodelle sind alle erreichbar. Darüber liegen zwei Abostufen mit größeren Kontingenten, und die höchste öffnet zusätzlich Fremdmodelle. Ein Ausprobieren kostet zunächst nichts.

Eines sollte man vorher wissen. Das kostenlose Kontingent erfrischt sich zyklisch, die offizielle Formulierung zu genauen Zahlen bleibt vage und spricht von einem Rahmen verfügbarer Rechenkapazität, und es gibt keine Zusage, dass diese Stufe dauerhaft bestehen bleibt. Parallele Unteragenten zehren gleichzeitig am Kontingent, und ein locker formuliertes Ziel kann ein Dutzend oder mehr Modellaufrufe auslösen, sodass es schneller leerläuft als erwartet. Wer das zum Alltagswerkzeug machen will, sollte erst den eigenen Verbrauchsrhythmus kennen, statt mitten in einer Aufgabe trockenzulaufen.

Umzug vom alten Einstieg

Bestandsnutzer beginnen nicht bei null. Eine Importfunktion ist eingebaut: Erweiterungen des Vorgängers werden zu Plugins hier, und Skills, MCP-Server sowie Hooks lassen sich größtenteils mitnehmen. Versionsinformationen stehen in einem Changelog-Befehl, die Befehlsliste ist einen Hilfe-Befehl entfernt. Zwei Stellen Stolpern. Arbeitsbereichs-Skills müssen in ihr neues Verzeichnis verschoben werden, und ohne Umzug erscheinen sie einfach nicht, ohne dass ein Fehler gemeldet wird. Kontextdateien sind der leichte Teil: die bestehende funktioniert weiter.

Erwähnenswert ist, dass dies eine Migration und kein Versionssprung ist: Die Binärdatei hat gewechselt, die Authentifizierung hat gewechselt, das Plugin-Modell hat gewechselt. Wer Skripte oder Pipelines hat, die den alten Kommandozeileneinstieg aufrufen, muss diesen Teil von Hand durchgehen.

Außerdem ist das Werkzeug derzeit quellgeschlossen, veröffentlicht werden nur Dokumentation und Änderungsprotokoll. Das ist ein Unterschied zu dem offenen Projekt, das es ersetzt, und wer das wichtig findet, sollte es vorher wissen.

Antigravity CLI will nicht Code für dich schreiben, sondern den Ablauf im Terminal selbst organisieren. Eine Go-Binärdatei nimmt die Umgebungslast weg, ein geteilter Kern hält es mit der Desktop-Version im Gleichschritt, und parallele Unteragenten plus Terminal-Sandbox legen sowohl das Loslassen als auch das Zurückholen offen auf den Tisch. Ob die kostenlose Stufe reicht, hängt von der Größe der Aufgabe ab, und ein echtes Projekt sagt mehr als jede Bewertung.