GLM-5.2: por qué probarlo antes que Kimi K2.7 o MiniMax M3

Z.ai (Zhipu) ha vuelto a soltar modelo, y esta vez el ruido no viene solo del laboratorio. Viene de la gente probándolo.

GLM-5.2 es su nuevo flagship para tareas largas de programación con agentes, y la frase que se repite estos días en foros y newsletters es peligrosa: “igual no necesito pagar tanto por el modelo cerrado de turno”. Esa frase es la que hace que un product manager se despierte sudando a las cuatro de la mañana.

No voy a venderte humo. La señal todavía es una mezcla de laboratorio, fe religiosa y facturas de tokens. Pero ya hay benchmarks independientes, pruebas reales en proyectos de verdad y quejas concretas. Suficiente para sentarse a mirarlo en serio.

Esto es lo que vamos a repasar:

1. Qué cambia respecto a GLM-5 y por qué el millón de tokens importa
2. Dónde lo puedes probar hoy y cuánto cuesta
3. Los benchmarks oficiales (con la ceja levantada que toca)
4. Los niveles de razonamiento y cuándo usar high o max
5. Qué dice la comunidad: Artificial Analysis, Willison, Latent Space, Hacker News, Reddit y más
6. Si puedes ejecutarlo en tu máquina y para qué sirve de verdad

🔑 GLM-5.2 es open-weights con licencia MIT. No hay lista de espera ni formulario de acceso. Te bajas los pesos de Hugging Face o lo consumes vía API desde el primer minuto.

Qué cambia respecto a GLM-5 ¶

Si vienes de fábrica, este modelo es la continuación directa de la apuesta de Z.ai por dejar atrás el “vibe coding” y abrazar lo que ellos llaman Agentic Engineering. Ya analicé esa jugada cuando salió el modelo anterior en el análisis de GLM-5, así que aquí no te repito qué es la arquitectura MoE ni de dónde viene el término. Si te suena a chino (nunca mejor dicho), pásate por ahí primero.

La novedad gorda de la versión 5.2 es el contexto de 1M de tokens estable. Y subrayo estable, porque ahí está la trampa de marketing que toda la comunidad está vigilando con lupa.

GLM-5.1, su antecesor inmediato, tenía fama de degradarse en contextos largos. Varios desarrolladores reportaron problemas a partir de 100K-200K tokens: loops, pérdida de rendimiento, el modelo olvidándose de lo que tú le habías dicho hace tres archivos. La gran pregunta no es “¿soporta un millón de tokens?”. Cualquiera pone esa cifra en una diapositiva. La pregunta es si ese millón aguanta un proyecto real o si es puro maquillaje.

La documentación oficial insiste en tres mejoras: contexto estable de 1M, mejor ejecución en tareas largas y más adherencia a estándares de producción. Suena bien. Lo veremos en la sección de opiniones, que es donde la cosa se pone interesante de verdad.

Acceso y precio: dónde lo puedes probar hoy ¶

GLM-5.2 está repartido por medio internet, aunque no todos los sitios te ofrecen el mismo contexto, ni el mismo precio, ni la misma velocidad.

La llamada a la API sigue el formato estándar que ya conoces si has tocado OpenAI o Anthropic. Nada de aprender un dialecto nuevo:

curl -X POST "https://api.z.ai/api/paas/v4/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer tu-api-key" \
-d '{
    "model": "glm-5.2",
    "messages": [
        {
            "role": "user",
            "content": "Refactoriza este servicio para que use inyeccion de dependencias"
        }
    ],
    "thinking": {
        "type": "enabled"
    },
    "reasoning_effort": "high",
    "max_tokens": 8192
}'

¿Y cuánto cuesta el chiste? El precio oficial de Z.ai es de los que te hacen mirar dos veces.

Ese mismo rango aparece replicado en OpenRouter, Fireworks, Cloudflare y DeepInfra, así que no es un precio gancho de un solo proveedor. Para que te hagas una idea de la distancia con los modelos cerrados de gama alta, esto es lo que coloca a GLM-5.2 en la conversación de “coste/calidad” donde antes solo competían Sonnet y los Flash de turno.

Si prefieres no tocar la API y lanzarlo desde tu agente, lo tienes integrado en flujos que ya he cubierto: el parque de modelos de Ollama Cloud y el tutorial de OpenCode, donde modelos como este conviven con Kimi y DeepSeek. Y si andas decidiendo qué modelo meter en tu stack diario, la comparativa de los mejores modelos para programar te da el mapa completo por perfil de developer.

👉 Vale, ya sabes dónde encontrarlo. Ahora la pregunta de verdad: ¿qué lleva dentro?

El millón de tokens y la arquitectura ¶

Aquí van los números que importan, y conviene tratarlos como un rango antes que como dato tallado en mármol, porque cada proveedor redondea a su manera.

Hugging Face lista GLM-5.2 con 753B parámetros en formato BF16/F32, mientras que Fireworks habla de 743B. Simon Willison, que se ha tomado la molestia de pesarlo, lo describe como un monstruo de 1,51 TB con unos 40B de parámetros activos por token. Esa es la magia del MoE: tienes un cerebro enorme, pero en cada paso solo enciendes la fracción que necesitas.

Z.ai presume de dos optimizaciones con nombre propio:

• IndexShare, que según el laboratorio reduce los FLOPs por token en contexto de 1M en un factor de 2,9×. Traducido: el millón de tokens no te cuesta lo que costaría a fuerza bruta.
• Una capa MTP que mejora la aceptación en speculative decoding hasta un 20%, lo que ayuda a la velocidad de generación.

Hay un detalle que te puede arruinar la fiesta según para qué lo quieras: GLM-5.2 es solo texto. Sin visión. Fireworks lo dice sin rodeos (image input no soportado) y la comunidad lo ha señalado como su talón de Aquiles para cualquier flujo frontend donde necesitas que el modelo mire una captura, un diseño o una pantalla rota.

⚠️ Si tu trabajo vive de pasarle screenshots al agente para que arregle la UI, GLM-5.2 no es tu modelo. No ve. Punto. Para eso sigues necesitando un modelo con visión.

Benchmarks oficiales ¶

La model card de Z.ai trae cifras de las que quitan el hipo. Aquí tienes las más relevantes para quien programa con agentes:

Antes de que saques la cartera: estos números vienen de la propia model card. Son benchmarks reportados por el proveedor, no una garantía mágica de que mañana te arregle el monolito de 2017 sin dejar cadáveres en utils.ts.

Fíjate además en el contraste entre Terminal Bench (81-82) y SWE-Marathon (13.0). El segundo mide tareas de programación de muy largo recorrido, y ese 13 te recuerda que “ejecución sostenida” sigue siendo terreno pantanoso para todos los modelos, no solo para este. La honestidad con los benchmarks empieza por leer también las columnas que no quedan bonitas.

En agregadores y rankings de tipo arena (FrontierSWE, Design Arena, Code Arena Frontend) también aparece arriba, pero ahí la señal es más difusa: sirve para detectar hype, no para decidir tu arquitectura.

Niveles de razonamiento: cuándo usar high y cuándo max ¶

GLM-5.2 tiene niveles de esfuerzo de razonamiento, y aquí hay una decisión práctica que mucha gente se está saltando. En la integración con Claude Code, Z.ai mapea low, medium y high hacia esfuerzo alto, y xhigh, max o ultracode hacia esfuerzo máximo. Para tareas complejas recomiendan max.

El problema es que max razona como si le pagaran por palabra.

En Hacker News, un usuario lo probó con una tarea más bien pequeña: una librería de evaluación matemática en Nim. ¿El resultado? GLM-5.2 en xhigh/max tardó más de 15 minutos razonando y gastó unos 45.000 tokens antes de escribir el primer archivo. No el proyecto entero. El primer archivo.

La lectura que sale del propio hilo es clara y te la robo sin pudor:

💡 Max no debería ser tu modo por defecto. Usa high para el día a día y reserva max para las tareas que de verdad lo pidan. El modelo razona bien, pero a veces razona de más, y eso te lo cobran en tiempo y en tokens.

Esto conecta con un patrón que vas a ver repetido en la siguiente sección: GLM-5.2 es barato por token, sí, pero no es comedido con los tokens. Es el típico invitado que trae el pan, pero se zampa media nevera.

Qué dice la comunidad técnica ¶

Aquí está el cambio de tono que hace este modelo distinto. GLM-5.1 generaba interés. GLM-5.2 está generando pruebas reales y comparaciones directas con Opus. Te traigo las voces que más me han hecho parar a leer.

Artificial Analysis: legitimidad con su propio benchmark ¶

La novedad más fuerte es AA-Briefcase, un benchmark nuevo de Artificial Analysis para trabajo agéntico de conocimiento: proyectos largos, miles de archivos de entrada, emails, Slack, documentos, modelos financieros y entregables profesionales. Ahí GLM-5.2 Max aparece por detrás de Claude Fable 5 y Claude Opus 4.8, pero por delante de GPT-5.5 xhigh, y lo presentan como el líder claro entre los open-weights.

Lo jugoso no es solo la posición. Artificial Analysis calcula que GLM-5.2 queda a unos 90 Elo de Opus 4.8, pero por menos del 25% del coste. Y que tarda alrededor de 19 minutos por tarea, frente a los ~24 de Opus 4.8 Max. No es el más fino del baile, pero empieza a ser peligrosamente competitivo justo donde duele: tareas largas con herramientas.

Simon Willison: el text-only más potente ahora mismo ¶

Willison publicó una pieza diciendo que GLM-5.2 es probablemente el modelo open-weights solo texto más potente disponible hoy. Confirma los 753B parámetros, el 1,51 TB, los ~40B activos por token y el detalle de que no tiene visión.

Pero también recoge la crítica que más se va a repetir: GLM-5.2 es token-hungry. Según esa lectura, consume unos 43.000 tokens de salida por tarea en el Intelligence Index, más que GLM-5.1, MiniMax-M3, Kimi K2.6 y DeepSeek V4 Pro Max. Barato por token, sí. Comedido, ni de lejos.

Latent Space: “esto ya huele a frontier” ¶

La gente de Latent Space / AINews fue contundente: dicen que GLM-5.2 ha pasado el “vibe check” de varios usuarios avanzados y que empieza a sentirse como un modelo frontier que casualmente es abierto. Recogen que Jeremy Howard lo elogió para su uso personal y que otros ya lo usan como daily driver. La pega de siempre: la falta de visión.

Es síntesis de comunidad, no ciencia. Pero el cambio de tono es real.

DEV Community: una prueba que separa al code monkey del útil ¶

Hay una prueba en DEV Community usando GLM-5.2 con OpenCode que vale su peso en oro porque no se queda en el “wow”. El autor le pidió implementar búsqueda en una página de blog con query params y debounce. Y el modelo no se limitó a escupir código:

• Entendió que la página era un server component con ISR y mantuvo el fetch en el servidor.
• Propuso un componente cliente aparte para filtrar, en lugar de romper la arquitectura.
• Evitó meter llamadas innecesarias en cada pulsación de tecla.
• Detectó que useSearchParams exige envolver en Suspense en Next.js.

Eso último es lo que marca la diferencia. No solo implementa: evita las trampas del framework. No lo hace infalible, pero ya no estamos en el terreno del “me montó un TODO app”.

Reddit: “lo siento on par con Opus 4.8” ¶

En r/ClaudeAI, un usuario contó que usando GLM-5.2 con Claude Code y pensamiento en max le parecía “on par” con Opus 4.8 en tareas de backend, pagos, debugging, Laravel y React. Él mismo avisa de que es anecdótico y sin benchmarks formales. Pero matiza algo interesante: la diferencia frente a DeepSeek no está en la implementación mecánica, sino en la planificación y las decisiones coherentes de arquitectura.

Y vuelve a salir la misma piedra en el zapato: para flujos frontend con screenshots y revisión visual de UI, varios usuarios echan en falta la visión que sí tiene Claude.

OpenCode: entusiasmo con asterisco de latencia ¶

OpenCode anunció que GLM-5.2 ya estaba disponible en su capa Go con 1M de contexto y el mismo pricing que la 5.1. Poco después avisaron de que estaba recibiendo 3× la demanda y que trabajaban en los problemas derivados.

En r/opencodeCLI la cosa se partió en dos. Un usuario decía que le funcionaba muy bien en frontend, debugging y repos grandes, comparable a Opus 4.8. Otro respondió que la velocidad de inferencia y el TTFT (time to first token) le parecían horribles y que no lo usaría hasta que mejorase. Moraleja: el modelo puede encantarte, pero el proveedor y el routing importan muchísimo.

Zyte: bueno, barato, lento y verboso ¶

El post de Zyte es, para mí, el más honesto de todos, porque lo prueba en trabajo real de scraping: spiders, extracción JSON, selectores, tool calling y planificación.

Su veredicto en una frase: bueno, barato, lento y verboso.

En ejecución cotidiana llegó a paridad con Sonnet en varias tareas, con spiders idiomáticos y JSON correcto. En planificación salió bastante más barato que Opus. Pero encontró dos pegas que conviene grabarse:

1. Verborrea de campeonato. En una tarea, GLM-5.2 usó 1.144 tokens para escribir un spider que Sonnet resolvió en 357. Y respondió “PONG” gastando 69 tokens. Sesenta y nueve tokens para decir PONG.
2. Conocimiento de APIs recientes flojo. En una integración concreta de la API de Zyte dejó la configuración incompleta, peor que Sonnet.

El consejo del autor es de los que te ahorran disgustos: úsalo dentro de un loop con herramientas que puedan consultar documentación actual, no confíes en su memoria de APIs.

🛡️ Si el modelo no tiene acceso a docs actualizadas, asume que su conocimiento de librerías recientes puede estar desfasado. Dale herramientas para leer la documentación de verdad y revisa lo que toca APIs nuevas.

Y el detalle técnico que lo explica todo: el mismo autor vio que GLM-5.2 desde la infraestructura de Z.ai iba a 3-5 tokens/s, mientras que desde otro proveedor llegaba a casi 30 tokens/s. La conclusión no es “GLM es lento”, sino “GLM depende mucho de dónde lo enrutes”.

Local: ¿puedes ejecutarlo en tu máquina? ¶

La respuesta corta: sí sobre el papel, casi no en la práctica.

Ya hay soporte GGUF vía Unsloth y llama.cpp. Se anunció una versión de 2 bits que reduce el modelo de 1,51 TB a 238 GB, conservando supuestamente alrededor del 82% de precisión. La página de Unsloth en Hugging Face muestra instrucciones para unsloth/GLM-5.2-GGUF con llama.cpp, Ollama, LM Studio, vLLM y compañía.

Antes de que sueñes con un Opus en zapatillas dentro del MacBook, dos avisos de la propia comunidad:

• Ese 82% sería respecto a Q8_0 en llama.cpp, no necesariamente contra BF16. La cifra de marketing y la realidad de calidad pueden no coincidir.
• 238 GB siguen siendo 238 GB. “Local” aquí significa “local en una sala con máquinas serias”, no “en mi portátil mientras Chrome se come la mitad del planeta”.

Para uso self-hosted serio, la model card menciona compatibilidad con SGLang, vLLM, Transformers, KTransformers y despliegues tipo Docker. Pero seamos sinceros: con este tamaño, el self-hosting es cosa de equipos con presupuesto de GPU, no de tu rincón del salón.

GLM-5.2 frente a Kimi K2.7 y MiniMax M3 ¶

Aquí está el meollo del título, así que vamos al grano. Estos tres son los open-weights de coding agéntico que están en boca de todos ahora mismo, y los tres salieron en cuestión de dos semanas de junio de 2026. Te pongo los cerrados de Anthropic como referencia para que tengas el mapa completo.

Un par de notas para que la tabla no te engañe. MiniMax M3 arrancó con una promo de lanzamiento a la mitad ($0.30 / $1.20 en OpenRouter), así que mira el precio vigente antes de hacer cuentas. Y Kimi K2.7 Code se queda en 256K de contexto frente al millón de GLM-5.2 y MiniMax: suficiente para cargar buena parte de un repo real, pero no para las barbaridades de contexto que prometen los otros dos.

Por qué empezaría por GLM-5.2 ¶

La razón no es que sea “el mejor” en abstracto. Es que es el que más pruebas independientes tiene encima de la mesa.

Mientras escribo esto, los benchmarks de Kimi K2.7 Code son todos propios de Moonshot (Kimi Code Bench v2, MCP Atlas y compañía), sin scores independientes de SWE-bench todavía. Los de MiniMax M3 también son de cosecha propia, aunque al menos Artificial Analysis ya le ha pasado su Intelligence Index. GLM-5.2, en cambio, ya tiene el aval de AA-Briefcase situándolo por delante de GPT-5.5 xhigh, la pieza de Willison, las pruebas de Zyte en scraping y los reportes de Reddit poniéndolo “on par” con Opus en backend y debugging. No es lo mismo “el laboratorio dice que es buenísimo” que “media comunidad técnica lo ha estrujado en proyectos reales y sigue funcionando”.

🔑 No elijas por la tabla de benchmarks del fabricante. Elige por quién lo ha probado fuera del laboratorio. A día de hoy, GLM-5.2 es el que tiene la cartilla de validación externa más llena de los tres.

Cuándo me iría a Kimi K2.7 o MiniMax M3 ¶

Ahora la parte honesta, porque cada uno tiene su terreno donde le da un repaso a GLM-5.2:

• Si te duele la factura de tokens, Kimi K2.7 Code. Es el contraataque directo al gran defecto de GLM-5.2. Donde GLM se enrolla y gasta ~43k tokens de salida por tarea (según Willison), Kimi presume justo de lo contrario: alrededor de un 30% menos tokens de razonamiento que su predecesor. En agentes que dan miles de pasos, ese ahorro se multiplica. Y encima sale más barato por token.
• Si necesitas que el modelo vea, MiniMax M3 (o cualquier cerrado). GLM-5.2 es ciego. MiniMax M3 nace multimodal con imagen y vídeo, así que para flujos frontend guiados por capturas o revisión de UI, M3 hace lo que GLM-5.2 no puede ni intentar.
• Si quieres lo más barato con 1M de contexto, MiniMax M3. Es el más económico de la terna y aguanta el millón de tokens, aunque sea el más nuevo y el menos rodado en proyectos reales.

¿La síntesis sin rodeos? GLM-5.2 es el que yo metería primero en una prueba seria, porque es el que tiene más kilómetros validados por terceros. Pero si tu cuello de botella es el coste de tokens o la visión, Kimi y MiniMax no son premios de consolación: son la respuesta correcta a un problema distinto.

👉 Y al final, lo que decide no es ninguna tabla, sino tu repo. Por eso la última parada de este post es la más importante.

Para qué sirve de verdad ¶

Después de cribar todo lo anterior, GLM-5.2 pinta jugoso para cuatro escenarios concretos:

1. Repositorios grandes, donde el millón de tokens corta el baile absurdo de “lee este archivo, ahora este otro, ahora se te olvidó el primero”.
2. Spec-driven development, porque varias pruebas tempranas lo usan como runner de implementación a partir de especificaciones, y rinde.
3. Flujos agénticos en Claude Code, OpenCode o Cline, donde pesa más la ejecución sostenida que una respuesta de chat bonita.
4. Alternativa coste/calidad frente a los cerrados caros, siempre que la fiabilidad del proveedor acompañe.

Lo que yo no haría es meterlo como “modelo único para todo” sin pasarlo por tu propia prueba. Y la prueba no es “¿funciona?”. Es esta:

• Una feature multiarchivo.
• Un bug viejo y sucio.
• Una migración pequeña.
• Una tarea con tests que tengan que pasar al ejecutarlos.
• Una tarea larga con contexto de producto real.

Compáralo contra tu modelo habitual midiendo no solo si “funciona”, sino cuántas vueltas necesita, cuántos tests rompe y cuánta basura convincente deja por el camino. Glamour cero, utilidad mucha.

Lo que queda por demostrar ¶

GLM-5.2 ha dado el salto de “lanzamiento interesante” a “candidato serio para el stack de programación con agentes”. Junta cuatro cosas poco habituales a la vez: pesos abiertos, 1M de contexto, precio competitivo y disponibilidad rápida en proveedores grandes. Eso no se ve todos los meses.

Pero la ceja levantada toca mantenerla, porque sus límites están cada vez más claros:

• Consume muchos tokens de razonamiento, sobre todo en max.
• Puede ser lento, y depende como pocos del proveedor que elijas.
• No tiene visión, mala noticia para todo lo que sea UI guiada por capturas.
• Su conocimiento de APIs recientes puede estar desfasado si no le das acceso a documentación.
• “Local” no significa “doméstico”, salvo que tu portátil venga con montacargas.

Mi resumen mental, sin reírme por dentro: muy prometedor para programación agéntica real, no sustituto universal de Opus o Sonnet, pero el primer open-weights que merece una prueba seria en tus proyectos de verdad. Y eso, para un modelo abierto a este precio, ya es noticia.

Así que la pregunta no es si GLM-5.2 es bueno. Es esta otra: ¿cuánto estás pagando ahora mismo por algo que este modelo igual te resuelve por la cuarta parte? Ábrele un hueco en una tarea de mañana y compruébalo tú.

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter