GLM 5.2: el reasoning effort es la palanca de coste

GLM 5.2 ya está en Synthorai a aproximadamente un sexto del precio por token de los modelos frontier, y el titular de pesos abiertos con benchmarks de nivel frontier es real. Pero el precio por token es el número equivocado para tomar como referencia. Lo que realmente cuesta una tarea de coding en GLM 5.2 varía en más de un orden de magnitud según un solo parámetro, el reasoning effort, y el valor por defecto deja ese parámetro en la peor posición. Si lo ajustas bien, GLM 5.2 acierta y es más barato que los modelos frontier tanto en tareas fáciles como difíciles. Si lo dejas por defecto, la misma respuesta cuesta veinte veces más y tarda minutos. Lo medimos.

Qué es GLM 5.2

GLM 5.2 es el modelo frontier de pesos abiertos de Zhipu, lanzado el 2026-06-13: una red mixture-of-experts (~744B en total, ~40B activos), un contexto utilizable de 1M tokens y una licencia MIT que puedes alojar tú mismo. Está orientado a coding y trabajo agéntico, con benchmarks publicados sólidos (SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). En Synthorai es glm-5.2, con un precio de 1,40 $ por millón de tokens de entrada y 4,40 $ por millón de salida.

El detalle que condiciona todo lo que viene a continuación: es un modelo de reasoning, y cuánto razona lo decides tú.

Dónde queda en precio

En precio de lista por token, GLM 5.2 se sitúa bastante por debajo del frontier occidental y entre los modelos chinos más baratos. Las tarifas de Synthorai para un conjunto representativo:

Su tarifa de salida de 4,40 $ es alrededor de un séptimo de la de gpt-5.5 y un sexto de la de claude-opus-4-8, aunque deepseek-v4-pro y kimi-k2.5 la dejan por debajo. Así que GLM 5.2 ofrece capacidad de nivel frontier a precios más bien de modelo chino, sin ser el más barato en absoluto. No hay un cargo separado por escritura en cache: una escritura se factura a la tarifa de entrada, y solo la lectura de cache se descuenta a la tarifa de arriba. El descuento varía según el proveedor: la lectura de cache de GLM 5.2 es aproximadamente un quinto de su tarifa de entrada, mientras que los modelos frontier (gpt-5.5, claude-opus-4-8, gemini-3.1-pro) descuentan las lecturas a alrededor de un décimo.

También supone un salto respecto a sus propios predecesores. La generación anterior de GLM era extraordinariamente barata; la línea GLM 5 subió los precios, y GLM 5.2 se queda en unas 3x la tarifa de entrada de GLM-4.6 (tarifas oficiales de Zhipu):

Eso te da el contexto de 1M y los benchmarks frontier. Pero la tarifa por token es solo el titular. Lo que pagas de verdad por tarea lo marca el reasoning effort.

El parámetro de reasoning effort

El reasoning de GLM 5.2 es un dial, no un interruptor. Puedes apagarlo (enable_thinking: false), poner reasoning_effort en low, medium o high, o dejarlo en el valor por defecto, que ejecuta el reasoning sin límite. Ese ajuste cambia el coste y la latencia mucho más de lo que lo hace el precio. Ejecutamos una tarea de coding fácil y una difícil con todos los ajustes, comprobando cada respuesta contra una referencia en cientos de casos aleatorizados.

Una tarea fácil: razonar solo suma coste

Weighted interval scheduling, un problema de programación dinámica de dificultad media:

Hay dos cosas que llaman la atención. Con thinking off la respuesta es correcta y resulta lo más barato de toda la tabla, unas 8 veces por debajo de los modelos frontera, y cada paso que subes el dial solo añade coste para llegar a la misma respuesta. Y la factura sigue al razonamiento, no a la respuesta: el código que devuelve GLM ronda los 150 tokens siempre, mientras que el razonamiento que lo precede crece desde nada hasta unos 6,300, facturado a la misma tarifa de $4.40/M de salida. El default sin límite gasta ese razonamiento para llegar a la misma respuesta que thinking off producía sin nada, y esa diferencia es toda la diferencia de coste. Los modelos frontera responden aquí con poco o ningún razonamiento reportado: gpt-5.5 gasta 59 tokens de razonamiento, y el uso de claude-opus-4-8 no reporta ninguno.

Una tarea difícil: el razonamiento se gana el sueldo, el modo por defecto no

Coincidencia de cadenas con comodines (? y *), el problema clásico que es fácil equivocar de forma sutil. Aquí, con el pensamiento desactivado, falló. Devolvió una recursión con memoización:

def is_match(s, p):
    memo = {}
    def match(i, j):
        if (i, j) in memo:
            return memo[(i, j)]
        if j == len(p):
            result = i == len(s)
        elif i < len(s) and p[j] in (s[i], '?'):
            result = match(i + 1, j + 1)
        elif p[j] == '*':
            result = match(i + 1, j) or match(i, j + 1)
        else:
            result = False
        memo[(i, j)] = result
        return result
    return match(0, 0)

Parece correcto, e incluso el memo sugiere cierto cuidado. Pero la rama del * hace match(i + 1, j) sin acotar i. Cuando la cadena ya se consumió y al patrón todavía le queda un *, i sube sin parar y la pila se desborda. Rápido, barato y mal.

Sube la palanca y devuelve el algoritmo iterativo correcto de dos punteros, que retrocede al último * en lugar de recurrir:

def is_match(s, p):
    s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
    while s_idx < len(s):
        if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
            s_idx += 1
            p_idx += 1
        elif p_idx < len(p) and p[p_idx] == '*':
            star_idx = p_idx
            match_idx = s_idx
            p_idx += 1
        elif star_idx != -1:
            p_idx = star_idx + 1
            match_idx += 1
            s_idx = match_idx
        else:
            return False
    while p_idx < len(p) and p[p_idx] == '*':
        p_idx += 1
    return p_idx == len(p)

La palanca completa en esta tarea:

Todos los niveles de effort explícitos la resolvieron. reasoning_effort: high lo logró por $0.0031 en 13 segundos: unas veinte veces más barato y treinta veces más rápido que el default sin límite para la misma respuesta, y además queda por debajo de los modelos de frontera en coste, apenas unos segundos más lento. Una rareza que conviene conocer: el low de GLM produjo más razonamiento que el high, de forma consistente en ambas tareas, así que los nombres no se corresponden con el número de tokens. Medium y high fueron las configuraciones baratas y rápidas.

El default sin límite es la única configuración que hay que evitar. Es lo peor de ambos mundos: compra razonamiento que la tarea quizá no necesite y tarda minutos en hacerlo, para llegar a la misma respuesta que dio reasoning_effort: high por veinte veces el coste.

La regla de decisión

La palanca es el reasoning effort, y la configuración correcta depende de la tarea, no del modelo:

• Trabajo simple o de alto volumen donde la corrección es fácil: pensamiento desactivado (enable_thinking: false). Correcto y unas 8 veces por debajo de la frontera.
• Problemas más difíciles donde el pensamiento desactivado falla: reasoning_effort: medium o high. Correcto, alrededor de $0.003 por tarea, por debajo de la frontera en coste y solo unos segundos más lento.
• Nunca el default sin límite. Dejar el razonamiento activado sin un tope de effort es justo lo que convierte una respuesta de $0.003 en una de $0.06 y siete minutos.

Si no puedes saber de antemano si una tarea necesita razonamiento, reasoning_effort: high es un default seguro: fue barato, resolvió ambas tareas y nunca se descontroló.

El caché ayuda con la entrada, no con el razonamiento

GLM 5.2 soporta caché en el gateway, y ayuda justo donde lo esperarías. Enviamos un prefijo compartido de 1.494 tokens (un módulo de código para revisar) junto con varias preguntas distintas:

Una vez que se ha visto un prefijo grande, queda en caché. Los tokens de entrada cacheados se facturan a aproximadamente una quinta parte de la tarifa normal de entrada, lo que redujo una petición por lo demás idéntica de $0.0026 a $0.0009, un 64% menos. Una repetición exacta se sirve directamente desde el caché semántico: la misma respuesta al mismo coste que la llamada cacheada, pero de vuelta en cerca de un segundo en lugar de cinco.

El truco es el mismo que ya nos enseñó el dial: el caché descuenta la entrada, y en cuanto el razonamiento está activo, el coste y la latencia viven en la salida del razonamiento, que no se cachea. Así que el caché es una ganancia real para el trabajo con thinking-off y mucho contexto (el mismo system prompt o codebase en cada llamada), y una pequeña ganancia una vez que el razonamiento está activo.

Cómo usarlo en Synthorai

glm-5.2 ya está disponible en el gateway. Tres notas prácticas de nuestras pruebas:

• Define el esfuerzo de razonamiento de forma explícita. Usa enable_thinking: false para tareas simples y reasoning_effort: medium o high para problemas más difíciles. Lo único que hay que evitar es dejar el razonamiento activo sin un límite de esfuerzo (el default sin límite), que es la trampa de los $0.06 y siete minutos.
• Usa streaming cuando el razonamiento esté activo. Las respuestas con razonamiento pueden tardar minutos, y una petición sin streaming se queda sobre una conexión silenciosa el tiempo suficiente como para que tu cliente probablemente haga timeout antes de que llegue la respuesta. Con stream: true obtienes salida incremental y el resultado completo.
• Reutiliza tu contexto. Si envías el mismo system prompt grande o el mismo codebase en cada llamada, el caché de prefijo reduce el coste de entrada, y combinarlo con thinking off abarata toda la petición.

El precio es de $1.40 / $4.40 por millón de tokens, y el gateway devuelve un campo cost por llamada para que veas exactamente cuánto costó cada petición.

En resumen

GLM 5.2 es un modelo de coding genuinamente barato y capaz, y bien configurado le gana a los precios de frontera tanto en trabajo fácil como difícil. El truco está en la configuración. Su razonamiento es un dial, y el default lo deja sin límite, que es como una tarea que debería costar $0.003 se convierte en una llamada de $0.06 y siete minutos. Pon enable_thinking: false para el trabajo simple y reasoning_effort: medium o high para el resto, y GLM 5.2 sale barato y correcto en todos los frentes. Déjalo con el razonamiento en su valor por defecto, y será la opción más lenta y más cara que podrías haber elegido.

Fuentes

• VentureBeat: Z.ai’s open-weight GLM-5.2 beats GPT-5.5 on long-horizon coding for 1/6 the cost
• eigent.ai: GLM-5.2 specs and overview
• CloudPrice: GLM-5.2 pricing and specs
• Z.ai: official GLM API pricing (GLM-4.5 / 4.6 / 5 generations)

(Los precios listados arriba para Synthorai son las tarifas de esta plataforma a fecha de 2026-06-24; las tarifas por generación de GLM son la lista oficial de Zhipu.)

Costes medidos en Synthorai el 2026-06-24 (glm-5.2 a $1.40 / $4.40 por M tokens); verifica el precio actual antes de basarte en él.

← Volver al blog