GLM 5.2 vs Opus
(techstackups.com)- Con el mismo prompt de una sola toma para crear un juego de plataformas 3D en raw WebGL, Opus produjo un resultado más rápido y pulido, mientras que GLM-5.2 destacó por su menor costo y sus pesos abiertos
- GLM-5.2 es un modelo de pesos abiertos con licencia MIT de Z.ai, con contexto de 1M de tokens y niveles de razonamiento High/Max, pero al ser solo de texto tiene limitaciones para la autoevaluación basada en imágenes
- En la prueba real, GLM-5.2 costó $5.39 y Opus alrededor de $21.92; los tiempos de compilación fueron de 1 hora 10 minutos 40 segundos y 33 minutos 30 segundos, respectivamente, mostrando un intercambio claro entre velocidad y costo
- El resultado de GLM-5.2 tuvo problemas básicos como texturas faltantes, pinchos que no funcionaban, ausencia de condición de victoria y una superposición de depuración visible; Opus fue más limpio, aunque todavía dejó una detección imprecisa en plataformas aéreas delgadas y un disparador de victoria demasiado lejano
- Tanto en benchmarks como en evaluaciones externas, GLM-5.2 aparece como un fuerte modelo de pesos abiertos, pero Opus aventaja en muchas tareas de programación y agentes; la elección termina dependiendo de costo, apertura y juicio visual
Diferencias visibles en la misma tarea
- GLM-5.2 es un caso reciente que muestra el potencial de los modelos abiertos, pero en la misma tarea práctica Claude Opus 4.8 entregó un resultado más rápido y preciso
- La prueba consistió en dar a ambos modelos el mismo prompt de una sola toma y pedirles construir desde cero un juego de plataformas 3D para navegador en raw WebGL, sin motor de juego ni bibliotecas de renderizado 3D como Three.js
- Ambos resultados y su código fuente están publicados
- Ambos juegos usan assets gratuitos CC0 de Kenney Platformer Kit
Naturaleza y enfoque de GLM-5.2
- GLM-5.2 es el modelo insignia más reciente de Z.ai y se ofrece como pesos abiertos con licencia MIT
- Se puede descargar y ejecutar directamente o invocar mediante la API de Z.ai
- Los pesos están publicados en Hugging Face y ModelScope, sin restricciones regionales
- Puede servirse localmente con frameworks como vLLM, SGLang y Transformers
- El modelo apunta a tareas de largo horizonte, como trabajos de agentes de programación de varias etapas durante periodos prolongados
- Ofrece una ventana de contexto de 1M de tokens
- Tiene niveles de razonamiento High y Max; en la prueba se usó High
- La limitación decisiva es que es solo de texto
- GLM-5.2 no puede leer imágenes
- Los flujos de trabajo que requieren revisar directamente capturas de pantalla o diagramas necesitan un modelo multimodal como Claude Opus
Precio y costo de ejecución
- Según la documentación de los proveedores, el precio por 1M de tokens de GLM-5.2 es menor que el de Opus
- Claude Opus 4.8: entrada $5, lectura de caché $0.50, salida $25
- GLM-5.2: entrada $1.4, lectura de caché $0.26, salida $4.4
- En tokens de salida, GLM-5.2 cuesta menos de una quinta parte que Opus
- En la prueba real de creación del juego, tiempo y costo se movieron en direcciones opuestas
| Métrica | GLM-5.2 (Pi/OpenRouter) | Opus (Claude Code) |
|---|---|---|
| Tiempo total de compilación | 1 hora 10 min 40 s | 33 min 30 s |
| Tokens de salida | 131,000 | 216,809 |
| Uso máximo de contexto | 16% de 1M | 19% de 1M |
| Llamadas a herramientas | 128 | 153 |
| Costo | $5.39 cobrados realmente | aprox. $21.92 estimados |
- Opus terminó en cerca de la mitad del tiempo, mientras que GLM-5.2 completó el trabajo con un costo mucho menor
La prueba: un juego de plataformas 3D en raw WebGL
- La tarea tenía una estructura más compleja que una simple landing page
- Parser de modelos GLB
- Matemáticas de matrices y vectores
- Shaders GLSL
- Animación esquelética con skinning
- Bucle de timestep fijo
- Manejo de colisiones
- Cámara de seguimiento
- Ambos modelos recibieron el mismo prompt, los mismos assets y un solo intento sin pistas
- Las condiciones de finalización eran las siguientes
- Motor 3D y renderer basados en raw WebGL
- Cargador para el personaje 3D y los modelos del mundo proporcionados
- Movimiento y salto del personaje con gravedad y colisiones
- Cámara de seguimiento y controles de teclado
- Juego completo ejecutable en el navegador con un solo comando
- Ambos modelos implementaron en gran medida por cuenta propia un parser binario de GLB, matemáticas de matrices y cuaterniones, un renderer WebGL2, shaders GLSL para skinning y colisiones AABB con substeps
- También están publicados los registros de compilación
Resultado al jugar y bugs restantes
- Ambos juegos tienen forma de juego de plataformas 3D en tercera persona
- Movimiento con WASD o flechas
Spacepara saltarShiftpara correr- Arrastrar el mouse para rotar la cámara
- Rueda para hacer zoom
- Objetivo de recoger monedas, evitar pinchos y llegar a la bandera
- Si se cae fuera del mapa, vuelve al punto de inicio
-
Resultado de GLM-5.2
- El juego de GLM-5.2 mostró en general un acabado tosco
- Faltaban algunos materiales del personaje y había un problema donde el personaje caminaba girado en dirección opuesta a su movimiento
- Las trampas de pinchos no mataban ni reiniciaban al personaje, y al llegar a la bandera no se activaba la condición de victoria
- La cabeza desaparecía cuando la cámara se movía y además quedaba visible una superposición de depuración
- La parte donde el personaje rebota hasta la siguiente plataforma al pisar un resorte sí funcionaba bien
- Los modelos de Kenney hacen referencia a una paleta de colores compartida en un archivo separado, pero el renderer de GLM-5.2 no cargó ese archivo, así que fue reemplazada por colores planos
-
Resultado de Opus
- El juego de Opus fue más limpio y funcionó mejor
- La cámara y el controlador funcionaban, y también la lógica donde los pinchos matan al jugador
- Las texturas se aplicaban correctamente, la animación era fluida y al llegar a la bandera sí se podía ganar
- Los bugs restantes se parecían más a casos borde que a fallas de funcionalidad básica
- El personaje podía quedarse un momento en el aire junto al borde de una plataforma, resultado de un tiempo de gracia de coyote-time demasiado amplio que permitía saltar incluso justo después de salir del borde
- La condición de victoria se activaba incluso estando todavía bastante lejos de la bandera
La diferencia multimodal en la autoevaluación
- A ambos modelos se les indicó verificar el resultado antes de terminar la tarea
- Opus, al ser multimodal, renderizó el juego y luego inspeccionó directamente las capturas de pantalla
- Detectó los indicadores de depuración que aún quedaban en pantalla, los eliminó y luego cerró el trabajo
- En la escena final verificó bloques, escaleras, monedas, gemas, pinchos, bandera, personaje, HUD de puntaje, iluminación y geometría
- GLM-5.2 no pudo ver directamente las capturas porque no puede leer imágenes
- En su lugar usó una vía indirecta: leer datos de píxeles en bruto y comprobar si los colores coincidían aproximadamente con lo esperado
- En la imagen guardada revisó condiciones de color como grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit, no black
- Ese método dejó pasar problemas reales de la pantalla
- El personaje se veía gris y faltaban texturas
- La superposición de depuración seguía presente en pantalla
- En tareas donde el resultado visual importa, la verificación multimodal capaz de entender imágenes se traduce en una diferencia real de calidad
Posición vista en benchmarks
- En los benchmarks de la model card de Z.ai, GLM-5.2 quedó en muchos casos justo detrás de los mejores modelos cerrados, e incluso los superó en algunos benchmarks de razonamiento
- Las cifras principales fueron las siguientes
- 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
- La ejecución independiente de ArtificialAnalysis también evalúa a GLM-5.2 como un fuerte modelo de pesos abiertos
- Puntaje de 51 en el Intelligence Index v4.1
- Por encima de MiniMax-M3 44, DeepSeek V4 Pro 44 y Kimi K2.6 43
- TerminalBench v2.1 marca 78%, usando un harness distinto al 81 o 82.7 de la model card
- Los tokens de salida por tarea rondan los 43k, más que los 26k de GLM-5.1
- La tendencia de los benchmarks se parece a la de la prueba práctica
- GLM-5.2 está entre los líderes de pesos abiertos y conserva cierta competitividad en razonamiento
- Opus va por delante en muchos benchmarks de programación y agentes
Reacciones externas
- Simon Willison calificó a GLM-5.2 como “probablemente el LLM de pesos abiertos solo de texto más potente”
- En su prueba de SVG, GLM-5.2 generó un pelícano en bicicleta completamente animado y sin partes rotas
- La prueba del zarigüeya en scooter salió peor que con GLM-5.1, así que el rendimiento no fue uniforme
- Artificial Analysis evaluó a GLM-5.2 como el modelo de pesos abiertos líder en su propio Intelligence Index
- Considera que, en ese nivel, es el modelo más barato y lo ubica en la frontera de inteligencia por costo
- Aun así, lo marca como un modelo que consume muchos tokens, con unos 43k de salida por tarea
- Nathan Lambert señaló que, según la tabla de LMArena, GLM-5.2 incluso podría verse como un mejor agente que Gemini, y que como modelo abierto con licencia MIT es un “serious accomplishment”
- Destacó que los mejores modelos de EE. UU. siguen por delante en general, pero subrayó que los laboratorios chinos están alcanzando puntajes altos con menos cómputo
Qué modelo elegir
- GLM-5.2 es un modelo de pesos abiertos con rendimiento fuerte por una fracción del precio de Opus
- Es adecuado cuando importan el costo y la apertura, y el trabajo se centra sobre todo en texto y lógica
- Los pesos descargables no pueden retirarse ni restringirse de repente como ocurre con los modelos cerrados
- Opus fue más rápido, más limpio y más preciso en la prueba
- Puede ver y verificar directamente resultados visuales
- Es más adecuado para trabajos donde importan la precisión, el pulido y el juicio visual, y donde se puede asumir el costo
- GLM-5.2 se parece menos a un reemplazo principal de Opus y más a un potente modelo complementario, barato y siempre accesible
1 comentarios
Comentarios de Hacker News
De verdad no entiendo por qué hay tanto alboroto con el prompting de un solo disparo
Por definición, un solo prompt no puede contener la complejidad de un proyecto de software. Al final, el modelo solo entrega un resultado haciendo varias suposiciones a partir del código existente en su corpus de entrenamiento
Más bien me gustaría ver un agente de codificación que siga con precisión las etapas de un archivo de planificación, respetando las barreras definidas por humanos en especificaciones revisadas y las convenciones de código. También habría que verificar si, para una meta definida por humanos, el bucle del agente no se sale de esas barreras y se mantiene firme hasta completar el objetivo
Además, una métrica mucho más valiosa es su capacidad para entender el contexto del caso de uso que se quiere construir, encontrar bugs o posibles mejoras de rendimiento en el código existente y proponer refactorizaciones
Más que un benchmark para ver si la salida coincide con la entrada, se parece más a ver si el resultado es internamente consistente. En un juego, por ejemplo, si termina al llegar a la meta, si mueres al tocar pinchos o si al moverte aparecen casos límite raros
Aun así, creo que debieron haber usado el mismo entorno de ejecución y repetir el experimento varias veces para ver también la dispersión de resultados
Antes me burlaba de los ingenieros que probaban un framework desde un proyecto vacío siguiendo el README y luego decían “este framework es lo máximo para nuestra app de producción de 10 años”. La mentalidad greenfield es la solución para todos los problemas y el problema de todas las soluciones
La capacidad one-shot también es una métrica autorreferencial importante, así que hay que medirla, pero debería hacerse sobre una base de código grande ya establecida
La razón por la que Claude Code y Opus llamaron tanto la atención es que el entorno de ejecución mejoró y ahora pueden corregir por sí mismos muchos errores sin intervención del usuario. A largo plazo, creo que las mayores mejoras vendrán de la autonomía de varias horas y la capacidad de autocorrección
No creo que generar millones de tokens a partir de unas cuantas fichas de entrada transmita gran cosa
Para evaluar un mejor modelo, basta con agregar más requisitos a la tarea. Aunque no sea un caso de uso realista, me parece un método útil
Claro, si un ingeniero de software lo pilotea, el modelo puede producir resultados mucho mejores. Aunque dependiendo del ingeniero, también podrían ser peores
Una ejecución única de one-shot del tipo “lo enfrenté cara a cara con el mismo prompt one-shot contra Claude Opus 4.8: crear desde cero un juego de plataformas 3D en WebGL puro” no es un benchmark ni representa un uso realista
La mayoría del uso de agentes es colaborativo, así que habría que probar cosas como la confiabilidad al delegarle una tarea, por ejemplo si la completa sin inventarse resultados de pruebas, y también qué tan controlable es, es decir, si sigue mis instrucciones o hace lo que se le ocurre
Esta prueba muestra qué pueden hacer ambos modelos cuando se les da una tarea one-shot larga y técnicamente difícil
Creo que valdría mucho la pena probar en el futuro un formato centrado en colaboración, delegación de tareas, finalización, desarrollo guiado por pruebas y controlabilidad
Pensándolo bien, la mayoría del trabajo con agentes que hago son subagentes que se ejecutan con sus propios prompts desde la sesión principal. Eso también puede verse como una versión corta de trabajo totalmente autónomo
El artículo también hablaba de eso, y esto en sí no estaba pensado como un benchmark formal. Benchmarks formales ya hay bastantes
Como Anthropic no dejaba de arrojar 529 Overloaded, ayer me registré en GLM 5.2 para probarlo
Me gustó, pero una sola sesión con 2 prompts en xhigh de GLM 5.2 se comió el 22% del uso del plan light en una ventana de reinicio de 5 horas
El resultado me dejó satisfecho y la calidad también estuvo bien. Como quiero usar ambos, estaría bueno que hubiera un plan de suscripción unificado que permitiera usar Anthropic y GLM juntos
La impresión que me dejó GLM 5.2 tras usarlo en algunos proyectos es que tarda bastante en empezar a escribir código y no es para nada un modelo rápido
Se desvía mucho durante la fase de exploración y planificación, aunque luego se corrige, y no es fácil de pilotear. Alucina cosas que después ni siquiera va a seguir. Aun así, la calidad de salida es bastante buena
Por ejemplo, estaba optimizando el renderizado en una base de código Swift+Zig y me atasqué en 5 mil elementos de datos. GLM 5.2 pasó 20 minutos creando un benchmark y extrayendo datos, y como me desesperé, le bloqueé el acceso a herramientas fuera del editor y me fui. Cuando volví unos 30 minutos después, ya había optimizado 3 cuellos de botella basándose en el benchmark que había creado y en algunas “conclusiones”, y también dijo que necesitaba más datos porque no podía verificar sus sospechas
La implementación funcionaba bien y era idiomática y no intrusiva. Incluso diría que fue más idiomática que lo que produjo GPT 5.5 en el mismo repositorio. Me gustaría usarlo más, pero GPT normalmente completa la misma solicitud 5 veces más rápido
Gracias a GLM 5.2 terminé preparando una configuración para ejecutar varios en paralelo dentro de contenedores aislados y workspaces de JJ
Era un problema para interceptar el clic izquierdo en la barra de menús de macOS y hacer que Ctrl+clic o clic derecho abrieran el menú como si fueran clic izquierdo, pero solo de manera condicional
A mitad de la sesión de resolución del problema cambié el modelo a GLM-5.2; ni siquiera volví a meter el prompt, lo cambié a media inferencia, y unos minutos después el problema quedó arreglado. Lo usé dentro de la asignación por suscripción de OpenCode Go, y un problema así podía haberse comido toda la cuota de uso de Opus de la ventana actual de 5 horas o incluso el límite semanal
Puedes detenerlo y corregirlo cuando ves que el modelo se está saliendo de rumbo o descubre algo que no te dijo. O también puedes aprender por qué tomó esas decisiones, así que luego te quedan menos dudas
Coincide bastante con mi experiencia. Lo estoy usando en Pi y es inteligente, además de que la salida es buena, pero el proceso para llegar ahí no es eficiente
Dice: “GLM-5.2 no puede leer imágenes, así que ahí surgió el problema. No es multimodal. Entonces, en vez de ver la captura de pantalla, usé el truco de escribir un script que leyera los datos brutos de píxeles y verificara si los colores salían más o menos como se esperaba”, pero un mejor método sería usar https://github.com/openbmb/MiniCPM-V
Si de verdad quieres, incluso podrías hacer que llame a Opus para las imágenes, y aun así probablemente ahorrarías costos
Me suscribí a Ollama para experimentar con modelos open source
Durante los últimos 3 meses solo he estado en modo de probar y experimentar, pero GLM es el primer modelo que uso a diario junto con Claude para trabajo real de programación. Me ha gustado bastante, al punto de agotar todos los días mi límite de uso de Ollama
GLM consume menos tokens y también hace menos llamadas a herramientas, pero tarda más del doble en completar
Si ese tiempo no se va en el comportamiento del modelo en sí, me pregunto entonces en qué se está yendo
¿Será que cada llamada de herramienta es más compleja y por eso tarda más, o que el modelo hace más cómputo por token y por eso tiene menos tokens por segundo?
Además, algunos modelos de pesos abiertos como GLM 5.2 o DeepSeek v4 Pro generan tokens bastante más lento, lo que afecta la latencia percibida. Aun así, es difícil llamar lento a GLM 5.2; por ejemplo, ahora mismo dentro de Notion es uno de los modelos más rápidos
Otra posibilidad es que Opus use algo como Mixture of Experts, así que la parte del modelo que se carga en memoria a la vez podría ser menor que en GLM
GLM 5.2 tiene un problema importante que limita su éxito de forma significativa: el valor de la suscripción para programación
Si solo miras el precio del API, GLM 5.2 le gana a la competencia. Pero usar cobro por API para trabajo de programación es algo más propio de grandes empresas, y para ellas los productos por suscripción fuertemente subsidiados están desapareciendo cada vez más
Al mismo tiempo, esas empresas no van a dejar que sus empleados usen APIs chinas
Para individuos y equipos pequeños, la suscripción de programación de Z.ai es peor que la de Anthropic y OpenAI. Tal vez puedas conseguir un nivel de uso parecido al de Claude, pero Codex claramente da mucho más uso por el dinero pagado
Se puede debatir cuánto se ha acercado Z.ai a GPT5.5 y Opus 4.8, pero en un mundo donde todo cuesta lo mismo y se puede elegir libremente, no escogería GLM
Así que la pregunta importante es cuánto mejorarán los productos de Z.ai en GLM 5.3 o 6, y cuánto van a restringir OpenAI y Anthropic sus ofertas actuales en el futuro cercano
Para ese tipo de empresas, construir infraestructura alrededor de una IA que no te vayan a quitar de un día para otro tiene un valor inmediato. Otros países fuera de Europa son más sensibles al precio y tampoco tienen el mismo miedo a relacionarse con empresas chinas
Al mismo tiempo, si “esas empresas no van a dejar que sus empleados usen APIs chinas”, entonces me pregunto a quién apunta Amazon Bedrock al ofrecer GLM
Los particulares probablemente elegirán proveedores estadounidenses más baratos como DeepInfra. La entrada en caché de GLM cuesta $0.18 por millón de tokens y Opus $0.50. Fireworks AI también es una opción
Empleados y estudiantes que se acostumbran a programar usando miles de dólares en tokens con planes de 20 o 100 dólares van a empujar ese gasto dentro de las empresas
La aparición de un modelo chino competitivo no va a sustituir ese gasto empresarial, pero los modelos abiertos alojados en EE. UU. o la UE sí podrían hacerlo
La existencia de GLM 5.2 pone un techo al precio que OpenAI y Anthropic pueden cobrar por el acceso al API
Mi suposición es que la mayoría del trabajo se está haciendo en planes de programación
Aun así, fastidia que los planes sean demasiado restrictivos más allá de los límites de uso. Lo entiendo, pero es incómodo. En la práctica, solo Anthropic y quizá Google son realmente estrictos
Anthropic asustó a la gente con una política según la cual, si consideran que tu uso no cumple los términos del servicio, después podrían cobrarte a tarifa de API. Tal vez sea una preocupación infundada, pero da la impresión de que sí podrían hacerlo, y eso hace que prefiera evitarlo
Pero su infraestructura estaba claramente sobrecargada y el 100% de las solicitudes de chat a 5.2 terminaban en timeout. Cuando la infraestructura se ponga al nivel del rendimiento del modelo, lo volveré a intentar y recién ahí podré juzgar si la suscripción vale la pena
Hoy me sorprendió que GLM-5.2 fuera mucho mejor que GPT-5.5 en sentido estético y trabajo de UI
Por ahora voy a mantener mi configuración de Claude/Codex a través de Conductor, pero por este modelo terminé configurando OpenCode y descargando la app de escritorio para hacer ahí la mayor parte de mi trabajo de hoy
Cuando veo frases como “GLM-5.2 costó mucho menos. Opus terminó en la mitad del tiempo y entregó un juego más limpio”, enseguida se siente ese estilo de escritura de LLM
Parece que todos los modelos han convergido hacia ese estilo de redacción, y aunque mejoren en rendimiento, esa parte no cambia mucho
La industria de la redacción técnica está sufriendo un golpe fuerte en este momento. Las empresas exigen más trabajo en menos tiempo y la calidad ha bajado muchísimo, así que cada vez hay menos tiempo en el día a día para pulir la calidad de las frases
Nosotros estamos trabajando justo en la primera línea de este cambio, así que somos de los más afectados, pero al mismo tiempo resulta estimulante y muy frustrante poder experimentar antes que nadie con estos cambios