Desmontando a Demo do Pelicano do Gemini 4 Carbon: Dois Agentes, um Pipeline Blender e um Ciclo de Revisão que Realmente Fecha

A coisa mais útil que o Google lançou em 10 de novembro de 2026 não foi uma tabela de benchmarks. Foi um pássaro numa bicicleta. No mesmo post em que tornou o Gemini 4 Carbon disponível para todos, o Google descreveu uma execução em que agentes do Carbon construíram um jogo 3D de mundo aberto — você explora o campus do Google em Mountain View como um pelicano andando de GBike — modelando assets no Blender e depois criando o jogo para navegador em Three.js com shaders WebGL, com efeitos procedurais de Web Audio combinados com música do Lyria. O clipe que circulou com isso dura cerca de 77 segundos. A parte que merece sua atenção não é o pelicano. É que o ciclo se fechou: algo naquele pipeline olhou para o que tinha renderizado e decidiu se era bom o suficiente.

Isso é uma afirmação diferente de "o modelo é inteligente". As demos são escolhidas, e esta foi escolhida pelo fornecedor. Mas uma demo com um revisor incluído é testável de uma forma que uma pontuação de benchmark não é — você pode ler a estrutura, contar os papéis e perguntar se a mesma forma sobreviveria ao seu próprio trabalho. Portanto, esta é uma desmontagem, e não uma peça de lançamento: o que foi construído, como os agentes foram divididos, o que a execução demonstra e não demonstra, e quanto custa apontar o mesmo padrão para algo com que você realmente se importa.

O que foi realmente construído, na ordem em que foi construído

A descrição do Google é extraordinariamente específica sobre a cadeia de ferramentas, o que a torna digna de leitura como uma nota de engenharia. A execução teve três etapas de mídia, e elas não são intercambiáveis:

• Assets — subagentes modelaram objetos 3D no Blender, trabalhando a partir de referências geradas por Omni e Nano Banana. Essa é uma etapa de modelagem, não de código: geometria, materiais e escala saem dela, e tudo o que vem depois herda qualquer problema que eles tenham.

• O jogo — construído em Three.js com shaders WebGL, então o entregável é uma cena renderizável no navegador, e não um vídeo renderizado. Um shader que compila é um sinal rígido e verificável por máquina, enquanto "parece bonito" não é.

• Som — efeitos procedurais de Web Audio combinados com música do Lyria. Esta é a parte menos conectada ao ciclo de revisão e a mais provável de ser ajustada manualmente por uma pessoa posteriormente.

O mesmo post coloca quatro outras construções 3D ao lado dela, e o padrão se repete: uma exposição interativa em Three.js da construção da Torre Eiffel entre 1887 e 1889 a partir de fotografias históricas e pranchas de engenharia; uma reconstrução em Three.js, com 906.000 triângulos, do escritório Platform 37 do Google, construída ao longo de dez loops noturnos a partir de sete PDFs de planejamento da Câmara Municipal; um visualizador têxtil com rastreamento polar de 110 fibras; e um fortepiano tocável com física de escapamento de 61 teclas. Seja o que for verdade, este não é um prompt de sorte. É um conjunto de execuções com o mesmo formato.

Dois agentes, ou um agente com três funções?

Os relatos dos observadores e o próprio artigo do Google descrevem a mesma execução sob ângulos diferentes, e a diferença é instrutiva. O resumo em chinês mais amplamente compartilhado, de @dotey em 10 de novembro, divide-a em um agente construtor e um agente revisor que verifica suas próprias renderizações. O autor da postagem original, Vamsi Batchu, do Google AI Studio, descreve a mesma coisa como um pelicano coletando chips TPU pelo campus — e credita ao Google Antigravity o recurso/swarm, que o Google descreve como transformar um único prompt em "uma equipe coordenada de agentes que você pode acompanhar em tempo real."

A publicação do Google atribui ao Carbon os papéis, e não à mídia: "design arquitetônico, coordenação e auditoria." Lido em conjunto com a descrição do observador, o formato é o de um construtor que produz geometria e código, e o de um auditor que examina a saída em vez do código-fonte. Essa distinção importa mais do que o número de agentes. Um agente que revisa seu próprio diff tem um sinal fraco; um agente que revisa um quadro renderizado, um shader em compilação ou uma captura de tela do jogo em execução tem um sinal forte, porque a falha é visível no artefato em vez de discutível na prosa.

Duas ressalvas honestas sobre a origem das informações. A separação entre construtor e revisor vem de pessoas descrevendo a execução, não de um diagrama de arquitetura publicado — trate isso como um resumo fiel, e não como uma especificação. E /swarm está em prévia no Antigravity, então a camada de orquestração que você estaria reproduzindo não está disponível para o público em geral.

Há também um detalhe prático que ninguém menciona: o app do AI Studio vinculado exige login do Google. Não consegui abrir o jogo anonimamente — a URL redireciona direto para accounts.google.com. Então, "jogável no seu navegador" significa "jogável se você tiver uma conta do Google e, para o app em si, uma sessão do AI Studio." É uma coisinha que cem repostagens do vídeo ignoraram silenciosamente.

Por que um jogo é um teste mais difícil do que o SVG que ele substituiu

O prompt do pelicano em uma bicicleta pertence a Simon Willison, que o executou contra praticamente todo lançamento de fronteira desde 2024 — primeiro como uma única solicitação de SVG, depois, quando os modelos deixaram de se diferenciar em SVG plano, como prompts 3D: uma página WebGL, renderizações no Blender, esboços em p5.js. O valor do teste nunca foi que um pelicano é difícil. É que a saída é visual, autocontida e instantaneamente julgável por um humano em menos de um segundo.

O que a execução do Carbon faz é levar essa mesma propriedade a um nível maior de dificuldade. Um SVG é um artefato em uma linguagem. Isto é geometria de uma ferramenta, código em outra, um runtime em uma terceira, e uma etapa de revisão que precisa conciliar as três — que é exatamente a classe de tarefa em que o trabalho de agentes de longo horizonte costuma falhar, não no primeiro passo, mas no décimo quarto, quando o modelo já esqueceu a qual sistema de coordenadas se comprometeu.

A síntese do Google sobre a capacidade é precisa e nomeia o mecanismo: para o desenvolvimento de aplicações web, o modelo “executa ciclos de compilação e verificação, recupera-se de erros e verifica tanto seu código quanto a interface renderizada”. Esse é todo o truque, dito sem rodeios. A variável interessante não é quão boa é a primeira tentativa. É quantas vezes o ciclo pode girar antes que o agente pare de melhorar e comece a patinar.

O que a demo não lhe conta

Uma demo de fornecedor é uma amostra selecionada, e a seleção é o objetivo do exercício. Três coisas que ela não consegue responder:

• Com que frequência ele falha. Vemos a execução que terminou. Ninguém publica as onze que travaram, e não há denominador em lugar nenhum na publicação.

• Quanto custou. Dez loops noturnos na build da Platform 37 implicam muitos tokens e muito tempo real. Aos preços da Carbon, isso é um número concreto, e o Google não o divulga.

• Se um modelo mais barato teria sido suficiente. Esta é a pergunta que um leitor deveria realmente fazer, e a demonstração é estruturalmente incapaz de respondê-la.

Para as partes que podem ser medidas, o Artificial Analysis é o contraponto, e seus números são menos lisonjeiros que os do vídeo. O Gemini 4 Carbon em esforço alto obtém 60 no Intelligence Index v5.0.1 — quarto entre 74 modelos, atrás de três configurações do Claude Fable 5.2, com 65, 62 e 62. Seu custo por tarefa do índice é US$ 7,76, ocupando a 61ª posição entre 73 nessa métrica, e ele consome 205 milhões de tokens de saída ao longo do índice, contra uma mediana próxima de 73 milhões: é um modelo prolixo, e o preço por token subestima o custo de uma carga de trabalho do Carbon. A velocidade de saída é de cerca de 82 tokens por segundo, com aproximadamente 67,5 segundos até o primeiro token da resposta — rápido o suficiente por token, mas lento o suficiente até o primeiro para soar como um perfil de lote e espera, e não como o de uma caixa de chat. No Coding Agent Index, o mesmo avaliador colocou o Carbon em 59 com o Antigravity CLI, contra 62 do Claude Code com Opus 5.5.

Nada disso contradiz a demonstração. Um modelo pode ficar em quarto lugar num índice geral, ser caro por tarefa e ainda assim ser o que mantém uma build de quatro horas de pé — são medidas diferentes, e a demonstração é evidência para a terceira, não para a primeira. O que ela não é é prova, e a peça ausente mais barata é a que essa linhagem costuma fornecer. Willison executa o prompt pelican em quase todos os lançamentos e publica os resultados; em novembro de 2026, seus posts sobre o pelican cobrem Claude Fable 5.2 em cinco níveis de raciocínio e Muse Ember em seis, e não há nenhum conjunto Carbon entre eles. Até que um apareça, a demonstração do pelican é um artefato do Google e de mais ninguém — uma build selecionada pelo fornecedor, com descrição escrita pelo fornecedor, e nenhuma execução externa com a qual comparar a taxa de falha.

Quanto custa executar o mesmo loop por conta própria

O Carbon está apenas no nível pago do Google. Não há caminho gratuito: o app AI Studio precisa de uma conta Google, a API precisa de faturamento, e cada token processado é cobrado, incluindo os tokens de raciocínio. A tabela de preços é introdutória e por tempo limitado:

Até 30 de novembro de 2026 — US$ 2,00 por milhão de tokens de entrada, US$ 10,00 por milhão de tokens de saída.

• A partir de 1 de dezembro de 2026 — $4,00 e $20,00, num modelo que não mudou.

• Contexto — 1M de tokens, sem faixa de preço baseada em comprimento, então uma base de código de 900.000 tokens custa o mesmo por token que um prompt de 2.000 tokens.

Coloque a verbosidade ao lado do penhasco e a aritmética fica desconfortável. Um ciclo de construção e revisão é intensivo em saída por natureza: o revisor escreve, o construtor reescreve, e a transcrição cresce a cada turno. Uma carga de trabalho de 100 milhões de tokens de entrada e 20 milhões de tokens de saída custa $400 este mês — $200 de entrada, $200 de saída — e $800 a partir de 1 de dezembro para o mesmo tráfego. Se estiver a fazer um piloto em novembro, calcule o preço do piloto às tarifas de dezembro, ou aprovará um orçamento errado por um fator de dois.

Vale ser explícito sobre onde estamos: o Gemini 4 Carbon não está no catálogo do OrcaRouter, e nada aqui deve ser lido como uma alegação de que está. O que está lá é google/gemini-4-argon ao preço da própria Google de $2 de entrada / $10 de saída — o mesmo card em que o Carbon está este mês — ao lado do DeepSeek V4 Pro a $0.66/$1.98 e do Grok 4.7 a $2/$6, todos em uma única chave compatível com OpenAI em 216 modelos, com o preço de tabela do provedor repassado com 0% de margem para que uma mudança de tarifa do fornecedor chegue no dia em que acontece, e não depois de um ciclo de reprecificação. Para este padrão em particular, isso importa por um motivo entediante: um loop de build multiagente é a carga de trabalho com maior probabilidade de atingir um limite de requisições ou um dia ruim em um provedor, e o failover por uma segunda rota é mais barato do que descobrir o teto no meio de uma execução de dez loops.

Se você quiser copiar a estrutura, copie a etapa de revisão.

A parte transferível desta demonstração não é o Blender, e não é o Three.js. É que o revisor recebeu algo que podia olhar. Três movimentos, em ordem de quanto eles mudam o resultado:

• Faça do artefato a entrada da revisão. Tire um screenshot do app em execução, renderize o frame, compile o shader, execute o teste — e então entregue isso de volta, não o diff. Um agente a quem se pergunta "este código está correto" concordará consigo mesmo. Um agente a quem se pergunta "este screenshot corresponde ao briefing" tem algo com que estar errado.

• Defina um limite para o loop e verifique a convergência. Dez iterações noturnas é o número que o Google cita para uma build. Escolha seu próprio teto e registre se cada rodada realmente melhorou o artefato — um agente que parou de melhorar geralmente é um agente que começou a redecorar.

• Mantenha a cadeia de ferramentas entediante e verificável. Exportações do Blender, Three.js, WebGL e um navegador são todos determinísticos e inspecionáveis. Nada nesta execução depende de um recurso que só um fornecedor possui; depende de um modelo que continuará em frente após a primeira falha.

O que observar a seguir é restrito e específico. Se /swarm sai do preview, porque a orquestração é a parte que você não consegue reproduzir hoje. Se alguém fora do Google publica um Carbon pelican — a versão de Willison é a coisa mais próxima que essa linhagem tem de um resultado independente, e ela não apareceu. E se o intervalo de doze dias entre o anúncio restrito de 28 de outubro e o lançamento geral de 10 de novembro acaba se revelando o padrão, ou a exceção. A demo será citada por meses. O loop por trás dela é o que ou se generaliza, ou não.