Gemini 4 Carbon's Pelican Demo, Taken Apart: Two Agents, a Blender Pipeline, and a Review Loop That Actually Closes

The most useful thing Google shipped on 10 November 2026 was not a benchmark table. It was a bird on a bicycle. In the same post that made Gemini 4 Carbon generally available, Google described a run in which Carbon agents built an open-world 3D game — you explore Google's Mountain View campus as a pelican riding a GBike — by modelling assets in Blender, then building the browser game in Three.js with WebGL shaders, with procedural Web Audio effects paired against Lyria music. The clip that circulated with it runs about 77 seconds. The part worth your attention is not the pelican. It is that the loop closed: something in that pipeline looked at what it had rendered and decided whether it was good enough.

That is a different claim from "the model is smart." Demos are chosen, and this one was chosen by the vendor. But a demo with a reviewer in it is testable in a way a benchmark score is not — you can read the structure, count the roles, and ask whether the same shape would survive your own work. So this is a teardown rather than a launch piece: what was built, how the agents were split, what the run does and does not demonstrate, and what it costs to point the same pattern at something you actually care about.

What was actually built, in the order it was built

Google's description is unusually specific about the toolchain, which is what makes it worth reading as an engineering note. The run had three media legs, and they are not interchangeable:

• Assets — subagents modelled 3D objects in Blender, working from references generated by Omni and Nano Banana. That is a modelling step, not a code step: geometry, materials and scale come out of it, and everything downstream inherits whatever is wrong with them.

• The game — built in Three.js with WebGL shaders, so the deliverable is a browser-renderable scene rather than a rendered video. A shader that compiles is a hard, machine-checkable signal in a way that "looks nice" is not.

• Sound — procedural Web Audio effects paired with Lyria music. This is the leg least connected to the review loop, and the one most likely to be hand-tuned by a human after the fact.

The same post puts four other 3D builds beside it, and the pattern repeats: an interactive Three.js exhibition of the Eiffel Tower's 1887–1889 construction from historical photographs and engineering plates; a 906,000-triangle Three.js reconstruction of Google's Platform 37 office built across ten overnight loops from seven City Council planning PDFs; a textile visualiser with 110-fibre polar tracking; and a playable fortepiano with 61-key escapement physics. Whatever else is true, this is not one lucky prompt. It is a set of runs in the same shape.

Two agents, or one agent with three jobs?

The observer accounts and Google's own write-up describe the same run from different angles, and the difference is instructive. The most widely shared Chinese-language summary, from @dotey on 10 November, splits it into a builder agent and a reviewer agent that checks its own renders. The original poster, Vamsi Batchu of Google AI Studio, frames the same thing as a pelican collecting TPU chips around the campus — and credits Google Antigravity's /swarm feature, which Google describes as turning a single prompt into "a coordinated team of agents you can track in real time."

Google's post assigns Carbon the roles rather than the media: "architectural design, coordination, and auditing." Read alongside the observer description, the shape is a builder that produces geometry and code, and an auditor that looks at the output rather than the source. That distinction matters more than the agent count. An agent reviewing its own diff has a weak signal; an agent reviewing a rendered frame, a compiling shader, or a screenshot of the running game has a strong one, because the failure is visible in the artefact instead of arguable in the prose.

Two honest caveats on the sourcing. The builder/reviewer split comes from people describing the run, not from a published architecture diagram — treat it as a faithful summary rather than a spec. And /swarm is in preview in Antigravity, so the orchestration layer you would be reproducing is not generally available.

There is also a practical wrinkle nobody mentions: the linked AI Studio app is behind a Google sign-in. I could not open the game anonymously — the URL redirects straight to accounts.google.com. So "playable in your browser" means "playable if you have a Google account and, for the app itself, an AI Studio session." That is a small thing that a hundred reposts of the video quietly skipped.

Why a game is a harder test than the SVG it replaced

The pelican-on-a-bicycle prompt belongs to Simon Willison, who has run it against essentially every frontier release since 2024 — first as a single SVG request, then, once models stopped separating on flat SVG, as 3D prompts: a WebGL page, Blender renders, p5.js sketches. The test's value was never that a pelican is hard. It is that the output is visual, self-contained, and instantly judgeable by a human in under a second.

What Carbon's run does is push that same property up a level of difficulty. An SVG is one artefact in one language. This is geometry from one tool, code in another, a runtime in a third, and a review step that has to reconcile all three — which is exactly the class of task where long-horizon agent work usually falls over, not on the first step but on the fourteenth, when the model has forgotten which coordinate system it committed to.

Google's summary of the capability is precise, and it names the mechanism: for web app development the model "runs build-and-verify loops, recovers from errors, and checks both its code and the rendered UI." That is the whole trick, stated plainly. The interesting variable is not how good the first attempt is. It is how many times the loop can turn before the agent stops improving and starts thrashing.

What the demo does not tell you

A vendor demo is a selected sample, and the selection is the point of the exercise. Three things it cannot answer:

• How often it fails. We see the run that finished. Nobody publishes the eleven that stalled, and there is no denominator anywhere in the post.

• What it cost. Ten overnight loops on the Platform 37 build implies a lot of tokens and a lot of wall-clock. At Carbon's rates that is a real number, and Google does not give it.

• Whether a cheaper model would have done. This is the question a reader should actually ask, and the demo is structurally incapable of answering it.

For the parts that can be measured, Artificial Analysis is the counterweight, and its numbers are less flattering than the video. Gemini 4 Carbon at high effort scores 60 on Intelligence Index v5.0.1 — fourth of 74 models, behind three configurations of Claude Fable 5.2 at 65, 62 and 62. Its cost per index task is $7.76, ranked 61st of 73 on that measure, and it consumes 205 million output tokens across the index against a median near 73 million: it is a verbose model, and per-token pricing understates what a Carbon workload costs. Output speed is about 82 tokens per second with roughly 67.5 seconds to first answer token — fast enough per token, slow enough to the first one that it reads as a batch-and-wait profile rather than a chat-box one. On the Coding Agent Index, the same evaluator put Carbon at 59 with Antigravity CLI against 62 for Claude Code with Opus 5.5.

None of that contradicts the demo. A model can be fourth on a general index, expensive per task, and still be the one that holds a four-hour build together — those are different measurements, and the demo is evidence for the third, not the first. What it is not is proof, and the cheapest missing piece is the one this lineage usually supplies. Willison runs the pelican prompt on nearly every release and publishes the results; in November 2026 his pelican posts cover Claude Fable 5.2 at five reasoning levels and Muse Ember at six, and there is no Carbon set among them. Until one appears, the pelican demo is Google's artefact and nobody else's — a vendor-selected build with a vendor-written description, and no outside run to compare the failure rate against.

What it costs to run the same loop yourself

Carbon is on Google's paid tier only. There is no free path: the AI Studio app needs a Google account, the API needs billing, and every processed token is billed, thinking tokens included. The rate card is introductory and time-limited:

• Until 30 November 2026 — $2.00 per million input tokens, $10.00 per million output tokens.

• From 1 December 2026 — $4.00 and $20.00, on a model that has not changed.

• Context — 1M tokens, with no length-based price tier, so a 900,000-token codebase costs the same per token as a 2,000-token prompt.

Put the verbosity next to the cliff and the arithmetic gets uncomfortable. A build-and-review loop is output-heavy by construction: the reviewer writes, the builder rewrites, and the transcript grows every turn. A workload of 100 million input and 20 million output tokens bills $400 this month — $200 in, $200 out — and $800 from 1 December for the identical traffic. If you are piloting in November, price the pilot at December rates or you will approve a budget that is wrong by a factor of two.

Worth being explicit about where we sit: Gemini 4 Carbon is not in the OrcaRouter catalogue, and nothing here should be read as claiming it is. What is there is google/gemini-4-argon at Google's own $2 in / $10 out — the same card Carbon is on this month — alongside DeepSeek V4 Pro at $0.66/$1.98 and Grok 4.7 at $2/$6, all on one OpenAI-compatible key across 216 models, with provider list price passed through at 0% markup so a vendor rate change lands the day it happens rather than after a repricing cycle. For this particular pattern that matters for a boring reason: a multi-agent build loop is the workload most likely to hit a rate limit or a bad afternoon at one provider, and failover across a second route is cheaper than discovering the ceiling halfway through a ten-loop run.

If you want to copy the structure, copy the review step

The transferable part of this demo is not Blender, and it is not Three.js. It is that the reviewer was given something it could look at. Three moves, in order of how much they change the outcome:

• Make the artefact the review input. Screenshot the running app, render the frame, compile the shader, run the test — then hand that back, not the diff. An agent asked "is this code correct" will agree with itself. An agent asked "does this screenshot match the brief" has something to be wrong about.

• Cap the loop and check for convergence. Ten overnight loops is the number Google cites for one build. Pick your own ceiling, and log whether each turn actually improved the artefact — an agent that has stopped improving is usually an agent that has started redecorating.

• Keep the toolchain boring and checkable. Blender exports, Three.js, WebGL and a browser are all deterministic and inspectable. Nothing in this run depends on a capability that only one vendor has; it depends on a model that will keep going after the first failure.

What to watch next is narrow and specific. Whether /swarm leaves preview, because the orchestration is the part you cannot reproduce today. Whether anyone outside Google publishes a Carbon pelican — Willison's version is the closest thing this lineage has to an independent result, and it has not appeared. And whether the twelve-day gap between the 28 October gated announcement and the 10 November general release turns out to be the pattern, or the exception. The demo will be quoted for months. The loop behind it is the thing that either generalises or does not.