KI-Modelle und Plattformen
Google Antigravity führt Orchestrator für dynamische Modellwechsel ein
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
Google Antigravity teilte mit, dass Orchestrator, eine Option im Modellauswahlmenü, die für Google AI Ultra-Abonnenten eingeführt wird, bei Terminal-Bench 4.1 eine nahezu so hohe Aufgabenerfolgsquote wie Carbon erzielte und dabei durchschnittlich 24 % weniger Kontingent verbrauchte sowie Aufgaben 19 % schneller abschloss, indem innerhalb einer Sitzung dynamisch zwischen Gemini 4 Carbon und Gemini 4 Hydrogen gewechselt wurde.
Das neue Hydrogen-Modell wird in Antigravity separat für zahlende Google-AI-Pro- und Ultra-Abonnenten eingeführt. Unternehmen können über Gemini for business auf beide Modelle zugreifen. Google zufolge werden Orchestrator künftig auch weitere Modelle und Abonnements unterstützen. Hydrogen beschreibt das Unternehmen als Gegenstück zu Carbon und Argon, das auf schnelle Ausführung statt auf deren tiefergehendes Schlussfolgern über längere Zeiträume ausgelegt ist.
Dynamische Modellwechsel innerhalb einer Sitzung
Orchestrator ist auf die routinemäßige Entwicklung von Funktionen und die Fehlersuche ausgelegt. Dabei kann es die Iteration verlangsamen und das Kontingent für Spitzenmodelle aufbrauchen, wenn während einer Sitzung durchgehend ein führendes Schlussfolgerungsmodell und mehrere parallel arbeitende Agenten zum Einsatz kommen. Ein herkömmlicher statischer Router schätzt stattdessen anhand der anfänglichen Eingabeaufforderung den Schwierigkeitsgrad ein und weist die gesamte Aufgabe anschließend dem günstigsten Modell zu, das er für ausreichend hält. Laut Google eignet sich eine solche einmalige Zuweisung schlecht für lang laufende Agenten, da sich die Anforderungen einer Aufgabe ändern können und erst während ihrer Ausführung deutlich werden.
Orchestrator kann im Verlauf einer Aufgabe in beide Richtungen zwischen den zwei Modellen wechseln. In Googles Beispiel untersucht Carbon zunächst Abhängigkeiten, ohne Änderungen vorzunehmen, klärt Unklarheiten und erstellt einen Plan mit ausdrücklich festgelegten Bedingungen, bei deren Eintreten der Plan neu erstellt werden soll. Anschließend setzt Hydrogen Änderungen um, aktualisiert Pakete und führt Tests aus. Wenn Hydrogen auf Schwierigkeiten stößt, übernimmt Carbon wieder die Kontrolle, prüft den aktuellen Stand, korrigiert den Plan und setzt die Ausführung fort. So kann eine Sitzung für die Planung oder die Behebung von Problemen auf tiefergehendes Schlussfolgern zurückgreifen, ohne jeden Umsetzungsschritt demselben Modell zuzuweisen.
Explizite Modellrollen über das SDK
Entwickler, die statt eines automatischen Wechsels eine explizite Zuweisung wünschen, können Hydrogen und Carbon über das Antigravity SDK miteinander verbinden. Dadurch können sie programmgesteuert festlegen, welches Modell in einem Arbeitsablauf mit mehreren Agenten welche Rolle übernimmt.
In Googles Demonstration zur Triage von Issues in einem Open-Source-Projekt bearbeiten Hydrogen-Agenten die eingehenden Issues: Sie priorisieren sie und programmieren, durchsuchen die Codebasis, stellen Rückfragen und arbeiten Änderungen an der Benutzeroberfläche auf Grundlage von Kommentaren zu Pull Requests aus. Ein Carbon-Agent übernimmt umfangreichere Refaktorierungen, neue Funktionen und Sicherheitsprüfungen. Die Demonstration folgt derselben grundsätzlichen Aufteilung zwischen schneller Ausführung und tiefergehender Schlussfolgerung. Die Grenzen legt jedoch der Entwickler fest, statt sie Orchestrator zu überlassen.
Wie sich Orchestrator von /Swarm unterscheidet
Orchestrator folgt auf die am 10. November 2026 vorgestellte Vorschau von Gemini 4 Carbon und /swarm, die auf Entwicklungsaufgaben über viele Dateien und Testsammlungen hinweg abzielte. Laut der /swarm-Dokumentation kann ein Koordinator eine Aufgabe auf benannte Mitarbeiter aufteilen, die jeweils separate Dateien, Pakete oder Fragen bearbeiten, während Prüfer Änderungen durchsehen und Tests ausführen. Mitarbeiter können außerdem isolierte Arbeitskopien eines Repositorys erhalten. Orchestrator ist auf eine andere Arbeitsweise ausgelegt: Statt ein Team zu bilden, das unabhängig voneinander an verschiedenen Teilaufgaben arbeitet, wechselt es das verwendete Modell im Verlauf einer einzelnen Sitzung, während sich die Aufgabe weiterentwickelt.
Zusammen ermöglichen die Funktionen zwei unterschiedliche Aufteilungen agentengestützter Arbeit: auf mehrere Agenten, wenn sich ein Projekt in Teilaufgaben zerlegen lässt, und auf mehrere Modelle, wenn ein Gespräch zwischen Planung, Ausführung und Fehlerbehebung wechselt. Die praktische Veränderung besteht darin, dass die Wahl des Modells nicht mehr eine einmalige Entscheidung zu Beginn der Eingabeaufforderung sein muss. Sie kann Teil der Arbeitsablaufarchitektur werden – entweder adaptiv mit Orchestrator oder durch ausdrückliche Zuweisung über das SDK.
