Modo /chat en Z.ai: cómo funciona y cuándo usarlo (2026)

El modo /chat en Z.ai es una interfaz básica para conversaciones rápidas e interactivas con los modelos GLM-5 y GLM-5.2. Proporciona respuestas instantáneas sin la sobrecarga adicional de herramientas o planificación.

Spoiler: Chat es un completions ligero con soporte para historial, system prompt y streaming, ideal para RAG, chatbots y generación de texto, a diferencia del modo Agent con uso autónomo de herramientas. En junio de 2026, se lanzó GLM-5.2 con un contexto de 1M de tokens y un posicionamiento "coding-first" — los cambios clave se describen a continuación.

📚 Índice del artículo

• 🆕 GLM-5.2: ¿qué cambió en junio de 2026?
• 📌 ¿Qué sucede dentro del modo chat (pipeline de inferencia LLM)?
• 📌 Gestión del contexto y el historial
• 📌 Soporte para instrucciones del sistema
• 📌 Limitaciones del modo chat
• 📌 Ejemplos de casos de uso (chatbot, RAG, generación de texto)
• 📌 Comparación con ChatGPT y Claude Chat
• ❓ Preguntas frecuentes (FAQ)
• ✅ Conclusiones

Revisión detallada de la plataforma Z.ai (arquitectura, Chat vs Agent): aquí

🆕 GLM-5.2: ¿qué cambió en junio de 2026?

El 13 de junio de 2026, Z.ai lanzó GLM-5.2, una actualización "coding-first" con un contexto de 1M de tokens. Si leíste este artículo antes, esta sección contiene los cambios más actualizados.

El artículo describía originalmente GLM-5 (febrero de 2026). En cuatro meses, se lanzaron GLM-5.1 (marzo) y GLM-5.2 (13 de junio). Esto es lo que ha cambiado fundamentalmente:

📊 Benchmarks independientes de GLM-5.2

A diferencia de GLM-5, que se lanzó sin benchmarks publicados, para GLM-5.2 han aparecido resultados independientes:

• SWE-bench Pro: 62.1% — frente al 58.6% de GPT-5.5, 2º puesto entre los modelos de codificación en la tabla de clasificación de Code Arena (Artificial Analysis, junio de 2026)
• GPQA Diamond: 89.5% — razonamiento a nivel de posgrado (Requesty, junio de 2026)
• Intelligence Index: 51.1 — capacidad general (Artificial Analysis)
• Terminal-Bench: cerca de Claude Opus 4.8 según los resultados de la primera semana tras el lanzamiento

⚠️ Nota importante: los benchmarks independientes de GLM-5.2 aún son escasos — la empresa no publicó una tabla de resultados el día del lanzamiento. Interpreta las cifras de GLM-5.1 como un límite inferior verificado, y GLM-5.2 como una actualización con un aumento esperado, confirmado por las primeras pruebas independientes.

🛠️ Plan de Codificación GLM: una nueva forma de acceso

Con GLM-5.1, Z.ai lanzó una suscripción separada para herramientas de codificación — el Plan de Codificación GLM. GLM-5.2 está disponible a través de él desde el día del lanzamiento:

Agentes de codificación compatibles desde el primer día: Claude Code, Cline, Roo Code, Goose, OpenCode, Crush, OpenClaw, Kilo Code — a través de un endpoint de API compatible con OpenAI o Anthropic Messages. En esencia: un cambio de nivel de configuración sin modificaciones en el código.

⚠️ Limitación clave de GLM-5.2: solo texto

GLM-5.2 es un modelo exclusivamente de texto. No hay soporte para imágenes, audio, video ni capturas de pantalla de PDF. La multimodalidad permanece en un modelo cerrado separado, GLM-5V. Si tu flujo de trabajo incluye diagramas, capturas de pantalla o PDF, GLM-5.2 no es adecuado sin preprocesamiento adicional.

💡 Si leíste este artículo antes: dondequiera que diga "200K tokens" — para GLM-5.2, la cifra actualizada es 1M de tokens. Esto cambia la estrategia de gestión del contexto: la reducción manual del historial se vuelve crítica mucho menos a menudo.

🎯 ¿Qué sucede dentro del modo chat (pipeline de inferencia LLM)?

El modo Chat actúa como una interfaz ligera para obtener respuestas rápidas: el modelo funciona en modo de decodificación directa sin la sobrecarga de la lógica de agente u orquestación de herramientas.

Análisis detallado del pipeline de inferencia en modo chat (GLM-5 / GLM-5.2):

1. Preparación de datos de entrada: el cliente envía un array de mensajes (rol: system/user/assistant). El prompt del sistema (si existe) se convierte en el primer elemento. Todo el historial de la conversación se incluye en la solicitud sin reducción o resumen automático.
2. Tokenización y formación del contexto: el tokenizador convierte el texto en una secuencia de tokens (similar a BPE). El contexto se limita a 200 000 tokens en GLM-5 / 1 000 000 tokens en GLM-5.2 — si se excede, el cliente debe recortar el historial por sí mismo. El modelo recibe el contexto completo sin compresión previa.
3. Paso a través del modelo:
   • Capas MoE: 256 expertos (GLM-5: 744B parámetros), activación de los 8 principales (~40B parámetros activos por token, dispersión ~5.9%).
   • DeepSeek Sparse Attention (DSA): reemplaza la atención clásica, asigna dinámicamente la atención solo a los tokens relevantes, reduciendo la complejidad computacional de O(n²) a algo más cercano a lineal en secuencias largas. Crítico para el contexto de 1M de GLM-5.2.
4. Modo de pensamiento (si está habilitado): En GLM-5 — parámetro thinking: {"type": "enabled"}. En GLM-5.2 — dos niveles: Alto (tareas estándar) y Máximo (tareas complejas de varios pasos). El pensamiento intercalado genera reflexiones internas entre los tokens de decodificación, mejorando la calidad en consultas complejas, pero aumentando el número de tokens y la latencia en un 20-50%.
5. Generación: decodificación autorregresiva utilizando parámetros especificados (temperatura, top_p, max_tokens, etc.). Se admiten tanto la respuesta completa como el streaming (stream: true) — los tokens se envían al cliente a medida que se generan. GLM-5.2 admite una salida máxima de hasta 128K tokens (GLM-5 — significativamente menos).
6. Finalización: la respuesta se devuelve como un mensaje con role: "assistant". No hay continuación ni verificación automática — el proceso termina después de la generación.

Documentación oficial /chat/completions | Modo de pensamiento en modo chat

Diferencias del pipeline con el modo Agent

En el modo Agent, después de cada paso de decodificación, el modelo puede:

• Tomar una decisión sobre llamar a una herramienta (tool_calls)
• Ejecutar planificación y autocomprobación
• Iterar (planificar → ejecutar → observar → revisar)

En el modo chat, no existe tal ciclo — la respuesta se genera en una sola pasada (single forward pass + decode), sin un bucle externo ni orquestación.

Trade-offs técnicos

La simplicidad del pipeline garantiza:

• Latencia mínima en la primera respuesta (~0.5–2 segundos en consultas cortas)
• Bajo consumo de recursos en comparación con el modo Agent
• Comportamiento predecible sin llamadas inesperadas a herramientas

Al mismo tiempo, esto limita las capacidades: el modelo no puede corregir errores por sí mismo, verificar hechos a través de herramientas ni realizar tareas de varios pasos.

Conclusión: El pipeline de inferencia del modo chat es un proceso clásico de completions de una sola pasada con MoE + DSA y pensamiento intercalado opcional (dos niveles en GLM-5.2), optimizado para la velocidad y la simplicidad de los diálogos interactivos sin elementos de lógica de agente autónoma.

Gestión del contexto y el historial

El mecanismo de multi-turno en modo chat es una simple transmisión del historial completo en cada solicitud, sin gestión de estado integrada ni gestión automática de memoria en el servidor. Con GLM-5.2 y una ventana de 1M de tokens, el truncamiento manual es necesario con mucha menos frecuencia, pero no desaparece por completo.

Descripción detallada del trabajo con el contexto en modo chat (GLM-5 / GLM-5.2):

• Formación del contexto: el código del cliente (por ejemplo, a través de un SDK compatible con OpenAI) pasa una matriz de mensajes en la solicitud a /v4/chat/completions. El orden de los mensajes es importante: system (el primero, si existe), luego la alternancia user/assistant desde el inicio de la sesión. El modelo no guarda el estado entre solicitudes; cada solicitud es independiente y contiene todo el historial necesario.
• Procesamiento en el lado del modelo: el modelo recibe el contexto completo y lo pasa a través de capas MoE con DeepSeek Sparse Attention (DSA). DSA garantiza una calidad de atención estable incluso a la longitud máxima sin una degradación significativa en el escenario "needle-in-haystack". El contexto no se almacena en caché por el servidor en el modo chat básico (la entrada en caché está disponible por separado).
• Limitación de longitud:
  • GLM-5: 200.000 tokens; si se supera, la solicitud se rechaza (400 Bad Request o 413 Payload Too Large).
  • GLM-5.2: 1.000.000 de tokens; prácticamente un repositorio completo en una sola solicitud sin fragmentación.
  En ambos casos, el modelo no trunca el contexto automáticamente; esto es responsabilidad del cliente.
• Gestión del historial por el cliente: para sesiones que superan el límite, es necesario:
  • Eliminar los mensajes más antiguos al acercarse al límite.
  • Utilizar el resumen del historial anterior (pedir al modelo que comprima los N mensajes anteriores en 1-2 párrafos).
  • Aplicar el caché de contexto si la API lo admite: GLM-5 — caché de entrada $0.20/millón; GLM-5.2 — $0.26/millón.

Documentación oficial /chat/completions (mensajes y contexto) | Caché de contexto en la API de Z.ai

Consecuencias prácticas y compensaciones

Ventajas del enfoque:

• Transparencia total: el cliente sabe exactamente qué ve el modelo.
• Ausencia de truncamientos inesperados del historial por parte del servidor.
• Eficiencia de DSA en contextos largos sin pérdida de calidad.
• Con GLM-5.2: 1M de tokens: todo el repositorio, documentación extensa o una sesión larga sin truncamiento manual.

Desventajas:

• Aumento de los costos de tokens y la latencia con un historial largo (cada solicitud procesa repetidamente todo el contexto).
• Necesidad de gestión manual en el cliente, lo que complica la implementación para aplicaciones sencillas.
• Ausencia de gestión de estado automática (a diferencia de algunas plataformas de chat con caché de sesiones integrado).
• Con GLM-5.2 a 1M de tokens: mayor precio por token ($1.40/millón de entrada frente a $1.00 en GLM-5) y generación potencialmente más lenta con el contexto máximo.

En escenarios de producción para sesiones largas, se recomienda:

• Para GLM-5.2: si la sesión cabe en 1M, transmitir el historial completo, usar caché de contexto ($0.26/millón) para el contexto repetido.
• Para GLM-5 o si se supera el límite: comprimir el historial mediante una solicitud separada al modelo.
• Utilizar bases de datos vectoriales para RAG en lugar de contexto completo (más eficiente que cualquier límite).
• Pasar a modo Agente o endpoints especializados con caché para interacciones multi-turno complejas.

Conclusión: La gestión del contexto en modo chat de Z.ai se basa en la transmisión del historial completo en cada solicitud. GLM-5.2 con una ventana de 1M de tokens reduce significativamente la necesidad de truncamiento manual para la mayoría de las sesiones reales, pero no la elimina por completo, y aumenta el costo de los tokens y la latencia con el contexto máximo.

Soporte de instrucciones del sistema

La instrucción del sistema es el único elemento estable del contexto que no cambia al añadir nuevos mensajes, garantizando la coherencia del comportamiento del modelo durante la interacción multi-turno.

Implementación técnica en la API de Z.ai (compatible con OpenAI /v4/chat/completions):

• El system prompt se transmite como el primer elemento de la matriz de mensajes: {"role": "system", "content": "..."}.
• Se incluye en el contexto una vez al principio y permanece sin cambios para todos los mensajes posteriores en esta sesión (el cliente no debe reenviarlo en cada solicitud, a menos que quiera cambiar la instrucción).
• Si falta el system prompt, el modelo utiliza el comportamiento predeterminado (un asistente neutral y útil sin especialización).
• El system prompt se procesa como una parte normal del contexto: tokenización → paso por MoE + DSA → impacto en la atención y la decodificación. Su longitud se tiene en cuenta en el límite total (200K para GLM-5, 1M para GLM-5.2).
• El cambio del system prompt solo es posible con una nueva solicitud con una nueva matriz de mensajes (es decir, al reiniciar la sesión o al reemplazarla explícitamente).

Documentación oficial de mensajes y rol del sistema

Aspectos prácticos y ejemplos

El system prompt permite ajustar el modelo con precisión para una tarea específica. Escenarios de uso típicos:

• Restricciones de estilo: {"role": "system", "content": "Responde solo en español. Evita el lenguaje obsceno y la política."}
• Especialización de rol: {"role": "system", "content": "Eres un desarrollador backend senior con 15 años de experiencia. Analiza el código de forma crítica, señala posibles vulnerabilidades y propone optimizaciones."}
• Formato de las respuestas: {"role": "system", "content": "Responde de forma estructurada: 1. Resumen breve 2. Análisis paso a paso 3. Recomendaciones. Usa markdown."}
• Limitación de alucinaciones: {"role": "system", "content": "Si no estás seguro de un hecho, di 'no tengo suficientes datos' en lugar de inventar."}

Limitaciones y compensaciones

• El system prompt es fijo durante la sesión; para un cambio dinámico de comportamiento se requiere una nueva solicitud con un nuevo prompt.
• Un system prompt largo reduce el espacio disponible para el historial de conversación. Con GLM-5.2 (límite de 1M), esto es menos crítico que con GLM-5 (200K), pero el tamaño recomendado del prompt es de 200-500 tokens.
• El modelo puede "olvidar" o ignorar parte del prompt con un contexto muy largo (DSA ayuda, pero no elimina el problema por completo).
• No hay soporte para multi-system prompt o instrucciones condicionales integradas; todo se limita a una sola línea de contenido.

En las recomendaciones de producción: mantenga el system prompt conciso (200-500 tokens) para aprovechar al máximo el contexto para contenido útil. Para escenarios complejos con instrucciones dinámicas, utilice el modo Agente o varias sesiones separadas.

Conclusión: El soporte de instrucciones del sistema en modo chat de Z.ai es un mecanismo estable y predecible a través de role: "system", que se mantiene durante toda la sesión. La mecánica es la misma para GLM-5 y GLM-5.2; la diferencia es que con 1M de contexto, un prompt largo "consume" una parte relativamente menor del espacio disponible.

Limitaciones del modo chat

El modo chat implementa inferencia directa sin un bucle externo, por lo que excluye cualquier forma de ejecución autónoma de tareas, lo que lo diferencia del modo Agente.

Limitaciones técnicas y funcionales principales del modo chat (GLM-5 / GLM-5.2):

• Ausencia de llamada automática a herramientas (tool-calling): el modelo no puede decidir por sí mismo llamar a funciones o herramientas. Para usar herramientas, debe pasar explícitamente tools y procesar la respuesta por el cliente (bucle manual).
• Carácter de generación única: después de emitir la respuesta, el proceso finaliza. No hay un mecanismo de iteración integrado (planificar → ejecutar → observar → revisar). El modelo no analiza su propia respuesta, no verifica hechos ni corrige errores sin una nueva solicitud.
• Solo texto en GLM-5.2: GLM-5.2 acepta y genera exclusivamente texto. No hay soporte para imágenes, audio, video ni capturas de pantalla de PDF; la multimodalidad solo está disponible en un modelo cerrado separado, GLM-5V. Si el flujo de trabajo incluye diagramas o capturas de pantalla, se requiere un preprocesamiento separado.
• Ausencia de generación de artefactos finales: la respuesta se limita a texto o código en el campo content. No hay creación nativa de archivos (.docx, .pdf, .xlsx), sitios web u otros entregables; esto es prerrogativa del modo Agente.
• Acción limitada del modo de pensamiento (thinking mode): el pensamiento intercalado (High/Max en GLM-5.2) mejora la calidad en solicitudes complejas, pero no proporciona autonomía de agente. Los pensamientos permanecen internos. La latencia aumenta (añade un 20-50% de tokens y tiempo), pero el resultado sigue siendo una sola respuesta.
• Velocidad en contexto largo:
  • GLM-5 (200K): de 25-30 tokens/s en solicitudes cortas a 10-15 tokens/s en contexto máximo.
  • GLM-5.2 (1M): la sobrecarga computacional aumenta proporcionalmente; espere una menor velocidad con el contexto completo. El streaming suaviza la latencia del primer token, pero no resuelve el problema.
• Ausencia de gestión de estado integrada: la sesión no se guarda en el servidor; cada solicitud es independiente. El cliente debe transmitir todo el historial por sí mismo, lo que aumenta el consumo de tokens.
• Limitaciones de cuota de GLM Coding Plan: al usar GLM-5.2 a través de Coding Plan, se aplican límites semanales de prompts (Lite: ~400/semana, Pro: ~2000, Max: ~8000). Para cargas de producción con contextos largos, la cuota puede agotarse más rápido de lo esperado. Cuota Premium: ×2 hasta finales de septiembre de 2026 (fuera de horas pico 1×).

Consecuencias de las limitaciones en escenarios reales

Estas limitaciones se manifiestan en tareas que requieren:

• Verificación y corrección autónoma (corrección de errores con ejecución de código, imposible sin un ciclo manual).
• Ejecución multi-paso con herramientas (búsqueda → análisis → generación de informe; requiere procesamiento manual).
• Generación de productos finales (informe en .docx, tabla en .xlsx; solo descripción textual).
• Procesamiento de imágenes, PDF, audio; solo texto en GLM-5.2.

Para superar estas limitaciones:

• Modo Agente: para autonomía y entregables.
• Ciclo propio en el cliente (LangChain / LlamaIndex con tool-calling).
• GLM-5V o alternativa multimodal: para imágenes y PDF.
• Resumen o RAG: para ahorrar contexto en sesiones largas.

Conclusión de la sección: El modo chat de Z.ai está limitado a inferencia directa única sin mecanismos de autonomía, ejecución iterativa o generación de artefactos. GLM-5.2 elimina las limitaciones de contexto (1M), pero añade limitaciones de solo texto y cuotas de Coding Plan. Para tareas multimodales o ejecución autónoma, utilice el modo Agente o GLM-5V.

Ejemplos de casos de uso (chatbot, RAG, generación de texto)

El modo chat está optimizado para tareas con alta velocidad de respuesta y soporte de contexto, donde el

Comparación con ChatGPT y Claude Chat

El modo Chat de Z.ai ofrece capacidades competitivas en precio y contexto largo, pero es inferior en velocidad, multimodalidad y comprensión profunda de tareas ambiguas. Con GLM-5.2, la principal ventaja son los 1M de tokens para repositorios y documentos grandes a un precio de $1.40/millón de entrada.

Tabla comparativa de características clave (junio de 2026, modo de pensamiento activado donde esté disponible):

Análisis de las diferencias clave

Contexto y sesiones largas: GLM-5.2 lidera ahora — 1M de tokens frente a 200K en Claude y 128K–200K en ChatGPT (dependiendo del plan). Para RAG con documentos grandes, análisis de repositorios completos o sesiones de soporte prolongadas, GLM-5.2 tiene ahora el mayor contexto práctico entre las tres plataformas.

Velocidad y latencia: ChatGPT lidera gracias a una inferencia optimizada (25–40+ tokens/s). GLM-5.2 con 1M de contexto es más lento debido a la sobrecarga computacional de MoE + DSA a la máxima longitud. Si es crítico, un chat en tiempo real sin contextos grandes, ChatGPT gana.

Razonamiento y calidad: Claude Opus 4.6/4.8 mantiene la ventaja en tareas matizadas y ambiguas y en la conciencia situacional. GLM-5.2 es fuerte en razonamiento técnico y codificación: SWE-bench Pro 62.1% — superior a GPT-5.5 (58.6%), pero inferior a Claude Opus 4.8 (~66–70%). El modo de pensamiento Máximo en GLM-5.2 acerca la calidad para tareas complejas.

Multimodalidad: ChatGPT y Claude tienen soporte nativo para visión/audio. GLM-5.2 es solo de texto; para imágenes se necesita GLM-5V por separado u otro modelo. Esta es una limitación estricta para flujos de trabajo con capturas de pantalla de PDF, diagramas o audio.

Coste y disponibilidad: Z.ai sigue siendo la opción de API más barata: GLM-5.2 es 1.2–3.5 veces más barato que ChatGPT y 3.5–10 veces más barato que Claude en los mismos volúmenes. La licencia MIT permite el auto-alojamiento para un ahorro máximo. Para codificación a través del Plan de Codificación ($18/mes) — significativamente más barato que Claude Pro o la API de GPT-5 para agentes de codificación.

Entorno competitivo: En junio de 2026 aparecieron nuevos competidores en el segmento de bajo coste. DeepSeek V4 Pro ($0.44–$0.87/millón) compite agresivamente en precio, Gemini 3.5 Flash — en equilibrio precio/capacidades. GLM-5.2 destaca por su combinación: 1M de contexto + licencia MIT + SWE-bench competitivo — ninguno de los competidores directos tiene los tres juntos.

Conclusión: El modo Chat de Z.ai en la versión GLM-5.2 es la mejor opción para RAG de contexto largo y revisión de código a escala de repositorio a un precio inferior al de los competidores. Claude Chat — para máxima precisión de razonamiento y tareas multimodales. ChatGPT — para velocidad y visión/audio nativos. La elección depende de las prioridades: 1M de contexto + presupuesto → GLM-5.2; multimodalidad + velocidad → ChatGPT; calidad de razonamiento → Claude.

❓ Preguntas frecuentes (FAQ)

¿En qué se diferencia el chat del agente en Z.ai?

El modo Chat proporciona respuestas rápidas sin usar herramientas y sin planificación automática — inferencia directa para diálogos interactivos, generación de texto o código. El modo Agente soporta planificación autónoma, llamadas a herramientas, iteraciones multi-turno con autocorrección y generación de artefactos finales (.docx, .pdf, .xlsx, sitios web). El modo Agente convierte el modelo en un ejecutor de tareas, mientras que el modo Chat es una interfaz de chat clásica sin lógica de agente.

¿El modo Chat soporta el modo de pensamiento?

Sí. En GLM-5 — el parámetro thinking: {"type": "enabled"}. En GLM-5.2 — dos niveles: Alto (tareas estándar) y Máximo (complejas de varios pasos). El pensamiento intercalado genera reflexiones internas entre la decodificación de tokens, mejorando la calidad del razonamiento. La latencia y el consumo de tokens aumentan un 20–50%, pero el resultado sigue siendo una respuesta única — el modo no se convierte en un ciclo de agente.

¿Cuál es la longitud máxima de contexto en el modo chat?

GLM-5: 200 000 tokens (confirmado hasta 202 752 en pruebas HLE w/Tools). GLM-5.2: 1 000 000 tokens — prácticamente todo el repositorio sin fragmentación. En ambos casos, el cliente debe gestionar de forma independiente la matriz de mensajes. Superar el límite es un error de solicitud (400/413).

¿Cuál es la diferencia entre GLM-5 y GLM-5.2 para el modo chat?

Tres diferencias clave: (1) contexto de 200K → 1M de tokens — el mayor cambio práctico para RAG y grandes bases de código; (2) salida máxima ~8K → 128K tokens — GLM-5.2 puede generar respuestas significativamente más largas en una sola solicitud; (3) esfuerzo de pensamiento: activado/desactivado → Alto/Máximo. El precio ha aumentado: $1.00/$3.20 (GLM-5) → $1.40/$4.40 (GLM-5.2) por millón de tokens. GLM-5.2 solo de texto — es una nueva limitación explícita que no existía en GLM-5. Para acceder a GLM-5.2 a través del chat — se necesita un Plan de Codificación GLM desde $18/mes; el chat.z.ai gratuito sigue en GLM-5.1.

¿Es GLM-5.2 adecuado para tareas multimodales?

No. GLM-5.2 es exclusivamente solo de texto: acepta y genera solo texto. Imágenes, audio, vídeo y capturas de pantalla de PDF sin preprocesamiento no son compatibles. Para tareas multimodales: GLM-5V (modelo cerrado separado de Z.ai), o Claude Chat / ChatGPT con visión nativa. Si el flujo de trabajo incluye diagramas o capturas de pantalla — GLM-5.2 no es adecuado sin una conversión previa a texto.

✅ Conclusiones

• 🔹 El modo Chat de Z.ai implementa un pipeline de finalización estándar sin ciclos de planificación u orquestación adicionales. La mecánica es la misma para GLM-5 y GLM-5.2 — difieren la escala del contexto, los niveles de pensamiento y el precio.
• 🔹 GLM-5 (febrero de 2026): contexto de 200K tokens, pensamiento activado/desactivado, $1.00/$3.20 por millón, chat.z.ai gratuito. Actual para chatbots de producción económicos y RAG.
• 🆕 GLM-5.2 (junio de 2026): contexto de 1M tokens, salida máxima de 128K, pensamiento Alto/Máximo, $1.40/$4.40 por millón, Plan de Codificación GLM desde $18/mes. Solo texto. SWE-bench Pro 62.1% — 2º puesto entre los modelos de codificación. Disponible a través de Claude Code, Cline, Roo Code, Goose y otros.
• 🔹 Ventajas del modo: baja latencia en la primera respuesta, eficiencia en contextos largos gracias a DSA, consumo mínimo de recursos en comparación con el modo Agente, pesos abiertos MIT para auto-alojamiento.
• 🔹 Limitaciones: ausencia de llamadas a herramientas, ejecución iterativa, autocorrección y generación de artefactos; la gestión del contexto está completamente en el cliente; GLM-5.2 solo de texto (sin imágenes/audio); cuotas del Plan de Codificación (Lite: ~400 prompts/semana).
• 🔹 Mejores escenarios: chatbots interactivos, RAG de contexto largo con documentos grandes, revisión de código a escala de repositorio (GLM-5.2), generación de texto/código, brainstorming — donde una respuesta única es suficiente sin ejecución autónoma.

Idea principal: El modo Chat de Z.ai es la opción óptima cuando la prioridad es un contexto grande, un bajo precio de API y una licencia MIT sin dependencia de un proveedor en la nube. GLM-5.2 con 1M de tokens cubre prácticamente las tareas de RAG a escala de repositorio y revisión de código a un precio inferior al de Claude o GPT-5.4. Si se necesita multimodalidad — ChatGPT o Claude. Si se necesita máxima precisión de razonamiento y análisis matizado — Claude Opus. Si se necesitan artefactos y ejecución autónoma — modo Agente de Z.ai.