Probar GLM 5.2 dentro de Claude Code con un SDK real por cinco dólares.

Un proyecto de ley en Claude Code cuyo costo sigue aumentando es una buena razón para buscar un motor más económico. El candidato habitual es GLM 5.2, un modelo de código abierto de un laboratorio chino al que los artículos de análisis continúan elogiando. En lugar de leer más de esos artículos, un desarrollador invirtió cinco dólares en OpenRouter y aplicó el modelo a un código real: un SDK de interfaz de usuario generativa creado para React Native, verificando cada línea que devolvía. La auditoría costó 59 centavos y la compilación, cuatro dólares. Vale la pena examinar los detalles, incluido un error casi imperceptible respecto a qué código debería enviarse a un modelo alojado en la nube.

¿Por qué probarlo en absoluto?

Hubo dos motivos que impulsaron el experimento. El primero fue el costo. Un modelo cuyo precio era una décima parte del habitual y que podía manejar incluso la mitad de la carga de trabajo permitiría ahorrar dinero real, especialmente para alguien que ejecuta muchos agentes al mismo tiempo, a veces incluso una gran cantidad de ellos. El segundo motivo fue la curiosidad por los laboratorios chinos, que envían rápidamente y publican resultados de pruebas impresionantes, pero cuyos modelos nunca se habían probado con el propio código del desarrollador.

La regla para la prueba era sencilla: utilizar la base de código que el desarrollador conoce mejor que nadie y verificar cada afirmación en los resultados obtenidos.

La configuración es más breve de lo esperado

GLM 5.2 proviene de Z.ai. Apareció a mediados de junio, cuenta con una ventana de contexto de un millón de tokens y se describe ampliamente como un modelo de vanguardia para la programación a una fracción del precio. Las cifras públicas respaldan esta reputación. Design Arena de OpenRouter lo sitúa entre el 1 por ciento superior en tareas de programación, según 3,243 torneos cara a cara. Sin embargo, eso sigue siendo el estándar de otro competidor, y los estándares son, en realidad, el código de otras personas.

Claude Code no se preocupa por lo que hay detrás de él. Utiliza el formato de la API de Anthropic y lee dos variables de entorno para decidir a dónde dirigir las solicitudes. Si se apuntan a otro endpoint, la herramienta sigue funcionando igual, con el mismo agente, edición de archivos y pruebas, pero con un “cerebro” diferente a su espalda.

OpenRouter funcionó como punto de conexión. Una cuenta y una clave API pueden dirigirse a docenas de proveedores, incluido Z.ai, por lo que no había necesidad de establecer una relación de facturación separada con un laboratorio extranjero solo para realizar un experimento. Con unos pocos dólares de crédito se obtiene acceso a cualquier modelo mediante una sola clave. El proceso consta de tres pasos.

Crea la clave. Genera una clave API en OpenRouter y agrega unos pocos dólares de crédito. GLM 5.2 no cuenta con versión gratuita, aunque el crédito es suficiente: todo el experimento cabió dentro de cinco dólares, dejando incluso algo de margen. El campo de límite de crédito de la clave actúa como red de seguridad, y en este caso tenía un tope estricto de cinco dólares. Después del experimento, el panel de control mostró que se habían utilizado 4,59 dólares de ese límite, lo cual cubrió todo lo descrito a continuación.

Dirige el Point Claude hacia allí. Unos pocos ajustes son suficientes: la URL de base apunta a la API de OpenRouter, el token de autenticación es la clave de OpenRouter, y los nombres por defecto de los modelos Opus y Sonnet se establecen ambos en el identificador GLM 5.2.

ANTHROPIC_BASE_URL = https://openrouter.ai/api
ANTHROPIC_AUTH_TOKEN = your_openrouter_key
ANTHROPIC_DEFAULT_OPUS_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_SONNET_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_HAIKU_MODEL = z-ai/glm-4.5-air

Con eso en su lugar, al iniciar Claude Code se está comunicando con GLM. Para volver a usar Claude basta con eliminar esas líneas. Ese es todo el proceso de cambio.

Fijar el proveedor. La mayoría de las personas omite este paso, pero es importante. En OpenRouter, un mismo nombre de modelo puede ser ofrecido por una larga lista de empresas, y los precios varían mucho, desde menos de un dólar por millón de tokens hasta más de tres. Esta diferencia no es casualidad. Algunos hosts ejecutan copias cuantizadas del modelo, que son más pequeñas, más rápidas, pero notablemente menos inteligentes; por esa razón, la pestaña de Proveedores incluso incluye un filtro de cuantización. Si se deja en modo de enrutamiento automático, una solicitud podría llegar a uno de esos hosts, y el evaluador terminaría juzgando una versión comprimida y de mala calidad pensando que era la original.

Para una comparación justa, la ruta se configuró directamente en Z.ai, el proveedor oficial, con las opciones de respaldo desactivadas. Cada solicitud llegaba entonces al modelo de precisión total real y a nada más. Si el objetivo es la equidad, este ajuste determina el resultado.

El error casi imperceptible: no todo el código es compartible

El SDK es de código abierto, pero en el mismo repositorio se encuentra material que no lo es: un kit de integración dinámico, sistemas de facturación, lógica de usuarios y las funcionalidades destinadas a generar ingresos. Enviar todo el monorepo a un modelo alojado en otro país es ese tipo de fugas accidentales que solo se detectan posteriormente.

Antes de que cualquier cosa funcionara, se creó una copia limpia. Solo se incluyeron las partes visibles, es decir, el paquete SDK y una aplicación de ejemplo con su backend de agente, mientras que el código comercial permaneció en el disco del propio desarrollador. Luego vino la verificación sencilla pero importante: se buscó en esa copia las palabras que podrían delatar el juego, como “onboarding”, “billing”, “tenant” y “stripe”, y el resultado fue cero coincidencias antes de que saliera siquiera un único token de la máquina.

Esa costumbre es la verdadera lección: un modelo económico no cambia las reglas. El código público puede ir a una API alojada; el código privado permanece local o no se envía en absoluto. El mismo razonamiento llevó en su momento al desarrollador a elegir un modelo más caro pero seguro según las normas de la UE para el backend del cliente, y sigue siendo válido incluso cuando el experimento es solo por diversión.

Tarea uno: leer el SDK y señalar dónde falla

La primera tarea fue una prueba puramente de lectura. Se pidió a GLM que auditará la arquitectura como si se fuera a construir una nueva generación de herramientas sobre ella: identificar las uniones portantes, nombrar los archivos y indicar qué se rompería primero. Había una regla de suma importancia: cada afirmación debía hacer referencia a un archivo y línea reales, y las incertidumbres debían reconocerse en lugar de ocultarse con invenciones.

El modelo leyó cuarenta y un archivos y entregó un informe de auditoría que reveló tres problemas reales de los que el desarrollador ya era consciente:

• Los tipos de componentes se incluyen de forma fija en el paquete al iniciar la aplicación, por lo que un agente no puede definir un componente nuevo en tiempo de ejecución, algo que es precisamente lo que requiere la próxima función.
• La transmisión en flujo silencioso no tiene efecto alguno en la ruta del agente principal, ya que el adaptador responsable nunca recibió implementado un método de transmisión en flujo.

Se había ignorado un error de desviación: el SDK puede renderizar trece componentes, pero el servidor solo permite once y le indica al modelo que existen siete, lo que deja dos componentes perfectamente funcionales inaccesibles a través del agente.

Nada de eso se tomó a la ligera. Cada cita se verificó con grep contra el código, y todas resultaron correctas. Las rutas de los archivos y los números de línea eran precisos, y el modelo no había inventado ni una sola función. Incluso detectó algo que nadie más había señalado: un comentario en el backend que afirmaba orgullosamente que utilizaba los modelos más recientes de Claude, situado justo encima de código que en realidad llama a un modelo de OpenAI más económico. Un comentario obsoleto se había convertido en una pequeña mentira. Fue un descubrimiento sorprendente por parte de un modelo que el desarrollador estaba dispuesto a descartar.

La auditoría costó 59 centavos y duró seis minutos.

Tarea dos: cambiar el código

La lectura es el área donde cada modelo parece inteligente, por lo que el siguiente paso fue permitirle que interactuara con el código. Recibió la solución más difícil como resultado de su propia auditoría: poner fin de una vez por todas al desvío de los componentes. El SDK se convertiría en la única fuente de verdad; se generaría un manifiesto a partir de él, y el servidor leería ese manifiesto en lugar de una lista escrita a mano, de modo que los dos nunca volverían a divergir. Si eso ocurría, una prueba tendría que fallar.

El modelo completó todas las partes. Se generó un manifiesto desde el SDK, el servidor se configuró para consumirlo, los dos componentes aislados se convirtieron en componentes integrados adecuados y, por fin, se pudieron acceder a ellos, además de añadirse una prueba de control para detectar desviaciones. La ejecución del conjunto de pruebas por parte del propio desarrollador mostró noventa y dos pruebas superadas: las ochenta y siete originales sin cambios más cinco nuevas. Luego se realizó un intento deliberado de romperlo: se eliminó un componente del manifiesto manualmente y se volvió a ejecutar la prueba de control. Falló de manera evidente, en el lugar adecuado. La red de seguridad tenía efectividad real.

Durante el proceso, el modelo también se topó con una engorrosa trampa en la cadena de herramientas: un problema de sintaxis en React Native que impedía al ejecutor de pruebas cargar ciertos archivos. No ocultó el problema ni se rindió. Creó una solución temporal y registró el problema como una advertencia en su informe; una honestidad que vale más que un resultado aparentemente impecable.

La trampa

La fase de construcción costó cuatro dólares, frente a 59 centavos para la lectura, y esa diferencia es lo que los videos promocionales omiten. En cuanto a la lectura, GLM resultó ser una clara victoria: aproximadamente diez veces más barato que la configuración habitual y tres veces más rápido. En la fase de construcción también tuvo éxito, pero la mayor parte de los cuatro dólares se destinó a superar repetidamente las pruebas, en un ciclo de ejecutar, leer el error, editar y ejecutar de nuevo, repetido unas trescientas veces. Solo alrededor de treinta de esos pasos implicaron cambios reales en el código; el resto fue cuestión de resistencia.

Por lo tanto, la conclusión es más limitada que “el GLM reemplaza la configuración existente”. Para la lectura, revisión, auditoría y explicación de un código, tareas en las que el modelo piensa detenidamente una vez y devuelve una respuesta, el GLM 5.2 es realmente una buena opción que merece ser elegida intencionadamente. En proyectos largos sin supervisión, donde los costos aumentan debido a bucles de depuración, también funciona, pero los ahorros disminuyen y vuelve a ser necesario recurrir a un modelo de vanguardia.

Una tarde, cinco dólares y código familiar produjeron una respuesta definitiva donde un flujo constante de opiniones apresuradas nunca lo habría logrado, lo que lo convirtió en la investigación más económica del mes.

Uso rutinario

Existen dos enfoques posibles, dependiendo del código.

Para todo lo que es público, la configuración de OpenRouter se encuentra en un bloque comentado dentro de los ajustes de Claude Code. Si necesitas una segunda opinión económica sobre un repositorio de código abierto, una revisión de arquitectura o una pregunta del tipo “¿qué está mal aquí?”, elimina los signos de comentario, cambia el proveedor a Z.ai y deja que GLM realice la lectura detallada por un precio muy bajo. Claude sigue siendo la opción predeterminada cuando llega el momento de desarrollar.

Para todo lo que es privado, el modelo se integra en el código y no al revés. Eso significa que solo hay pesos locales o nada.

Leer más

• Reducir el gasto en tokens de RAG en un 67% con Qdrant Multivectors y aislamiento de oraciones — Un pipeline de RAG para descubrimiento legal que vuelve a ordenar los resultados con ColBERT dentro de Qdrant, isola la oración correspondiente y sacrifica algo de latencia a cambio de una reducción verificada del 67.1% en los tokens.
• Por qué el frontend es difícil después de React: estado, efectos, límites y herramientas de IA — React hizo que las interfaces de usuario fueran más fáciles de construir, no de diseñar. Donde realmente reside el trabajo en el frontend son el estado, los efectos complicados, los límites del sistema y el código generado por IA.