GLM 5.2 vs Opus
(techstackups.com)- Ao pedir que criassem um jogo de plataforma 3D em WebGL bruto com o mesmo prompt one-shot, o Opus entregou um resultado mais rápido e mais acabado, enquanto o GLM-5.2 mostrou vantagens em custo mais baixo e pesos abertos
- O GLM-5.2 é um modelo de pesos abertos sob licença MIT da Z.ai, com contexto de 1M tokens e níveis de raciocínio High/Max, mas por ser somente texto tem limitações para autoverificação baseada em imagem
- No teste real, o custo do GLM-5.2 foi de US$ 5,39, enquanto o do Opus foi de cerca de US$ 21,92; os tempos de build foram de 1h10min40s e 33min30s, respectivamente, dividindo a escolha entre velocidade e custo
- O resultado do GLM-5.2 teve problemas básicos como texturas ausentes, espinhos sem funcionamento, ausência de condição de vitória e overlay de depuração remanescente; o Opus ficou mais limpo, mas ainda com colisão permissiva em plataformas suspensas e gatilho de vitória distante
- Em benchmarks e avaliações externas, o GLM-5.2 aparece como um forte modelo de pesos abertos, mas o Opus fica à frente em muitas tarefas de coding e agentes; custo, abertura e julgamento visual acabam sendo os critérios de escolha
Diferenças reveladas na mesma tarefa
- O GLM-5.2 é um caso recente que mostra o potencial dos modelos abertos, mas na mesma tarefa prática o Claude Opus 4.8 produziu um resultado mais rápido e mais preciso
- O teste consistiu em dar aos dois modelos o mesmo prompt one-shot e pedir que criassem do zero um jogo de plataforma 3D para navegador em WebGL bruto, sem engine de jogo ou biblioteca de renderização 3D como Three.js
- Os dois resultados e seus códigos-fonte estão públicos
- Ambos os jogos usam assets gratuitos em CC0 do Kenney Platformer Kit
Natureza e abordagem do GLM-5.2
- O GLM-5.2 é o mais novo modelo flagship da Z.ai e é oferecido com pesos abertos sob licença MIT
- É possível baixá-lo e executá-lo diretamente ou chamá-lo via API da Z.ai
- Os pesos estão no Hugging Face e no ModelScope, sem restrição regional
- É possível servi-lo localmente com frameworks como vLLM, SGLang e Transformers
- O modelo mira tarefas de longo horizonte como trabalhos de agentes de código em várias etapas e longa duração
- Ele oferece uma janela de contexto de 1M tokens
- Há níveis de raciocínio High e Max, e no teste foi usado o High
- A limitação decisiva é ser somente texto
- O GLM-5.2 não consegue ler imagens
- Fluxos de trabalho que exigem verificar diretamente screenshots ou diagramas precisam de um modelo multimodal como o Claude Opus
Preço e custo de execução
- Segundo a documentação dos fornecedores, o preço por 1M tokens do GLM-5.2 é menor que o do Opus
- Claude Opus 4.8: entrada US$ 5, leitura de cache US$ 0,50, saída US$ 25
- GLM-5.2: entrada US$ 1,4, leitura de cache US$ 0,26, saída US$ 4,4
- Em tokens de saída, o GLM-5.2 custa menos de um quinto do Opus
- No teste real de criação do jogo, tempo e custo acabaram seguindo em direções opostas
| Métrica | GLM-5.2 (Pi/OpenRouter) | Opus (Claude Code) |
|---|---|---|
| Tempo total de build | 1h 10min 40s | 33min 30s |
| Tokens de saída | 131.000 | 216.809 |
| Uso máximo de contexto | 16% de 1M | 19% de 1M |
| Chamadas de ferramenta | 128 | 153 |
| Custo | US$ 5,39 cobrados de fato | cerca de US$ 21,92 estimados |
- O Opus terminou em cerca de metade do tempo, e o GLM-5.2 concluiu o trabalho com custo bem menor
Tarefa de teste: jogo de plataforma 3D em WebGL bruto
- A tarefa tinha uma estrutura mais complexa do que gerar uma landing page simples
- Parser de modelo GLB
- Matemática de matrizes e vetores
- Shaders GLSL
- Animação esquelética com skinning
- Loop de timestep fixo
- Tratamento de colisão
- Câmera de acompanhamento
- Os dois modelos receberam o mesmo prompt, os mesmos assets e uma única tentativa sem dicas
- As condições de conclusão eram as seguintes
- Engine e renderizador 3D baseados em WebGL bruto
- Loader para o personagem 3D e para o modelo do mundo fornecidos
- Movimento e pulo do personagem com gravidade e colisão
- Câmera de acompanhamento e controles por teclado
- Jogo completo executável no navegador com um único comando
- Ambos os modelos implementaram por conta própria boa parte de um parser binário de GLB, matemática de matrizes e quaternions, renderizador WebGL2, shaders GLSL com skinning e colisão AABB com substeps
- Os registros de build também estão públicos
Resultado ao jogar e bugs restantes
- Os dois jogos assumem a forma de um jogo de plataforma 3D em terceira pessoa
- Movimentação com WASD ou setas
- Pulo com Space
- Corrida com Shift
- Rotação da câmera com arrastar do mouse
- Zoom com a roda do mouse
- Objetivo de coletar moedas, evitar espinhos e chegar à bandeira
- Ao cair para fora do mapa, o jogador volta ao ponto inicial
-
Resultado do GLM-5.2
- O jogo do GLM-5.2 mostrou um acabamento bruto no geral
- Faltavam alguns materiais do personagem, e havia um problema em que ele andava virado na direção oposta ao movimento
- As armadilhas de espinhos não matavam nem resetavam o personagem, e alcançar a bandeira não ativava a condição de vitória
- A cabeça desaparecia quando a câmera se movia, e também restava um overlay de depuração
- A parte em que o personagem salta até a próxima plataforma ao pisar na mola funcionava bem
- Os modelos da Kenney referenciam uma paleta de cores compartilhada em um arquivo separado, mas o renderizador do GLM-5.2 não carregou esse arquivo, substituindo-o por cores chapadas
-
Resultado do Opus
- O jogo do Opus ficou mais limpo e funcional
- A câmera e o controlador funcionavam, e a lógica dos espinhos matando o jogador também funcionava
- As texturas foram aplicadas corretamente, as animações ficaram suaves e era possível vencer ao chegar à bandeira
- Os bugs restantes estavam mais próximos de casos de borda do que de falhas básicas
- O personagem podia ficar em pé por um instante no ar ao lado da plataforma, resultado de um tempo de tolerância coyote-time configurado de forma excessiva, permitindo pular logo após sair da borda
- A condição de vitória era acionada mesmo ainda estando relativamente longe da bandeira
Diferença multimodal exposta na autoverificação
- Ambos os modelos receberam instruções para validar o resultado antes de concluir o trabalho
- O Opus, por ser multimodal, renderizou o jogo e inspecionou diretamente screenshots capturadas
- Ele viu os indicadores de depuração ainda presentes na tela, removeu-os e então finalizou
- Na cena final, conferiu blocos, escadas, moedas, gemas, espinhos, bandeira, personagem, HUD de pontuação, iluminação e geometria
- O GLM-5.2 não consegue ler imagens, então não pôde ver as screenshots diretamente
- Em vez disso, usou uma abordagem alternativa lendo dados brutos de pixels para verificar se as cores batiam aproximadamente com o esperado
- Na imagem salva, checou condições de cor como grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit, no black
- Esse método deixou escapar problemas reais da tela
- O personagem aparecia cinza e com texturas ausentes
- O overlay de depuração ainda permanecia sobre a tela
- Em tarefas nas quais o resultado visual importa, a validação multimodal capaz de entender imagens se traduz em diferença real de qualidade
Posição mostrada nos benchmarks
- Nos benchmarks do model card da Z.ai, o GLM-5.2 apareceu logo atrás dos melhores modelos fechados em muitos itens, e superou alguns deles em certos benchmarks de raciocínio
- Os principais números foram os seguintes
- HLE: GLM-5.2 40,5, Opus 4.8 49,8
- HLE with tools: GLM-5.2 54,7, Opus 4.8 57,9
- AIME 2026: GLM-5.2 99,2, Opus 4.8 95,7
- IMOAnswerBench: GLM-5.2 91,0, Opus 4.8 83,5
- SWE-bench Pro: GLM-5.2 62,1, Opus 4.8 69,2
- NL2Repo: GLM-5.2 48,9, Opus 4.8 69,7
- ProgramBench: GLM-5.2 63,7, Opus 4.8 71,9
- SWE-Marathon: GLM-5.2 13,0, Opus 4.8 26,0
- MCP-Atlas public: GLM-5.2 76,8, Opus 4.8 77,8
- Tool-Decathlon: GLM-5.2 48,2, Opus 4.8 59,9
- A execução independente da ArtificialAnalysis também avalia o GLM-5.2 como um forte modelo de pesos abertos
- Pontuação 51 no Intelligence Index v4.1
- Acima de MiniMax-M3 44, DeepSeek V4 Pro 44 e Kimi K2.6 43
- O TerminalBench v2.1 ficou em 78%, usando um harness diferente dos 81 ou 82,7 do model card
- Os tokens de saída por tarefa ficaram em cerca de 43k, mais do que os 26k do GLM-5.1
- A tendência dos benchmarks é parecida com a do teste prático
- O GLM-5.2 está entre os líderes entre os modelos de pesos abertos e tem alguma competitividade em raciocínio
- O Opus fica à frente em muitos benchmarks de coding e agentes
Reações externas
- Simon Willison avaliou o GLM-5.2 como “provavelmente o LLM de pesos abertos somente texto mais poderoso”
- No teste de SVG dele, o GLM-5.2 gerou um pelicano andando de bicicleta totalmente animado e sem partes quebradas
- Já o teste do gambá em um scooter foi pior do que no GLM-5.1 anterior, mostrando que o desempenho não é uniforme
- A Artificial Analysis avaliou o GLM-5.2 como o modelo de pesos abertos líder em seu próprio Intelligence Index
- Considera-o o modelo mais barato naquele nível, posicionado na fronteira entre custo e inteligência
- Mas também o classifica como um modelo que consome muitos tokens, com cerca de 43k tokens de saída por tarefa
- Nathan Lambert avaliou que, pelo leaderboard do LMArena, o GLM-5.2 poderia até ser visto como um agente melhor que o Gemini, e o considerou uma “serious accomplishment” para um modelo aberto sob licença MIT
- Ele destaca que os principais modelos dos EUA ainda estão à frente no geral, mas que laboratórios chineses vêm alcançando pontuações altas com menos computação
Qual modelo escolher
- O GLM-5.2 é um modelo de pesos abertos com desempenho forte por uma fração do preço do Opus
- É adequado quando custo e abertura são importantes e o trabalho é principalmente centrado em texto e lógica
- Pesos baixáveis não podem ser aposentados de repente nem restringidos como modelos fechados
- O Opus entregou no teste um resultado mais rápido, mais limpo e mais preciso
- Ele consegue ver e validar diretamente resultados visuais
- É mais adequado para trabalhos em que precisão, acabamento e julgamento visual importam e o custo é aceitável
- O GLM-5.2 está mais para um forte modelo auxiliar, barato e sempre acessível, do que para um modelo principal capaz de substituir o Opus
1 comentários
Opiniões do Hacker News
Realmente não entendo por que existe tanto alvoroço em torno de prompting de uma vez só
Por definição, um único prompt não consegue conter a complexidade de um projeto de software. No fim, o modelo só entrega um resultado fazendo várias suposições com base no código existente no corpus de treinamento
Eu preferiria ver um agente de codificação que siga com precisão as etapas de um arquivo de planejamento, respeitando guardrails de especificações revisadas por humanos e convenções de código. Também seria preciso verificar se o loop do agente consegue cumprir o objetivo definido por humanos sem sair dos guardrails nem se desviar até a conclusão
Além disso, uma métrica muito mais valiosa é a capacidade de entender o contexto do caso de uso que se quer construir, encontrar possíveis bugs ou melhorias de desempenho no código existente e sugerir refatorações
Mais do que um benchmark para ver se a saída corresponde à entrada, é algo mais próximo de verificar se o artefato produzido é internamente consistente. Num jogo, por exemplo, isso seria ver se ele termina ao alcançar o objetivo, se morre ao tocar nos espinhos e se não surgem casos de borda estranhos ao se mover
Ainda assim, acho que deveriam ter usado o mesmo ambiente de execução e repetido o experimento várias vezes para observar também a variância dos resultados
Antigamente eu zombava de engenheiros que testavam algo seguindo o README de um framework num projeto vazio e depois diziam “esse framework é o melhor para o nosso app de produção com 10 anos”. O pensamento greenfield é a solução para todos os problemas e o problema de todas as soluções
Capacidade de one-shot também é uma métrica autorreferente importante e deve ser medida, mas deveria ser em cima de uma grande base de código já estabelecida
Claude Code e Opus chamaram muita atenção porque o ambiente de execução melhorou a ponto de conseguirem corrigir muitos erros por conta própria sem intervenção do usuário. No longo prazo, acho que as maiores melhorias virão de autonomia de várias horas e capacidade de auto-correção
Gerar milhões de tokens a partir de alguns poucos tokens de entrada, na minha opinião, não transmite muito significado
Para avaliar modelos melhores, basta adicionar mais requisitos à tarefa. Mesmo que não seja um caso de uso realista, acho um método útil
Claro, quando um engenheiro de software os conduz, os modelos podem produzir resultados muito melhores. Dependendo do engenheiro, também podem produzir resultados piores
Uma execução única em one-shot do tipo “coloquei Claude Opus 4.8 frente a frente com o mesmo prompt one-shot: criar do zero um jogo de plataforma 3D em WebGL puro” não é benchmark e também não representa o uso real
A maior parte do uso de agentes é colaborativa, então seria preciso testar confiabilidade, como ver se ele conclui a tarefa sem inventar resultados de testes, e controlabilidade, como ver se ele segue minhas instruções ou faz o que bem entende
Este teste mostra o que os dois modelos conseguem fazer quando recebem uma tarefa one-shot longa e tecnicamente difícil
Acho que formatos que avaliem colaboração, delegação de tarefas, conclusão, desenvolvimento orientado a testes e controlabilidade são ótimos testes para tentar no futuro
Pensando bem, a maior parte do trabalho com agentes que eu faço consiste em subagentes rodando com seus próprios prompts dentro da sessão principal. Isso também pode ser visto como uma versão curta de trabalho totalmente autônomo
O texto também fala disso, e a intenção nunca foi apresentar isso como benchmark formal. Já existem benchmarks formais de sobra
A Anthropic continuava me devolvendo 529 Overloaded, então ontem me cadastrei no GLM 5.2 para experimentar
Gostei, mas uma única sessão com 2 prompts no xhigh do GLM 5.2 já consumiu 22% do uso do plano light na janela de reset de 5 horas
Fiquei satisfeito com o resultado, e a qualidade também é boa. Como quero usar os dois, seria ótimo se existisse um plano de assinatura unificado que permitisse usar Anthropic e GLM juntos
A sensação que tive usando o GLM 5.2 em alguns projetos é que ele demora bastante para começar a escrever código e de jeito nenhum é um modelo rápido
Na fase de exploração e planejamento ele se perde bastante, mas depois se corrige; não é fácil de controlar, porque alucina coisas que depois nem vai seguir. Mesmo assim, a qualidade da saída é muito boa
Por exemplo, eu estava otimizando rendering em uma base de código Swift+Zig e travava em 5 mil itens de dados. O GLM 5.2 passou 20 minutos criando benchmarks e extraindo dados; fiquei frustrado, bloqueei o acesso a ferramentas fora da edição e saí. Cerca de 30 minutos depois, quando voltei, ele já tinha otimizado 3 gargalos com base no benchmark que havia criado e em algumas “conclusões”, e também disse que precisava de mais dados porque não conseguia validar suas suspeitas
A implementação funcionou bem e foi idiomática e não intrusiva. Dá até para dizer que foi mais idiomática do que o resultado produzido pelo GPT 5.5 no mesmo repositório. Quero usar mais, mas o GPT normalmente conclui o mesmo pedido 5 vezes mais rápido
Por causa do GLM 5.2, acabei preparando uma configuração para executar vários em paralelo dentro de contêineres isolados e workspaces do JJ
O problema era interceptar o clique esquerdo na barra de menus do macOS e fazer com que Ctrl+clique ou clique direito abrissem o menu como se fossem o clique esquerdo original, mas com comportamento condicional
No meio da sessão de resolução do problema, troquei o modelo para GLM-5.2; nem reenviei o prompt, só mudei no meio do raciocínio, e alguns minutos depois o problema estava resolvido. Usei isso dentro da alocação por assinatura do OpenCode Go, e esse tipo de problema poderia facilmente consumir toda a cota do Opus na janela atual de 5 horas ou até mesmo o limite semanal
Dá para perceber quando o modelo sai dos trilhos ou encontra algo que eu não tinha mencionado, então posso interromper e corrigir. Ou posso aprender por que ele fez certas escolhas, o que reduz a necessidade de ficar me perguntando isso depois
Minha experiência é parecida. Estou usando no Pi, e ele é inteligente e a saída é boa, mas o processo para chegar lá não é eficiente
Está escrito que “o GLM-5.2 não conseguia ler imagens, então o problema surgiu aí. Ele não é multimodal. Então, em vez de olhar a captura de tela, usei a gambiarra de escrever um script que lia os dados brutos dos pixels e verificava se as cores saíam mais ou menos como esperado”, mas um jeito melhor é usar https://github.com/openbmb/MiniCPM-V
Se realmente quiser, também pode fazer ele chamar o Opus para imagens, e mesmo assim provavelmente vai economizar
Assinei o Ollama para experimentar modelos open source
Nos últimos 3 meses eu estava mais no nível de testar e brincar, mas o GLM é o primeiro modelo que uso diariamente junto com o Claude em trabalho real de programação. É bem bom, a ponto de eu bater no limite diário de uso do Ollama todo dia
O GLM usa menos tokens e também faz menos chamadas de ferramenta, mas leva mais que o dobro do tempo para concluir
Se esse tempo não está sendo gasto no comportamento do modelo em si, fico me perguntando onde ele está sendo gasto
Será que cada chamada de ferramenta é mais complexa e por isso demora mais, ou será que o modelo faz mais computação por token e por isso tem menos tokens por segundo?
Além disso, alguns modelos open-weight como GLM 5.2 e DeepSeek v4 Pro têm geração de tokens bem mais lenta, o que afeta a latência percebida. Mesmo assim, é difícil chamar o GLM 5.2 de lento; por exemplo, no Notion ele é um dos modelos mais rápidos no momento
Outra possibilidade é o Opus usar algo como Mixture of Experts, então a parte do modelo carregada na memória de uma vez pode ser menor que no GLM
O GLM 5.2 tem um grande problema que limita um sucesso significativo: o valor da assinatura para programação
Só olhando o preço da API, o GLM 5.2 vence os concorrentes. Mas usar cobrança por API para trabalho de programação é coisa mais de grandes empresas, e para elas os produtos por assinatura fortemente subsidiados estão desaparecendo cada vez mais
Ao mesmo tempo, essas empresas não vão deixar seus funcionários usarem APIs chinesas
Para indivíduos e equipes pequenas, a assinatura de programação da Z.ai é inferior à da Anthropic e da OpenAI. Talvez dê para obter um uso parecido com o Claude, mas o Codex claramente oferece mais uso pelo valor pago
Dá para discutir o quanto a Z.ai alcançou o GPT5.5 e o Opus 4.8, mas num mundo em que tudo custe o mesmo e eu possa escolher livremente, eu não escolheria o GLM
Portanto, a pergunta importante é o quanto o produto da Z.ai vai melhorar no GLM 5.3 ou 6, e o quanto OpenAI e Anthropic vão restringir seus produtos atuais num futuro próximo
Construir infraestrutura em torno de uma IA que não possa ser retirada a qualquer momento tem valor imediato para essas empresas. Outros países fora da Europa são mais sensíveis a preço e também não têm o mesmo medo de se relacionar com empresas chinesas
Ao mesmo tempo, se “essas empresas não deixam seus funcionários usarem APIs chinesas”, então fico pensando para quem a Amazon Bedrock, que oferece GLM, está mirando
Indivíduos provavelmente escolherão provedores americanos mais baratos, como a DeepInfra. A entrada em cache do GLM custa $0.18 por 1 milhão de tokens, e o Opus custa $0.50. Fireworks AI também é uma opção
Funcionários e estudantes que se acostumarem a programar usando milhares de dólares em tokens em planos de 20 ou 100 dólares vão pressionar por esse gasto nas empresas
O surgimento de um modelo chinês competitivo não vai substituir esse gasto corporativo, mas modelos abertos hospedados nos EUA ou na UE podem fazer isso
A existência do GLM 5.2 cria um teto para o preço que OpenAI e Anthropic podem cobrar pelo acesso à API
Meu palpite é que a maior parte do trabalho está sendo feita em planos de programação
Só acho irritante que os planos sejam restritivos demais além do limite de uso. Eu entendo, mas é inconveniente. Na prática, só a Anthropic e talvez o Google parecem realmente rígidos nesse ponto
A Anthropic assustou as pessoas com uma política segundo a qual pode cobrar depois pela tarifa de API se considerar que o uso não está de acordo com os termos de serviço. Talvez seja um medo sem fundamento, mas parece algo que eles realmente fariam, então acabo evitando
Só que a infraestrutura deles estava claramente sobrecarregada, e 100% das requisições de chat do 5.2 deram timeout. Vou tentar de novo depois, quando a infraestrutura alcançar o desempenho do modelo, e só então poderei julgar se a assinatura vale a pena
Hoje fiquei surpreso porque o GLM-5.2 foi muito melhor que o GPT-5.5 em senso estético e trabalho de UI
Por enquanto vou manter minha configuração de Claude/Codex via Conductor, mas por causa desse modelo acabei configurando o OpenCode e baixando o app de desktop, então fiz a maior parte do meu trabalho de hoje por lá
Quando leio frases como “o GLM-5.2 custou muito menos. O Opus terminou em metade do tempo e entregou um jogo mais limpo”, eu percebo imediatamente um estilo de escrita de LLM
Parece que todos os modelos convergiram para esse estilo de escrita, e mesmo com a melhora de desempenho essa parte não parece mudar muito
O setor de redação técnica está sofrendo um grande impacto no momento. As empresas estão exigindo mais trabalho em menos tempo, a qualidade caiu bastante e, por isso, está cada vez mais difícil encontrar tempo no dia a dia para lapidar a qualidade das frases
Estamos trabalhando bem na linha de frente dessa mudança, então somos os mais afetados, mas ao mesmo tempo é estimulante e extremamente frustrante poder experimentar essas mudanças primeiro