- O benchmark OpenSCAD Pantheon testa se ferramentas de IA para código conseguem implementar uma obra arquitetônica em código CAD paramétrico usando apenas 2 imagens de referência e um prompt curto
- Google Antigravity 2.0 / Gemini 3.5 Flash High recebeu a maior nota, 4,5/5 em qualidade, e reproduziu até as dimensões reais do Pantheon, a inscrição e o padrão interno do teto em caixotões
- O Codex 5.5 High teve alta densidade de detalhes, mas perdeu pontos por inconsistência entre a prévia PNG e o STL final, enquanto o Sonnet produziu o modelo mais limpo entre as execuções autônomas anteriores
- O Cursor foi o mais rápido, mas também o de menor qualidade, e o ModelRift/Gemini Flash 3.0 chegou a 3,8/5 com uma abordagem human-in-the-loop com feedback visual
- Todos os sistemas conseguiram executar a renderização via OpenSCAD CLI, mas o gargalo não era o acesso à ferramenta, e sim o julgamento geométrico e a validação da malha final
Objetivo do benchmark e tarefa
- Como o ModelRift gera código OpenSCAD para todos os modelos 3D, a capacidade do LLM de lidar com geometria espacial se conecta diretamente à qualidade real do modelo
- Este teste foi um pequeno benchmark prático em que várias ferramentas de IA para código receberam a mesma tarefa: implementar o Pantheon em OpenSCAD com base em imagens de referência e um prompt curto
- O objetivo era verificar a capacidade de converter material arquitetônico de referência em código CAD paramétrico, renderizar prévias PNG com o OpenSCAD CLI e melhorar o resultado iterativamente
- O prompt exigia incluir a rotunda, a cúpula, o pórtico, as colunas, o frontão e os detalhes da fachada do Pantheon
see two ref images and build .scad file with openscad implementation of pantheon. use openscad CLI (available) to preview your work (by rendering openscad model to .png) and iterate until you are happy with the result.
Por que escolher o Pantheon e o OpenSCAD
- O Pantheon vai além de um simples teste de sintaxe com
difference(),cube()ecylinder(), mas também não envolve geometria orgânica de esculturas ou personagens, que é difícil para o OpenSCAD lidar - Sua estrutura principal é composta por rotunda circular e cúpula, óculo central, pórtico retilíneo, colunas, base em degraus e frontão triangular, o que facilita comparar diferenças nos resultados
- Mesmo um resultado fraco pode parecer um prédio com cúpula, mas um bom resultado precisa acertar com mais precisão a relação entre o tambor circular, o pórtico retangular, os anéis da cúpula e a fachada frontal
- O OpenSCAD é adequado como alvo para geometria gerada por LLM porque o modelo é código em texto puro e o vocabulário é pequeno
- Instruções como “repetir 28 colunas ao redor do raio” ou “subtrair o óculo da cúpula” podem ser expressas diretamente no código-fonte
- O resultado pode ser inspecionado, reproduzido e alterado com facilidade, então erros no espaçamento entre colunas podem ser corrigidos ajustando parâmetros ou loops, em vez de depender de um estado oculto de cena
- O contexto de por que o ModelRift foi construído sobre o OpenSCAD está resumido em Why we built ModelRift on OpenSCAD
- A desvantagem é que o OpenSCAD não é uma ferramenta de escultura, sendo mais adequado para objetos construtivos, paramétricos e hard-surface
Resultado geral
- As notas são uma avaliação relativa dentro deste benchmark, e não um ranking geral de modelos
- A nota de tempo reflete o tempo de implementação observado, não o horário de publicação do projeto
- A nota de qualidade foi atribuída de forma conservadora, e mesmo o melhor resultado ainda não se aproxima de um modelo perfeito do Pantheon
- Resultados por ferramenta e modelo:
- Cursor 3.5 / Composer 2.5: tempo 5/5, qualidade 1,4/5. Foi o mais rápido, mas também o mais fraco; além das grandes formas da cúpula e do pórtico, faltaram proporções, controle de cor e detalhes arquitetônicos
- Codex 5.5 High: tempo 4/5, qualidade 3,0/5. Tinha alta densidade de detalhes, a ponto de incluir a inscrição do entablamento, mas perdeu pontos porque o STL final diferia da prévia PNG
- Claude Code 2.1 / Opus 4.7: tempo 2/5, qualidade 3,0/5. Tinha estrutura, pórtico e base escalonada mais claros que o Cursor, mas a cor era uniforme demais e o resultado foi menos convincente que os melhores
- Claude Code 2.1 / Sonnet 4.6: tempo 1/5, qualidade 3,4/5. Mostrou a impressão geral mais plausível e proporções mais equilibradas entre as execuções autônomas anteriores, mas levou mais tempo para implementar
- Google Antigravity 2.0 / Gemini 3.5 Flash High: tempo 1/5, qualidade 4,5/5. Usou as dimensões reais do Pantheon e a inscrição, e foi o único agente autônomo a implementar o padrão interno do teto em caixotões
- ModelRift / Gemini Flash 3.0: tempo 1/5, qualidade 3,8/5. Foi o melhor resultado não autônomo usando o workflow iterativo com anotações do ModelRift, mas levou cerca de 2x mais tempo que o Claude Code
Observações sobre workflow
- O workflow do cliente foi tão importante quanto o próprio modelo
- O Codex Desktop mostrava diretamente na conversa as imagens que o LLM carregava para o contexto, o que facilitava verificar se as referências estavam realmente sendo usadas em trabalho visual de CAD
- O Cursor Agent e o Claude Code CLI também conseguiam usar imagens, mas o contexto visual aparecia de forma menos explícita durante o processo
- Todos os sistemas testados conseguiam usar a toolchain local do OpenSCAD e chamar o OpenSCAD do
PATHno macOS para renderizar prévias PNG - O gargalo não era o acesso à ferramenta, mas o julgamento geométrico, a configuração de câmera e a capacidade de exportar um modelo de prévia como uma malha final limpa
- O Codex expunha imagens de referência, edição do arquivo OpenSCAD e prévias geradas no mesmo thread, facilitando acompanhar a iteração
- Depois da publicação do benchmark, o Codex tentou corrigir problemas na exportação do telhado e do entablamento, mas a comparação final considerou o modelo originalmente submetido
- O Cursor ofereceu o loop de interação mais rápido e uma UI paralela útil para planejamento e código OpenSCAD, mas a qualidade do resultado ficou atrás das execuções mais lentas
- O Claude Code trabalhou de forma centrada no terminal, lendo imagens e repetindo comandos OpenSCAD, mas o processo de construção do modelo era menos visual
Google Antigravity 2.0 / Gemini 3.5 Flash High
- Explore 3D result
- Esta execução foi adicionada em 22 de maio de 2026, logo após o Google lançar o Antigravity 2.0 na I/O 2026 e anunciar o Gemini 3.5 Flash em 19 de maio de 2026
- O resultado foi o melhor modelo totalmente autônomo deste benchmark, e também um sinal inicial positivo para o Flash 3.5
- O Antigravity 2.0 era mais próximo de um app desktop agent-first com planejamento, execução de tarefas e prévias, e recebeu muitas críticas na semana de lançamento porque usuários que preferiam a experiência IDE anterior não tinham um caminho de retorno suave além de fazer downgrade ou fixar a versão antiga do app
- O Flash 3.5 High não se limitou a estimar as imagens de referência a olho, e sim buscou parâmetros reais do Pantheon
- O plano e o código usaram dimensões explícitas para a rotunda, a cúpula, o pórtico e o óculo, convertendo isso em valores paramétricos no OpenSCAD
Implement a detailed, visually stunning, and dimensionally accurate 3D model of the Pantheon in Rome using OpenSCAD. - Para refletir também a estrutura interna do Pantheon, ele propôs um modo cutaway
To showcase both the exterior (stepped rings, portico) and the interior (coffers, niches, perfect spherical proportion), I will include a toggle in the code `show_cutaway = false;`. - O detalhe mais forte foi o teto
The Pantheon dome interior has 5 rings of 28 coffers. Subtracting these mathematically in OpenSCAD is highly detailed and looks amazing. - O Antigravity foi o único entre os agentes autônomos a implementar o padrão repetido de caixotões quadrados visível através do óculo
- O resultado externo também incluiu elementos normalmente omitidos em saídas rápidas do OpenSCAD
- material das colunas mesclando cinza e vermelho
- inscrição legível
- anéis escalonados do telhado
- relações amplas entre a rotunda, o bloco intermediário, o pórtico e a cúpula
- A nota de qualidade foi 4,5/5, e a de velocidade 1/5
- Não foi rápido, mas elevou o teto de geração autônoma neste benchmark e sugere que o Flash 3.5 é promissor para geração de código espacial quando combinado com ferramentas de planejamento, renderização, inspeção e correção
ModelRift / Gemini Flash 3.0
- Explore 3D result
- Este resultado foi produzido com um processo human-in-the-loop usando ModelRift e Gemini Flash 3.0, e não foi um benchmark autônomo de passagem única como as quatro primeiras execuções
- O workflow levou cerca de 10 minutos e recebeu a mesma nota de velocidade 1/5 por levar aproximadamente o dobro do tempo do Claude Code
- Este benchmark foi executado em 21 de maio de 2026, logo após o anúncio do Gemini 3.5 Flash
- O resultado do Antigravity mostrou que o 3.5 Flash é forte, mas a seleção de modelo padrão do ModelRift também precisa considerar qualidade junto com custo e latência
- A tabela de preços da API Gemini do Google lista o preço padrão do Gemini 3.5 Flash em US$ 1,50 por 1 milhão de tokens de entrada e US$ 9,00 por 1 milhão de tokens de saída, enquanto o Gemini 3 Flash custa US$ 0,50 de entrada e US$ 3,00 de saída
- O Gemini 3.5 Flash representa um aumento de custo de 3x em relação à geração Flash anterior, e é muito mais caro do que a referência de custo da era Gemini 1.5 Flash
- A qualidade foi 3,8/5, melhor do que o lote anterior de execuções autônomas
- O modelo não era perfeito, mas o pórtico, a disposição das colunas, o telhado, as nervuras da cúpula e a massa geral eram mais consistentes
- A principal diferença foi a possibilidade de anexar feedback visual diretamente sobre o render atual
- O workflow do ModelRift foi projetado para repetir geração do modelo, inspeção no navegador, anotações visuais sobre o render e solicitação à IA para corrigir o OpenSCAD
- Em trabalho espacial de CAD, esse loop é muito mais preciso do que instruir apenas por texto
Principais resultados das execuções autônomas
-
Codex 5.5 High
- Explore 3D result
- O Codex 5.5 High gerou o modelo mais denso
- Os elementos incluídos foram rotunda, nervuras da cúpula, óculo, faixas de alvenaria em camadas, pórtico frontal, colunas, detalhes da base ao redor e texto no entablamento
- O entablamento incluía
M AGRIPPA L F COS TERTIVM FECIT - No OpenSCAD, texto é um elemento difícil do ponto de vista de modelagem porque exige posicionamento, extrusão, orientação e espessura fina
- Durante a iteração, a prévia renderizada parecia melhor que o STL final exportado
- No resultado final, surgiu uma superfície parecida com teto com problemas na região do entablamento e do telhado do pórtico, alterando a impressão do conjunto frontal
- O Codex mostrou forte raciocínio espacial e alta ambição de detalhe, mas também expôs o risco de exportação em que a precisão da prévia não equivale à precisão da malha final
- Se a avaliação tivesse sido baseada na melhor prévia PNG em vez do STL publicado, ele teria estrutura e detalhes suficientes para ficar logo abaixo do Antigravity 2.0
- A nota 3,0/5 foi fortemente afetada pela penalidade por divergência entre exportação final e renderização, mais do que pela intenção de design do modelo
-
Claude Sonnet
- Explore 3D result
- O Claude Sonnet gerou o modelo mais limpo entre o lote anterior de execuções autônomas
- Não tentou o mesmo nível de microdetalhe do Codex, mas a silhueta era mais limpa e os principais componentes arquitetônicos se encaixavam com mais naturalidade
- Cúpula, tambor, pórtico e disposição das colunas eram lidos como um único edifício, e não como um agrupamento de primitivas adjacentes
- As proporções também eram mais contidas, e antes da execução do Antigravity este era o resultado totalmente autônomo mais forte
- O Claude Code foi cerca de 2 a 3 vezes mais lento que o Codex neste benchmark, e o Sonnet recebeu a menor nota de tempo apesar da boa qualidade
- A nota de qualidade foi 3,4/5, ainda ficando no nível de um modelo aproximado, e não de uma reconstrução arquitetônica pronta para produção
-
Cursor Composer
- Explore 3D result
- A combinação de Cursor e Composer 2.5 foi a execução mais rápida, mas o resultado foi o mais fraco
- Acertou os grandes gestos da rotunda, da cúpula, do pórtico e das colunas
- Mas deixou de lado a contenção de materiais e a nuance arquitetônica que fazem o Pantheon ser reconhecível
- A saída ficou mais próxima de um placeholder simplificado do que de um modelo concluído, em um nível que exigiria bastante retrabalho antes da publicação
-
Claude Opus
- Explore 3D result
- O Claude Opus ficou entre o Cursor e o Sonnet
- Produziu um edifício mais completo que o Cursor, com pórtico e base escalonada mais claros
- Mas a saída era uniforme demais e menos convincente que a do Sonnet
- Havia estrutura, mas faltava julgamento de hierarquia visual
- Como quase todos os elementos tinham a mesma cor e peso, os detalhes competiam entre si em vez de guiar o olhar
- A nota atualizada foi 3,0/5, merecendo uma avaliação melhor que a da primeira versão da tabela, mas ainda atrás de Sonnet e Antigravity
Principais lições
- O OpenSCAD se manteve bem como linguagem-alvo
- A sintaxe é pequena, a saída é determinística e a CLI renderiza prévias inspecionáveis no loop iterativo
- Os LLMs não precisaram de nenhuma adaptação especial para usar o OpenSCAD
- O uso da ferramenta não era o gargalo
- Todos os agentes chamaram o OpenSCAD no
PATHdo macOS e renderizaram prévias PNG - A parte difícil não era a infraestrutura, e sim o julgamento geométrico
- Todos os agentes chamaram o OpenSCAD no
- Velocidade não previu qualidade
- O Cursor foi o mais rápido, mas entregou o pior resultado
- O Sonnet foi o mais lento entre as execuções autônomas anteriores, mas produziu o modelo mais limpo
- O Antigravity também foi lento, mas o Gemini 3.5 Flash High entregou o melhor resultado autônomo depois de ter tempo para planejar e iterar
- O ModelRift/Gemini Flash 3.0 levou mais tempo, mas alcançou qualidade superior à do lote autônomo anterior graças ao feedback visual
- Prévia e exportação não são a mesma coisa
- O Codex parecia forte no loop de renderização, mas apresentou problemas geométricos ao redor do telhado do pórtico no STL final
- Modelos destinados a impressão precisam ter a malha exportada inspecionada separadamente, e não apenas a prévia
- Nenhuma saída ainda passou no nível de um modelo arquitetônico fiel
- A inscrição do Codex foi um bom detalhe
- As proporções do Sonnet foram consistentes
- O teto em caixotões do Antigravity foi o detalhe mais impressionante
- O resultado do ModelRift/Gemini Flash 3.0 mostra como a qualidade sobe quando uma pessoa faz ajustes visuais
- Com apenas duas imagens de referência e um prompt curto, todos os sistemas chegaram a um OpenSCAD válido e renderizável sem escrever código CAD manualmente
- A diferença de qualidade entre as ferramentas foi grande, mas o ponto de partida em si foi mais alto do que o esperado
- A geração totalmente autônoma ainda não é o workflow certo para esse tipo de tarefa
- No ModelRift, o trabalho iterativo ainda usa o Annotation Mode
- Trata-se de desenhar setas e notas diretamente nas capturas de tela do modelo 3D e devolver isso para a IA
- Em geometria espacial, a etapa human-in-the-loop é importante mesmo usando os melhores modelos
- O modelo pode acertar os grandes volumes e ainda errar a posição das colunas ou as proporções da cúpula
- Apontar diretamente os problemas sobre o render é mais rápido e preciso do que descrevê-los em texto
1 comentários
Comentários no Hacker News
Na semana passada comprei a bicicleta da minha esposa no Marketplace, e ela estava em bom estado, mas faltava uma borracha/tampinha de roteamento interno de cabos
Coloquei no Claude uma foto isolada do furo em formato de cápsula, junto com outra foto medindo o lado maior e o menor com um paquímetro digital, e ele criou, com um prompt curto, um modelo em OpenSCAD com todas as dimensões parametrizadas
Imprimi em TPU sem nenhuma modificação, ficou quase perfeito já na primeira tentativa, e quando reduzi de 0,3 mm para 0,1 mm o desconto que o Claude tinha aplicado nas dimensões x/y, encaixou certinho. É uma forma muito mais simples do que arquitetura da Roma Antiga, mas ainda assim é incrível que isso funcione tão facilmente
Tive uma experiência parecida criando peças funcionais simples para impressora 3D com OpenSCAD e LLMs, e sei também que os modelos não são tão bons nisso quanto em gerar código React, além de eu ser o oposto completo de um operador experiente. Mesmo assim, é legal que isso tenha me levado a começar a aprender uma habilidade nova como hobby
A verdadeira mágica seria o momento em que você entrega só uma dimensão ou uma foto com régua e a IA deduz o resto, mas pelo menos hoje o Claude ainda é bem fraco em inferência
É realmente impressionante a frase de que “o Antigravity foi o único agente autônomo a implementar o padrão característico do teto interno do Pantheon, ou seja, o teto de caixotões quadrados repetidos visível através do óculo”
Mesmo tendo visto o modelo 3D, eu nem cheguei a pensar em olhar o interior até ler essa frase
O modelo 3D com
show_cutawayativado está aqui: https://modelrift.com/models/pantheon-benchmark-antigravity-...Se você quer o “Pantheon”, claramente faz sentido, mas acho que um desenhista técnico ou engenheiro teria dificuldade em aceitar esse tipo de resultado
Não sei em qual benchmark o Antigravity ficou em primeiro, mas o meu Antigravity, que substituiu à força o Gemini CLI, pede login no navegador toda vez que uso, e o Antigravity IDE nem atualiza
Se possível, queria que acertassem primeiro o mínimo de qualidade de entrega aceitável antes de se preocupar em ficar em primeiro lugar em alguma coisa
O título real é “OpenSCAD LLM Benchmark: Building the Pantheon”
Mesmo assim, os próprios modelos de LLM são bons e o Antigravity 2.0 também não é tão ruim. Só que, se como muita gente você perdeu as configurações e projetos do Antigravity 1.0, a história muda
O Gemini 3.5 Flash é estranho. O cutoff é antigo; em alguns aspectos ele é melhor que o 3.1 Pro, mas em outros é pior, e às vezes é mais barato, às vezes mais caro que o 3.1 Pro
O Antigravity parecia abandonado e as pessoas especulavam que seria encerrado, e de certa forma foi isso mesmo, já que migraram todo mundo para o novo Antigravity
Dá a sensação de que o Google simplesmente transformou seu organograma em produtos; há produtos de IA demais, e nenhum parece ser o melhor da categoria. Por exemplo, a integração do Gemini no Google Docs é pior que o Claude
Eu esperava um modelo com “inteligência de nível Opus pelo custo de Haiku” ou “desempenho de nível Sonnet pelo preço do Gemini 3.0”. Se tivesse vindo qualquer um dos dois, seria um modelo principal e um concorrente do Claude/Codex, mas não recebemos nenhum deles
Fico curioso sobre o que exatamente não é coberto pela combinação Antigravity CLI + VS Code ou por outras IDEs
Mas o e-mail enviado na quarta-feira, no estilo “obrigado por assinar o Google One AI Pro, agora vamos adicionar limitações à sua conta; não tem o que fazer”, foi realmente desagradável. Antes disso eu até elogiava a assinatura AI Pro pelo custo-benefício
Fico feliz que o Google esteja investindo nisso, mas quanto mais velho fico, mais eu protejo meu fluxo de trabalho
Já rodei muitos benchmarks no OpenSCAD com todo tipo de modelo e configuração, e a conclusão foi a seguinte
Os modelos são inconsistentes: podem ser excelentes para um tipo de modelo 3D e ruins para outro
Pela minha experiência, os modelos Gemini são os menos inconsistentes e têm a melhor compreensão de imagem
Os modelos Gemini também são os mais criativos, mas isso pode até ser indesejável se você quer uma peça CAD precisa
No geral, esse benchmark não prova muita coisa. Um único modelo 3D e uma única tentativa não bastam. Normalmente eu testo pelo menos 12 modelos, 3 vezes cada um, mas na verdade o ideal seria muito mais. Só que isso fica caro demais para um desenvolvedor individual
Ainda assim, obrigado por publicar, e pretendo rodar o Flash 3.5 em breve para ver como se sai
É um benchmark interessante avaliar LLMs pela capacidade de gerar modelos CAD 3D válidos
O OpenSCAD combina especialmente bem com esse tipo de avaliação, já que depende inteiramente de código
Quando tentei na prática, a experiência foi bem ruim. Na primeira tentativa pode até sair um rascunho mais ou menos aceitável, mas quando você começa a “depurar” aquilo, acaba chegando a uma sessão extremamente frustrante e percebe que o modelo não consegue realmente “ver” o resultado direito
Ou seja, ele não consegue fazer melhoria iterativa de verdade
Parece que a maioria das ferramentas de execução ou harnesses redimensiona as imagens antes de processá-las, e nesse processo se perdem detalhes a ponto de dificultar a inferência, especialmente em imagens wireframe
Posso estar usando errado, mas este teste não verificou isso de fato. Foi só uma tentativa única, e esse método desmorona bem rápido. Ainda mais se não houver uma foto de referência do que você quer criar
Fazer um objeto do mundo real e declarar isso como benchmark não é uma forma robusta de avaliar ferramentas
Deveria ser algo tipo Iron Chef: dar o tema de arquitetura grega e deixar um júri decidir o vencedor. Do jeito que está, é basicamente ver qual ferramenta fez um Pantheon subjetivamente mais convincente
Estão avaliando um exemplo único e mal definido, sem caso de uso final e com um critério de pontuação totalmente subjetivo
Ainda falta bastante para sair vendendo Autodesk a descoberto
Para referência, a Autodesk lançou em dezembro um assistente agêntico para o Fusion, e mesmo 6 meses depois ele continua bem ruim
Nas últimas semanas precisei projetar algumas peças simples para impressão 3D e testei isso; embora cada uma exigisse algo como 4 operações na timeline, mesmo descrevendo tudo em detalhes passo a passo e usando a nomenclatura do Fusion, ele não conseguiu chegar nem perto do que eu queria
Neste momento, nem tenho confiança de que ele consiga criar corretamente um sólido básico simples
Não me convence muito. O Pantheon é um dos edifícios históricos mais icônicos que existem, então há muitos livros sobre ele, além de muitas fotos e modelos públicos que provavelmente já entraram no treinamento
Um benchmark em que se modelasse uma estrutura anônima apenas com base nas referências fornecidas pareceria mais interessante. Do jeito que está, parece aquela mágica superficial de ver um LLM criar um app de tarefas de primeira
Estou criando um dispositivo tecnológico para cuidados infantis, e a carcaça externa foi gerada inteiramente por IA
Eu não fazia a menor ideia de por onde começar em modelagem 3D, e o LLM me mostrou que isso, como muitas outras coisas, também é código
Curiosamente, o Opus 4.5 fez tudo perfeitamente de primeira, e isso foi logo antes da polêmica sobre degradação de desempenho; desde então, até fazer alterações mínimas na carcaça ficou muito difícil
Parece que o Opus passou de um modelo que rotacionava formas profissionalmente na cabeça para um modelo que nem entende o que está manipulando
Mas o 4.7 foi razoável para fazer revisões