Gemini 4 Carbon und Hydrogen funktionieren am besten als Team: Carbon plant, Hydrogen baut. Übertragen Sie einem Planer-Agenten auf Carbon den Task, lassen Sie ihn Teilaufgaben mit Akzeptanzkriterien formulieren, übergeben Sie diese an Worker- und Verifier-Agenten auf Hydrogen und leiten Sie alles, was zweimal fehlschlägt, an den Planer zurück. So zahlen Sie Frontier-Preise nur für die Durchläufe, die wirklich fundiertes Urteilsvermögen auf Frontier-Niveau verlangen.
Warum Gemini 4 Carbon und Hydrogen überhaupt kombinieren?
Google hat Gemini 4 Hydrogen am 12. November 2026 veröffentlicht und als „Daily Driver für agentische Workflows“ bezeichnet. Zwei Tage zuvor, am 10. November, wurde Gemini 4 Carbon im Gemini API-Changelog als allgemein verfügbar (Generally Available) aufgeführt. Damit können Sie in diesem Monat zum ersten Mal Googles leistungsstärkstes Modell und sein schnelles Ausführungsmodell hinter denselben Task schalten.
Googles eigenes Plädoyer für Hydrogen stützt sich genau auf diese Kombination. Im Launch-Beitrag heißt es, Carbon könne als Koordinator fungieren, während Hydrogen „Worker- und Verifier-Agenten antreibt, um Änderungen simultan über isolierte Workspaces hinweg zu erstellen und zu testen“. Der Gemini API-Leitfaden bringt es noch deutlicher auf den Punkt: Lassen Sie Carbon Schnittstellen planen oder hartnäckige Hindernisse lösen und delegieren Sie Code-Änderungen, parallele Subagenten-Aufgaben und Testläufe an Hydrogen.
Das ist ein Orchestrierungsmuster, keine Modellfunktion – und Sie können es noch heute auf Ihrem eigenen Board umsetzen. Wenn dieses Muster auf einem zentralen Board statt in einem lokalen Skript auf einem einzelnen Laptop liegen soll, ist Sharkly der Ort, an dem Tasks, Agents und Reviews zusammenlaufen.
Was Googles Orchestrator leistet – auf den Punkt gebracht
Orchestrator ist eine Modelloption in Google Antigravity, die innerhalb einer Konversation zwischen einem Planer (Carbon oder Argon) und Hydrogen wechselt. Laut der Antigravity-Dokumentation beginnt der Planer mit einer schreibgeschützten Phase (Read-Only), erstellt einen Plan mit expliziten Triggern für eine Neuplanung und übergibt die Ausführung an Hydrogen. Hydrogen gibt die Kontrolle zurück, sobald Reibungsverluste oder Blockaden auftreten.
Die Dokumentation nennt drei Signale für solche Blockaden, die es wert sind, übernommen zu werden:
- Ein Verifizierungsschritt schlägt zweimal fehl.
- Eine Schnittstelle verhält sich anders als im Plan erwartet.
- Eine Architekturentscheidung wurde im Plan nicht geklärt.
Google berichtet, dass Orchestrator auf Terminal-Bench eine Erfolgsquote nahe an Carbon erzielte – bei 24 % weniger Quotenverbrauch und durchschnittlich 19 % schnellerer Ausführung. Die beiden Beiträge von Google widersprechen sich hinsichtlich der Benchmark-Version (der Launch-Beitrag nennt Version 4.0, der Antigravity-Beitrag Version 4.1); zitieren Sie es daher einfach als Terminal-Bench, bis Google den Widerspruch auflöst.
Orchestrator hält einen einzelnen Agenten in Ihrer Konversation, läuft mit einer festen Konfiguration ohne Kontrolle über das Thinking-Level und ist in seiner Carbon-Variante ausschließlich für Google AI Ultra gelistet. Ein Team-Board verteilt diese Aufteilung hingegen auf mehrere Agents, sodass Plan und Übergaben für alle transparent sichtbar bleiben.
Der Kostenfaktor: Preise von Gemini 4 Hydrogen vs. Carbon
Token-Preise laut der Gemini API-Preisseite, Stand: 13. November 2026:
| Modell | API-Modell-ID | Input / 1 Mio. | Output / 1 Mio. | Free Tier |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
2,00 $ bis 30. Nov., danach 4,00 $ | 10,00 $ bis 30. Nov., danach 20,00 $ | Nein |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
1,50 $ | 7,50 $ | Ja, ratenlimitiert |
Prüfen Sie die Daten genau, bevor Sie darauf ein Budget aufbauen: Bis zum 30. November ist Hydrogen pro Token lediglich 25 % günstiger als Carbon. Ab dem 1. Dezember sind es 62,5 %. Beide Werte basieren auf unseren eigenen Berechnungen anhand von Googles Listenpreisen.
Was das für einen einzelnen Durchlauf bedeutet – ebenfalls basierend auf unseren Berechnungen: Nehmen wir einen Worker-Durchlauf, der 200.000 Token liest und 40.000 schreibt (der Output schließt Thinking-Token ein). Bei Carbon entspricht das nach dem 1. Dezember 0,80 $ + 0,80 $ = 1,60 $. Bei Hydrogen sind es 0,30 $ + 0,30 $ = 0,60 $. Rechnet man das auf 30 Durchläufe pro Tag über einen Sprint hoch, ist der Unterschied längst kein Rundungsfehler mehr.
Der reine Token-Preis unterschätzt diesen Unterschied sogar noch. Google gibt an, dass Carbon „pro Durchgang mehr Thinking-Token aufwendet, um Hypothesen zu testen und Randfälle zu verifizieren“, und die Output-Preise schließen Thinking-Token mit ein. Dieselbe Code-Änderung schlägt bei Carbon also voraussichtlich nicht nur mit einem höheren Tarif, sondern auch mit mehr Output-Tokens zu Buche. Google veröffentlicht keine Kosten pro Task für dieses Modellpaar; messen Sie den Verbrauch daher an Ihrem eigenen Repository, bevor Sie Einsparungen prognostizieren.
Die Geschwindigkeit ist die andere Seite der Medaille: Laut Google erledigt Hydrogen Aufgaben 2,5-mal schneller als Gemini 3.8 Flash auf dessen Standardstufe high.
Aufgaben im Agenten-Team aufteilen: Rollen passend zum Modell
Eine Planer/Worker-Aufteilung ist eine klar definierte Arbeitsteilung: Ein Agent übernimmt den Plan und die schwierigen Entscheidungen, kostengünstigere Agenten kümmern sich um die Ausführung, und ein Verifier überprüft das Ergebnis, bevor es einem Menschen vorgelegt wird. Jede Rolle erhält das Modell, dessen Kosten und Tiefe optimal zur Aufgabe passen.
| Rolle | Modell | Thinking-Level | Verantwortungsbereich |
|---|---|---|---|
| Planer | gemini-4-carbon |
Standard medium, high für anspruchsvolle Tasks |
Codebasis analysieren, Teilaufgaben mit Akzeptanzkriterien formulieren, Neuplanung |
| Worker (1 bis n) | gemini-4-hydrogen |
high (Standard) |
Code-Änderungen, Paket-Updates, Tests, jeweils eine Teilaufgabe |
| Verifier | gemini-4-hydrogen |
high, xhigh für riskante Diffs |
Prüfungen anhand der Akzeptanzkriterien des Planers durchführen |
| Mensch | n/a | n/a | Plan bei großen Tasks freigeben, Ergebnis abnehmen |
Zwei Details aus Googles Dokumentation liegen dieser Tabelle zugrunde: Carbon und Argon nutzen standardmäßig medium und sind bei high gedeckelt, während Hydrogen standardmäßig auf high läuft und zusätzlich xhigh bietet. Zudem warnt Google davor, dass xhigh die Latenz sowie den Token-Verbrauch erhöht und „bei einfacheren Prompts zu Overthinking führen kann“. Reservieren Sie xhigh beim Verifier für Diffs, die Authentifizierung, Zahlungsabwicklung oder Datenmigrationen betreffen.
Was sollte der Planer schreiben?
Das Ergebnis des Planers ist der verbindliche Vertrag für alle nachgelagerten Schritte. Ein guter Plan enthält genau eine Teilaufgabe pro unabhängiger Änderung, einen definierten Datei-Scope für jede davon, den Befehl zur Funktionsprüfung und die Bedingung für eine Rückmeldung. Wenn ein Worker nicht eindeutig feststellen kann, wann die Arbeit abgeschlossen ist, ist der Plan noch nicht fertig.
Wann geht die Arbeit zurück an den Planer?
Übernehmen Sie Googles Trigger-Liste und machen Sie sie explizit. Ein Worker gibt eine Teilaufgabe zurück, wenn dessen Prüfung zweimal fehlschlägt, eine Schnittstelle nicht zum Plan passt oder eine Architekturentscheidung getroffen werden muss. Die Rückgabe erfolgt mit dem Log, dem bisherigen Diff und der offenen Frage. Ein stillschweigender Neuversuch mit einem größeren Modell findet niemals statt – denn das würde die Kosten der günstigen Stufe in der Rechnung der teuren verschleiern.
Einrichtung in Sharkly
In Sharkly ist ein Agent ein KI-Teamkollege, der über eine Runtime auf einem verbundenen Computer läuft, und eine Crew ist eine Gruppe von Agents und Menschen, die von einem leitenden Agenten koordiniert wird. Das bildet die Planer/Worker-Aufteilung ganz ohne Glue-Code ab. Der Planer fungiert als Crew Leader; die Worker und der Verifier sind Crew Members.
Jeder Agent verfügt über eine eigene Runtime und ein Default-Modell, wie im Bedienfeld oben dargestellt (dieses nutzt Claude Code). Geben Sie für dieses Setup jedem Agenten eine Runtime, die die Gemini API erreichen kann (beispielsweise die Gemini CLI), und legen Sie das Modell pro Agent fest: Carbon für den Planer, Hydrogen für die restlichen Agenten. Falls die Modellliste die neuen IDs noch nicht anzeigt, konfigurieren Sie das Modell direkt in den Einstellungen der Runtime. Die Gemini CLI unterstützt laut ihrer Konfigurationsreferenz auch eine Umgebungsvariable GEMINI_MODEL, und Agents unterstützen agentenspezifische Umgebungsvariablen.
Hinterlegen Sie anschließend die Koordinationsregeln in den Crew-Anweisungen:
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
Weisen Sie den Task der Crew zu. Die Ausführung erfolgt nach dem „Leader-first“-Prinzip gemäß der Crews-Dokumentation: Der Leader liest den Task und die Crew-Anweisungen, erwähnt anschließend Mitglieder für spezifische Beiträge, und deren Ergebnisse fließen in denselben Task zurück. Nutzen Sie temporäre Arbeitsverzeichnisse, damit jeder Worker einen eigenen Worktree erhält. Aktivieren Sie das geteilte Task-Verzeichnis der Crew nur dann, wenn Teilaufgaben der Reihe nach auf den lokalen Änderungen der jeweils anderen aufbauen müssen.
Blockierte Arbeiten bleiben sichtbar: Fehlgeschlagene oder blockierte Durchläufe landen in der Inbox, und ein Agent, der auf eine menschliche Rückmeldung wartet, erscheint in den Task-Chats der Seitenleiste. Genau dort landet der gestrichelte Pfeil, wenn der Planer den Plan nicht selbstständig korrigieren kann.
Fortgeschrittene Techniken
Modellwechsel per API für einen langen Task nutzen. Laut Google-Dokumentation können Sie in einer einzelnen Multi-Turn-Sitzung mithilfe von previous_interaction_id ohne Schemaänderungen Planungsdurchläufe an gemini-4-carbon und Ausführungsschritte an gemini-4-hydrogen leiten. Das ist der Trick des Orchestrators im eigenen Code – nützlich innerhalb eines einzelnen Agenten-Laufs.
Maximale Antwortgrößen beachten. Hydrogen liefert bis zu 65.536 Token pro Non-Streaming-Hop zurück, während Carbon und Argon bei Non-Streaming-REST-Hops auf 32.768 Token begrenzt sind. Belassen Sie umfangreiche Generierungen, wie Test-Suites oder Migrationsspezifikationen, daher auf der Worker-Seite.
Kein explizites Caching bei Hydrogen. Hydrogen unterstützt kein explizites Context Caching. Implizites Caching greift bei Prompts ab 4.096 Token und reduziert die Kosten für gecachten Input um 95 % – platzieren Sie den gemeinsamen Repository-Kontext daher an den Anfang jedes Worker-Prompts.
Alternativen zum Planer/Worker-Modell
- Hydrogen allein. Googles Dokumentation empfiehlt dies für Paket-Upgrades, Deduplizierung, Scaffolding, Unit-Tests für klar definierte Funktionen und Dokumentation. Hierfür ist kein Planer erforderlich.
- Carbon allein. Für das Design verteilter Systeme, Race Conditions oder Multi-Repository-Migrationen, bei denen jeder Schritt tiefes Verständnis erfordert.
- Orchestrator in Antigravity. Eine Person, eine Konversation, automatische Übergaben – bei Plänen, die dies beinhalten.
- Ein statischer Router. Den Task vorab klassifizieren und an ein einzelnes Modell senden. Google argumentiert, dass dieser Ansatz bei längeren Abläufen scheitert, da sich der Schwierigkeitsgrad mitten im Task ändern kann. Die Vorab-Klassifizierung haben wir im Artikel Agenten-Tasks mit der Gemini Decisions API routen beschrieben.
Praxisbeispiele
Umfangreiches Issue-Triage. Googles eigene Antigravity SDK-Demo kombiniert Hydrogen-Agenten für Triage und Coding mit einem Carbon-Agenten für Refactorings, neue Features und Sicherheitsprüfungen. Auf einem Board entspricht das einem Hydrogen-Agenten für die Eingangswarteschlange und einem leitenden Carbon-Agenten für alles, was als Refactoring oder Security gekennzeichnet ist.
Aufteilung eines Features in parallele Teilaufgaben. Der Planer unterteilt eine API-Änderung in Schema-, Handler- und Client-Updates; drei Worker setzen diese in separaten Worktrees um; der Verifier führt die Contract-Tests aus.
Fazit
Carbon plant, Hydrogen baut und ein Mensch nimmt ab. Die Preisgestaltung macht diese Aufteilung ab dem 1. Dezember wirtschaftlich lohnend, die Eskalations-Trigger verhindern, dass aus günstigen Fehlern teure Wiederholungsversuche werden, und das Board hält jede Übergabe transparent im Task für das gesamte Team fest. Weiterführende Informationen zu diesem Muster finden Sie in unseren Beiträgen darüber, was KI-Agenten-Orchestrierung ist, sowie zu unserer Modell-Routing-Regel für Crews.
Ihr nächster Schritt: Verbinden Sie einen Computer mit Sharkly, erstellen Sie einen Planer-Agenten auf Carbon und einen Worker auf Hydrogen, fügen Sie beide mit den obigen Anweisungen in eine Crew ein und weisen Sie ihr einen Task zu, den Sie normalerweise einem Mitarbeiter für einen Nachmittag übertragen würden. Sharkly bietet einen kostenlosen Tarif (Free Plan), sodass für diesen Test lediglich die Gemini-Tokens anfallen.
FAQ
Was ist der Unterschied zwischen Gemini 4 Carbon und Hydrogen?
Carbon ist Googles stärkstes Frontier-Modell, entwickelt für weitreichendes logisches Denken (Long-Horizon Reasoning) sowie anspruchsvolle Architektur-, Debugging- und Sicherheitsaufgaben. Hydrogen ist das schnelle, effiziente Gemini 4-Modell für alltägliches Coding und die Agenten-Ausführung. Carbon nutzt standardmäßig das Thinking-Level medium und ist bei high gedeckelt; Hydrogen startet standardmäßig mit high und bietet zusätzlich xhigh.
Ist Gemini 4 Hydrogen günstiger als Carbon?
Ja. Hydrogen kostet 1,50 $ pro 1 Mio. Input-Token und 7,50 $ pro 1 Mio. Output-Token. Carbon liegt bis zum 30. November 2026 bei 2 $ bzw. 10 $ und ab dem 1. Dezember bei 4 $ bzw. 20 $. Zudem verfügt Hydrogen über ein ratenlimitiertes Free Tier in der Gemini API; Carbon bietet dies nicht.
Sollte der Verifier auf Carbon statt auf Hydrogen laufen?
Standardmäßig nicht. Google positioniert Hydrogen für parallele Worker- und Verifier-Agenten. Verwenden Sie xhigh beim Verifier für riskante Diffs und eskalieren Sie den Task erst dann an den Carbon-Planer, wenn eine Prüfung zweimal fehlschlägt.
Wählt Sharkly das Modell für jeden Task aus?
Nein. Sie legen das Modell pro Agent über dessen Runtime fest, und die Crew-Anweisungen bestimmen, welcher Agent welchen Teil des Tasks übernimmt. Sharkly verwaltet den Task, die Durchläufe, die Übergaben und das Review.
