Gemini 4 Carbons Pelican-Demo im Detail: zwei Agenten, eine Blender-Pipeline und eine Review-Schleife, die tatsächlich schließt

Das Nützlichste, was Google am 10. November 2026 veröffentlichte, war keine Benchmark-Tabelle. Es war ein Vogel auf einem Fahrrad. In demselben Beitrag, mit dem Google Gemini 4 Carbon allgemein verfügbar machte, beschrieb Google einen Lauf, in dem Carbon-Agenten ein Open-World-3D-Spiel bauten – man erkundet Googles Campus in Mountain View als Pelikan auf einem GBike –, indem sie Assets in Blender modellierten und dann das Browserspiel in Three.js mit WebGL-Shadern bauten, wobei prozedurale Web-Audio-Effekte mit Lyria-Musik kombiniert wurden. Der dazu kursierende Clip ist etwa 77 Sekunden lang. Der Teil, der Ihre Aufmerksamkeit verdient, ist nicht der Pelikan. Es ist die Tatsache, dass sich der Kreis schloss: Etwas in dieser Pipeline sah sich an, was gerendert worden war, und entschied, ob es gut genug war.

Das ist eine andere Behauptung als „das Modell ist klug“. Demos werden ausgewählt, und diese hier wurde vom Anbieter ausgewählt. Doch eine Demo mit einer prüfenden Person ist auf eine Weise testbar, wie es ein Benchmark-Wert nicht ist – man kann die Struktur lesen, die Rollen zählen und fragen, ob dieselbe Form in der eigenen Arbeit Bestand hätte. Das ist also eher eine Zerlegung als ein Launch-Beitrag: was gebaut wurde, wie die Agenten aufgeteilt wurden, was der Durchlauf zeigt und was nicht, und was es kostet, dasselbe Muster auf etwas zu richten, das einem tatsächlich wichtig ist.

Was tatsächlich gebaut wurde, in der Reihenfolge, in der es gebaut wurde

Googles Beschreibung ist ungewöhnlich konkret, was die Toolchain betrifft, und genau das macht sie als Engineering-Notiz lesenswert. Der Lauf umfasste drei Mediensegmente, und diese sind nicht austauschbar:

• Assets — Subagenten modellierten 3D-Objekte in Blender, ausgehend von Referenzen, die von Omni und Nano Banana generiert wurden. Das ist ein Modellierungsschritt, kein Codeschritt: Geometrie, Materialien und Maßstab entstehen dabei, und alles Nachgelagerte übernimmt, was auch immer daran falsch ist.

• Das Spiel – in Three.js mit WebGL-Shadern umgesetzt, sodass das Ergebnis eine im Browser renderbare Szene ist und kein gerendertes Video. Ein Shader, der kompiliert, ist ein hartes, maschinell überprüfbares Signal – anders als „sieht gut aus“.

• Sound — prozedurale Web-Audio-Effekte in Kombination mit Lyria-Musik. Dies ist der am wenigsten mit der Review-Schleife verbundene Teilbereich und derjenige, der am ehesten im Nachhinein von einem Menschen manuell feinjustiert wird.

Derselbe Beitrag stellt vier weitere 3D-Bauten daneben, und das Muster wiederholt sich: eine interaktive Three.js-Ausstellung über die Errichtung des Eiffelturms 1887–1889 anhand historischer Fotografien und technischer Tafeln; eine Three.js-Rekonstruktion von Googles Platform-37-Büro mit 906.000 Dreiecken, erstellt in zehn nächtlichen Durchläufen aus sieben Planungs-PDFs des City Council; einen Textilvisualisierer mit Polar-Tracking für 110 Fasern; und ein spielbares Fortepiano mit 61-Tasten-Escapement-Physik. Was auch immer sonst zutrifft: Dies ist kein einzelner Glücks-Prompt. Es ist eine Reihe von Durchläufen in derselben Form.

Zwei Agenten – oder ein Agent mit drei Aufgaben?

Die Beobachterkonten und Googles eigene Darstellung beschreiben denselben Ablauf aus unterschiedlichen Blickwinkeln, und der Unterschied ist aufschlussreich. Die am weitesten verbreitete chinesischsprachige Zusammenfassung von @dotey vom 10. November unterteilt ihn in einen Builder-Agenten und einen Reviewer-Agenten, der seine eigenen Renderings prüft. Der ursprüngliche Verfasser, Vamsi Batchu von Google AI Studio, stellt dieselbe Sache als einen Pelikan dar, der TPU-Chips auf dem Campus einsammelt — und schreibt dies der Funktion /swarm von Google Antigravity zu, die Google als Verwandlung eines einzelnen Prompts in „ein koordiniertes Team von Agenten, die du in Echtzeit verfolgen kannst“ beschreibt.

Googles Beitrag weist Carbon die Rollen zu und nicht den Medien: „Architekturdesign, Koordination und Auditing“. Liest man das zusammen mit der Beschreibung des Beobachters, ergibt sich das Bild eines Builders, der Geometrie und Code erzeugt, und eines Prüfers, der auf die Ausgabe statt auf die Quelle schaut. Diese Unterscheidung ist wichtiger als die Anzahl der Agenten. Ein Agent, der seinen eigenen Diff überprüft, hat ein schwaches Signal; ein Agent, der ein gerendertes Bild, einen kompilierten Shader oder einen Screenshot des laufenden Spiels überprüft, hat ein starkes, weil der Fehler im Artefakt sichtbar ist statt im Prosatext verhandelbar.

Zwei ehrliche Vorbehalte zur Quellenlage. Die Aufteilung zwischen Builder und Reviewer stammt von Personen, die den Lauf beschreiben, nicht aus einem veröffentlichten Architekturdiagramm – betrachten Sie sie als getreue Zusammenfassung, nicht als Spezifikation. Und /swarm ist in Antigravity in der Vorschau, daher ist die Orchestrierungsschicht, die Sie nachbauen würden, nicht allgemein verfügbar.

Es gibt außerdem einen praktischen Haken, den niemand erwähnt: Die verlinkte AI Studio-App ist hinter einer Google-Anmeldung. Ich konnte das Spiel nicht anonym öffnen – die URL leitet direkt weiter zu accounts.google.com. „Im Browser spielbar“ bedeutet also „spielbar, wenn man ein Google-Konto und für die App selbst eine AI Studio-Sitzung hat.“ Das ist eine Kleinigkeit, die hundert Reposts des Videos stillschweigend übersprungen haben.

Warum ein Spiel ein schwierigerer Test ist als das SVG, das es ersetzt hat

Der Prompt mit dem Pelikan auf einem Fahrrad stammt von Simon Willison, der ihn seit 2024 gegen praktisch jedes Frontier-Release laufen ließ – zunächst als einzelne SVG-Anfrage, dann, als sich die Modelle bei flachem SVG nicht mehr unterschieden, als 3D-Prompts: eine WebGL-Seite, Blender-Renderings, p5.js-Skizzen. Der Wert des Tests lag nie darin, dass ein Pelikan schwierig ist. Er liegt darin, dass die Ausgabe visuell, in sich geschlossen und von einem Menschen in unter einer Sekunde sofort beurteilbar ist.

Was Carbons Durchlauf tut, ist, dieselbe Eigenschaft eine Schwierigkeitsstufe höher zu treiben. Ein SVG ist ein Artefakt in einer Sprache. Hier ist es Geometrie aus einem Werkzeug, Code in einem anderen, eine Laufzeitumgebung in einem dritten und ein Prüfschritt, der alle drei in Einklang bringen muss – genau die Art von Aufgabe, bei der Agentenarbeit mit langem Zeithorizont üblicherweise scheitert, nicht beim ersten Schritt, sondern beim vierzehnten, wenn das Modell vergessen hat, für welches Koordinatensystem es sich entschieden hatte.

Googles Zusammenfassung der Fähigkeit ist präzise, und sie benennt den Mechanismus: Bei der Entwicklung von Web-Apps „durchläuft das Modell Build-and-Verify-Schleifen, erholt sich von Fehlern und prüft sowohl seinen Code als auch die gerenderte Benutzeroberfläche“. Das ist der ganze Trick, schlicht gesagt. Die interessante Variable ist nicht, wie gut der erste Versuch ist. Sie ist, wie oft die Schleife durchlaufen kann, bevor der Agent aufhört, sich zu verbessern, und anfängt, im Kreis zu laufen.

Was die Demo Ihnen nicht verrät

Eine Anbieter-Demo ist eine ausgewählte Stichprobe, und die Auswahl ist der eigentliche Zweck der Übung. Drei Dinge, die sie nicht beantworten kann:

• Wie oft es fehlschlägt. Wir sehen den Durchlauf, der fertig wurde. Niemand veröffentlicht die elf, die hängen blieben, und nirgends in dem Beitrag gibt es einen Nenner.

• Was es gekostet hat. Zehn nächtliche Schleifen beim Build von Platform 37 bedeuten eine Menge Tokens und eine Menge Wall-Clock-Zeit. Zu Carbons Tarifen ist das eine echte Zahl, und Google gibt sie nicht an.

• Ob ein günstigeres Modell ausgereicht hätte. Das ist die Frage, die ein Leser eigentlich stellen sollte, und die Demo ist strukturell nicht in der Lage, sie zu beantworten.

Für die Teile, die sich messen lassen, ist Artificial Analysis das Gegengewicht, und seine Zahlen sind weniger schmeichelhaft als das Video. Gemini 4 Carbon erzielt bei hohem Effort 60 auf dem Intelligence Index v5.0.1 – Platz vier von 74 Modellen, hinter drei Konfigurationen von Claude Fable 5.2 mit 65, 62 und 62. Seine Kosten pro Index-Aufgabe betragen 7,76 US-Dollar; damit liegt es bei diesem Maßstab auf Platz 61 von 73, und es verbraucht über den Index hinweg 205 Millionen Output-Tokens gegenüber einem Median von nahezu 73 Millionen: Es ist ein wortreiches Modell, und die Preisgestaltung pro Token unterschätzt, was eine Carbon-Workload kostet. Die Ausgabegeschwindigkeit liegt bei etwa 82 Tokens pro Sekunde, mit ungefähr 67,5 Sekunden bis zum ersten Antwort-Token – pro Token schnell genug, bis zum ersten jedoch so langsam, dass es eher wie ein Batch-and-Wait-Profil als wie ein Chatbox-Profil wirkt. Im Coding Agent Index setzte derselbe Evaluator Carbon mit Antigravity CLI auf 59 gegenüber 62 für Claude Code mit Opus 5.5.

Das alles widerspricht der Demo nicht. Ein Modell kann auf einem allgemeinen Index auf Platz vier stehen, pro Aufgabe teuer sein und trotzdem dasjenige sein, das einen vierstündigen Build zusammenhält – das sind unterschiedliche Messgrößen, und die Demo ist ein Beleg für die dritte, nicht für die erste. Sie ist allerdings kein Beweis, und der günstigste fehlende Baustein ist der, den diese Modelllinie üblicherweise liefert. Willison führt den Pelican-Prompt bei nahezu jedem Release aus und veröffentlicht die Ergebnisse; im November 2026 decken seine Pelican-Beiträge Claude Fable 5.2 auf fünf Reasoning-Stufen und Muse Ember auf sechs ab, und es ist kein Carbon-Set darunter. Bis ein solches Set auftaucht, ist die Pelican-Demo ein Artefakt von Google und von niemandem sonst – ein anbieterseitig ausgewählter Build mit einer anbieterseitig verfassten Beschreibung und kein externer Lauf, gegen den sich die Fehlerrate vergleichen ließe.

Was es kostet, dieselbe Schleife selbst auszuführen

Carbon ist ausschließlich in Googles kostenpflichtiger Tarifstufe verfügbar. Es gibt keinen kostenlosen Weg: Die AI Studio-App benötigt ein Google-Konto, die API benötigt Abrechnung, und jedes verarbeitete Token wird abgerechnet, einschließlich Thinking-Tokens. Die Preisliste ist ein Einführungstarif und zeitlich begrenzt:

• Bis 30. November 2026 — 2,00 $ pro Million Eingabe-Tokens, 10,00 $ pro Million Ausgabe-Tokens.

• Ab dem 1. Dezember 2026 — 4,00 $ und 20,00 $, bei einem Modell, das sich nicht verändert hat.

• Kontext — 1 Mio. Token, ohne längenabhängige Preisstaffel, sodass eine Codebasis mit 900.000 Token pro Token genauso viel kostet wie ein Prompt mit 2.000 Token.

Stellt man die Ausführlichkeit neben die Klippe, wird die Rechnung unangenehm. Eine Build-and-Review-Schleife ist konstruktionsbedingt outputlastig: Der Reviewer schreibt, der Builder schreibt um, und das Transkript wächst mit jeder Runde. Ein Arbeitsvolumen von 100 Millionen Input- und 20 Millionen Output-Tokens kostet diesen Monat $400 – $200 für Input, $200 für Output – und ab dem 1. Dezember für exakt denselben Traffic $800. Wenn Sie im November einen Pilotversuch durchführen, kalkulieren Sie ihn mit den Dezember-Tarifen, sonst genehmigen Sie ein Budget, das um den Faktor zwei danebenliegt.

Es lohnt sich, ausdrücklich klarzustellen, wo wir stehen: Gemini 4 Carbon ist nicht im OrcaRouter-Katalog, und nichts hier sollte so gelesen werden, als würde behauptet, dass es dort sei. Dort gibt es google/gemini-4-argon zu Googles eigenem Preis von 2 $ für Eingaben / 10 $ für Ausgaben — dieselbe Tarifkarte, auf der Carbon diesen Monat läuft — neben DeepSeek V4 Pro zu 0,66 $/1,98 $ und Grok 4.7 zu 2 $/6 $, alles über einen einzigen OpenAI-kompatiblen Schlüssel für 216 Modelle, wobei der Listenpreis des Anbieters mit 0 % Aufschlag weitergegeben wird, sodass eine Tarifänderung eines Anbieters am Tag ihres Eintretens wirksam wird und nicht erst nach einem Preisänderungszyklus. Für dieses spezielle Muster ist das aus einem langweiligen Grund wichtig: Ein Multi-Agent-Build-Loop ist die Workload, die am ehesten ein Ratenlimit oder einen schlechten Nachmittag bei einem Anbieter erwischt, und ein Failover über eine zweite Route ist billiger, als die Obergrenze auf halber Strecke eines Laufs mit zehn Schleifen zu entdecken.

Wenn Sie die Struktur kopieren möchten, kopieren Sie den Überprüfungsschritt

Der übertragbare Teil dieser Demo ist weder Blender noch Three.js. Er besteht darin, dass der prüfenden Person etwas gezeigt wurde, das sie sich ansehen konnte. Drei Schritte, geordnet danach, wie stark sie das Ergebnis verändern:

• Machen Sie das Artefakt zur Eingabe für die Überprüfung. Machen Sie einen Screenshot der laufenden App, rendern Sie das Frame, kompilieren Sie den Shader, führen Sie den Test aus — und reichen Sie dann das zurück, nicht den Diff. Ein Agent, den man fragt, ob dieser Code korrekt ist, wird sich selbst bestätigen. Ein Agent, den man fragt, ob dieser Screenshot der Vorgabe entspricht, hat etwas, woran er sich irren kann.

• Begrenze die Schleife und prüfe auf Konvergenz. Zehn Schleifen über Nacht ist die Zahl, die Google für einen Build nennt. Wähle deine eigene Obergrenze und protokolliere, ob jeder Durchlauf das Artefakt tatsächlich verbessert hat – ein Agent, der aufgehört hat, sich zu verbessern, ist normalerweise ein Agent, der angefangen hat, umzudekorieren.

• Die Toolchain langweilig und überprüfbar halten. Blender-Exporte, Three.js, WebGL und ein Browser sind allesamt deterministisch und nachprüfbar. Nichts in diesem Durchlauf hängt von einer Fähigkeit ab, die nur ein Anbieter besitzt; es hängt von einem Modell ab, das nach dem ersten Fehlschlag weiterläuft.

Was als Nächstes zu beobachten ist, ist eng umrissen und konkret. Ob /swarm die Preview verlässt, weil die Orchestrierung der Teil ist, den man heute nicht reproduzieren kann. Ob jemand außerhalb von Google einen Carbon pelican veröffentlicht – Willisons Version ist das, was in dieser Linie einem unabhängigen Ergebnis am nächsten kommt, und sie ist nicht erschienen. Und ob die zwölf Tage zwischen der zugangsbeschränkten Ankündigung am 28. Oktober und der allgemeinen Veröffentlichung am 10. November sich als das Muster oder als die Ausnahme erweisen. Die Demo wird monatelang zitiert werden. Die Schleife dahinter ist das, was sich entweder verallgemeinert oder nicht.