La démo Pelican de Gemini 4 Carbon, décortiquée : deux agents, un pipeline Blender et une boucle de révision qui se ferme vraiment

Ce que Google a livré de plus utile le 10 novembre 2026 n'était pas un tableau de benchmarks. C'était un oiseau sur un vélo. Dans le même billet qui rendait Gemini 4 Carbon généralement disponible, Google décrivait une exécution dans laquelle des agents Carbon construisaient un jeu 3D en monde ouvert — vous explorez le campus de Google à Mountain View dans la peau d'un pélican chevauchant un GBike — en modélisant des ressources dans Blender, puis en construisant le jeu pour navigateur dans Three.js avec des shaders WebGL, avec des effets Web Audio procéduraux associés à de la musique Lyria. Le clip qui a circulé avec cela dure environ 77 secondes. La partie qui mérite votre attention n'est pas le pélican. C'est que la boucle était bouclée : quelque chose dans ce pipeline regardait ce qu'il avait rendu et décidait si c'était suffisamment bon.

Cela constitue une affirmation différente de « le modèle est intelligent ». Les démos sont choisies, et celle-ci l’a été par le fournisseur. Mais une démo comportant un relecteur est testable d’une manière qu’un score de benchmark ne l’est pas — on peut lire la structure, compter les rôles et se demander si la même forme survivrait à votre propre travail. Il s’agit donc d’une analyse détaillée plutôt que d’un article de lancement : ce qui a été construit, comment les agents ont été répartis, ce que l’exécution démontre et ne démontre pas, et ce qu’il en coûte d’appliquer le même schéma à quelque chose qui vous tient réellement à cœur.

Ce qui a réellement été construit, dans l’ordre de sa construction

La description de Google est inhabituellement précise concernant la chaîne d’outils, ce qui en fait une note d’ingénierie digne d’être lue. L’exécution comportait trois volets médiatiques, et ils ne sont pas interchangeables :

• Ressources — des sous-agents ont modélisé des objets 3D dans Blender, à partir de références générées par Omni et Nano Banana. Il s’agit d’une étape de modélisation, pas d’une étape de code : la géométrie, les matériaux et l’échelle en résultent, et tout ce qui se trouve en aval hérite de leurs défauts éventuels.

• Le jeu — développé avec Three.js et des shaders WebGL, ce qui fait du livrable une scène affichable dans un navigateur plutôt qu'une vidéo rendue. Un shader qui compile constitue un signal strict et vérifiable par la machine, contrairement à un simple « rendu agréable ».

• Son — effets Web Audio procéduraux associés à la musique Lyria. C’est le volet le moins connecté à la boucle de révision, et celui qui est le plus susceptible d’être ajusté manuellement par un humain après coup.

La même publication place à ses côtés quatre autres réalisations 3D, et le schéma se répète : une exposition interactive Three.js de la construction de la tour Eiffel de 1887 à 1889 à partir de photographies historiques et de planches d’ingénierie ; une reconstruction Three.js de 906 000 triangles du bureau Platform 37 de Google, réalisée en dix boucles nocturnes à partir de sept PDF de planification du conseil municipal ; un visualiseur textile avec suivi polaire à 110 fibres ; et un fortepiano jouable avec une physique d’échappement à 61 touches. Quoi qu’il en soit, il ne s’agit pas d’une simple requête chanceuse. C’est un ensemble d’exécutions de même forme.

Deux agents, ou un seul agent avec trois fonctions ?

Les récits des observateurs et le propre compte rendu de Google décrivent la même exécution sous des angles différents, et la différence est instructive. Le résumé en chinois le plus largement partagé, de @dotey le 10 novembre, la divise en un agent constructeur et un agent réviseur qui vérifie ses propres rendus. L'auteur du message initial, Vamsi Batchu de Google AI Studio, présente la même chose comme un pélican collectant des puces TPU aux alentours du campus — et attribue le mérite à Google Antigravity pour la fonctionnalité /swarm, que Google décrit comme transformant une simple invite en « une équipe coordonnée d'agents que vous pouvez suivre en temps réel ».

Le billet de Google attribue à Carbon les rôles plutôt qu’aux médias : « conception architecturale, coordination et audit. » Rapprochée de la description de l’observateur, la configuration est celle d’un constructeur qui produit de la géométrie et du code, et d’un auditeur qui examine la sortie plutôt que la source. Cette distinction compte davantage que le nombre d’agents. Un agent qui relit son propre diff dispose d’un signal faible ; un agent qui examine une image rendue, un shader en cours de compilation ou une capture d’écran du jeu en cours d’exécution dispose d’un signal fort, car la défaillance est visible dans l’artefact au lieu d’être discutable dans la prose.

Deux mises en garde honnêtes sur le sourcing. La séparation entre constructeur et relecteur provient de personnes décrivant l’exécution, et non d’un diagramme d’architecture publié — considérez-la comme un résumé fidèle plutôt que comme une spécification. Et /swarm est en préversion dans Antigravity, donc la couche d’orchestration que vous reproduiriez n’est pas en disponibilité générale.

Il y a aussi un détail pratique que personne ne mentionne : l’application AI Studio liée est protégée par une connexion Google. Je n’ai pas pu ouvrir le jeu anonymement — l’URL redirige directement vers accounts.google.com. Donc « jouable dans votre navigateur » signifie « jouable si vous avez un compte Google et, pour l’application elle-même, une session AI Studio ». C’est un petit détail que cent repartages de la vidéo ont discrètement passé sous silence.

Pourquoi un jeu constitue un test plus difficile que le SVG qu’il a remplacé

Le prompt du pélican à bicyclette appartient à Simon Willison, qui l’a soumis à pratiquement chaque modèle frontière publié depuis 2024 — d’abord sous la forme d’une simple requête SVG, puis, une fois que les modèles ont cessé de se départager sur du SVG plat, sous forme de prompts 3D : une page WebGL, des rendus Blender, des esquisses p5.js. La valeur du test n’a jamais tenu au fait qu’un pélican soit difficile à générer. Elle tient au fait que le résultat est visuel, autonome et immédiatement évaluable par un humain en moins d’une seconde.

Ce que fait l’exécution de Carbon, c’est pousser cette même propriété à un niveau de difficulté supérieur. Un SVG est un artefact dans un seul langage. Ici, il y a de la géométrie provenant d’un outil, du code dans un autre, un environnement d’exécution dans un troisième, et une étape de revue qui doit concilier les trois — ce qui correspond exactement à la catégorie de tâches où le travail d’agent à long horizon échoue généralement, non pas à la première étape mais à la quatorzième, lorsque le modèle a oublié le système de coordonnées qu’il avait choisi.

Le résumé que Google donne de cette capacité est précis, et il nomme le mécanisme : pour le développement d’applications web, le modèle « exécute des boucles de construction et de vérification, se remet des erreurs et vérifie à la fois son code et l’interface utilisateur rendue. » C’est toute l’astuce, dite simplement. La variable intéressante n’est pas la qualité de la première tentative. C’est le nombre de fois que la boucle peut tourner avant que l’agent cesse de s’améliorer et commence à tourner en rond.

Ce que la démo ne vous dit pas

Une démo fournisseur est un échantillon sélectionné, et c’est précisément la sélection qui fait tout l’intérêt de l’exercice. Trois choses auxquelles elle ne peut pas répondre :

• À quelle fréquence cela échoue. Nous voyons l’exécution qui s’est terminée. Personne ne publie les onze qui ont calé, et il n’y a aucun dénominateur nulle part dans l’article.

• Ce que cela a coûté. Dix boucles nocturnes sur le build Platform 37 impliquent beaucoup de tokens et beaucoup de temps d’horloge. Aux tarifs de Carbon, c’est un nombre concret, et Google ne le fournit pas.

• Si un modèle moins cher aurait suffi. Voilà la question que le lecteur devrait réellement se poser, et la démo est structurellement incapable d'y répondre.

Pour les parties qui peuvent être mesurées, Artificial Analysis fait office de contrepoids, et ses chiffres sont moins flatteurs que la vidéo. Gemini 4 Carbon en effort élevé obtient 60 sur l’Intelligence Index v5.0.1 — quatrième sur 74 modèles, derrière trois configurations de Claude Fable 5.2 à 65, 62 et 62. Son coût par tâche de l’indice est de 7,76 $, ce qui le classe 61e sur 73 sur ce critère, et il consomme 205 millions de jetons de sortie sur l’ensemble de l’indice, contre une médiane proche de 73 millions : c’est un modèle verbeux, et la tarification au jeton sous-estime le coût d’une charge de travail Carbon. La vitesse de sortie est d’environ 82 jetons par seconde, avec environ 67,5 secondes avant le premier jeton de réponse — assez rapide par jeton, mais assez lent jusqu’au premier pour qu’on y voie un profil de type traitement par lots et attente plutôt qu’un profil de boîte de chat. Sur le Coding Agent Index, le même évaluateur a placé Carbon à 59 avec Antigravity CLI, contre 62 pour Claude Code avec Opus 5.5.

Rien de tout cela ne contredit la démo. Un modèle peut être quatrième sur un indice général, coûteux par tâche, et néanmoins être celui qui fait tenir un build de quatre heures — ce sont des mesures différentes, et la démo est un élément de preuve en faveur de la troisième, pas de la première. Ce qu’elle n’est pas, c’est une preuve, et l’élément manquant le moins coûteux est celui que cette lignée fournit habituellement. Willison exécute le prompt pelican sur presque chaque version et publie les résultats ; en novembre 2026, ses articles sur le pelican portent sur Claude Fable 5.2 à cinq niveaux de raisonnement et Muse Ember à six, et aucun ensemble Carbon n’y figure. Jusqu’à ce qu’un tel ensemble apparaisse, la démo pelican est l’artefact de Google et de personne d’autre — un build sélectionné par le fournisseur, avec une description rédigée par le fournisseur, et aucune exécution externe à laquelle comparer le taux d’échec.

Combien coûte le fait d’exécuter la même boucle vous-même

Carbon est disponible uniquement sur l'offre payante de Google. Aucun parcours gratuit : l'application AI Studio nécessite un compte Google, l'API nécessite une facturation, et chaque token traité est facturé, y compris les tokens de réflexion. La grille tarifaire est introductive et limitée dans le temps :

• Jusqu'au 30 novembre 2026 — 2,00 $ par million de tokens d'entrée, 10,00 $ par million de tokens de sortie.

• À compter du 1er décembre 2026 — 4,00 $ et 20,00 $, sur un modèle qui n’a pas changé.

• Contexte — 1 M de tokens, sans palier tarifaire lié à la longueur : une base de code de 900 000 tokens coûte donc le même prix par token qu'un prompt de 2 000 tokens.

Placez la verbosité à côté de la falaise et l’arithmétique devient inconfortable. Une boucle de construction et de révision est lourde en sortie par construction : le réviseur écrit, le constructeur réécrit, et la transcription s’allonge à chaque tour. Une charge de 100 millions de tokens d’entrée et de 20 millions de tokens de sortie est facturée 400 $ ce mois-ci — 200 $ en entrée, 200 $ en sortie — et 800 $ à partir du 1er décembre pour le trafic identique. Si vous faites un pilote en novembre, chiffrez le pilote aux tarifs de décembre, sinon vous approuverez un budget erroné d’un facteur deux.

Soyons clairs sur notre position : Gemini 4 Carbon ne figure pas au catalogue d’OrcaRouter, et rien ici ne doit être interprété comme affirmant le contraire. Ce qui s’y trouve, c’est google/gemini-4-argon au tarif de Google lui-même, soit 2 $ en entrée / 10 $ en sortie — la même grille tarifaire que celle appliquée à Carbon ce mois-ci — aux côtés de DeepSeek V4 Pro à 0,66 $/1,98 $ et Grok 4.7 à 2 $/6 $, le tout sur une seule clé compatible OpenAI pour 216 modèles, avec le prix catalogue du fournisseur répercuté avec 0 % de marge ainsi, une modification des tarifs d’un fournisseur est appliquée le jour même, plutôt qu’après un cycle de réévaluation des prix. Pour ce schéma particulier, cela compte pour une raison banale : une boucle de construction multi-agents est la charge de travail la plus susceptible de heurter une limite de débit ou de subir un mauvais moment chez un fournisseur, et le basculement vers un second itinéraire coûte moins cher que de découvrir le plafond à mi-parcours d’une exécution de dix boucles.

Si vous voulez copier la structure, copiez l’étape de révision

La partie transférable de cette démo n’est pas Blender, et ce n’est pas Three.js. C’est que le relecteur a reçu quelque chose qu’il pouvait examiner. Trois actions, par ordre d’impact sur le résultat :

• Faites de l’artefact l’entrée de la revue. Faites une capture d’écran de l’application en cours d’exécution, effectuez le rendu de la frame, compilez le shader, lancez le test — puis renvoyez cela, pas le diff. Un agent à qui l’on demande « ce code est-il correct ? » sera d’accord avec lui-même. Un agent à qui l’on demande « cette capture d’écran correspond-elle au brief ? » a de quoi se tromper.

• Plafonnez la boucle et vérifiez la convergence. Dix boucles nocturnes, c’est le nombre que Google cite pour une compilation. Choisissez votre propre plafond et consignez si chaque tour a réellement amélioré l’artefact — un agent qui a cessé de s’améliorer est généralement un agent qui a commencé à redécorer.

• Garder la chaîne d’outils ennuyeuse et vérifiable. Les exports Blender, Three.js, WebGL et un navigateur sont tous déterministes et inspectables. Rien dans cette exécution ne dépend d’une capacité que seul un fournisseur possède ; cela dépend d’un modèle qui continuera après le premier échec.

Ce qu'il faut surveiller ensuite est étroit et précis. Savoir si /swarm sort de la préversion, car l'orchestration est la partie que l'on ne peut pas reproduire aujourd'hui. Savoir si quelqu'un en dehors de Google publie un Carbon pelican — la version de Willison est ce que cette lignée a de plus proche d'un résultat indépendant, et elle n'est pas apparue. Et savoir si l'écart de douze jours entre l'annonce à accès restreint du 28 octobre et la publication générale du 10 novembre se révèle être le schéma, ou l'exception. La démo sera citée pendant des mois. La boucle qui la sous-tend est ce qui se généralise ou non.