Tool Calls en GLM 5.2: Lo que 'OpenAI-Compatible' oculta

Cuando una plataforma se anuncia como 'compatible con OpenAI', la tentación es asumir que cualquier agente o flujo de trabajo escrito para GPT funcionará sin cambios. Con GLM 5.2 esa suposición se desmorona justo en el punto más crítico: el manejo de tool calls. Este modelo, desarrollado por Zhipu, adopta la superficie de la API de chat-completions, pero introduce dos comportamientos que rompen los loops de agentes entrenados con la documentación estándar. En lugar de devolver content vacío cuando emite tool_calls, GLM 5.2 incluye un texto de preámbulo (por ejemplo, 'Voy a buscar esa información por ti') y, además, expone tokens de razonamiento en la misma vuelta. Esto no es un error; es una decisión de diseño que convierte al modelo en una hibridación entre la API de OpenAI y el estilo de Anthropic.

Para los equipos que construyen agentes IA complejos —especialmente en tareas de planificación multietapa o asistentes de código— esta diferencia tiene consecuencias prácticas inmediatas: el bucle de ejecución que asume content = null cuando finish_reason = tool_calls interpretará el preámbulo como una respuesta final o, peor aún, lo descartará silenciosamente, perdiendo información valiosa. La solución es sencilla pero requiere conciencia: tratar cada turno de tool call como potencialmente portador de texto, decidir si se muestra al usuario o se almacena como parte del historial, y, sobre todo, no apoyar la lógica de UI en el primer delta de contenido, porque en streaming llega primero el razonamiento.

El perfil de coste y latencia también cambia las reglas del juego. GLM 5.2 es significativamente más barato por turno que modelos equivalentes de OpenAI y Anthropic (hasta 4-5 veces más económico en caliente gracias al caché de prefijo), pero es también el más lento —entre 2 y 3.5 veces más lento— porque invierte tokens de razonamiento en cada llamada a herramientas. Esto lo convierte en un candidato ideal para procesos largos y desatendidos: automatización de pipelines CI, agentes de código en background, sistemas de análisis batch. En cambio, para interacciones en tiempo real donde cada segundo cuenta, es preferible mantener un modelo rápido y delegar en GLM 5.2 las tareas donde el coste domina.

Adaptar un loop existente a GLM 5.2 no requiere reescribir la arquitectura, sino ajustar dos supuestos: que el turno de tool call es silencioso y que no hay razonamiento oculto. Con esos cambios, un mismo bucle puede manejar GPT, Claude y GLM sin fricción. Desde una perspectiva empresarial, entender estas sutilezas permite elegir el modelo adecuado para cada carga de trabajo, optimizando tanto el presupuesto como la experiencia de usuario. En Q2BSTUDIO aplicamos este conocimiento en cada proyecto de inteligencia artificial para empresas, diseñando agentes que seleccionan dinámicamente el modelo según la tarea, el coste y la latencia tolerada. Esta capacidad de orquestación forma parte de nuestro enfoque integral de desarrollo de aplicaciones a medida, donde combinamos servicios cloud AWS y Azure, inteligencia de negocio con Power BI, y ciberseguridad para crear soluciones robustas y escalables.

La lección final es que 'compatible con OpenAI' no es una garantía, sino un punto de partida. GLM 5.2 demuestra que los detalles de implementación importan, y que un bucle de agente correcto no solo ejecuta las llamadas, sino que interpreta el contexto completo de cada respuesta. Al adoptar este modelo, las organizaciones pueden reducir drásticamente los costes de inferencia en procesos largos, siempre que estén dispuestas a asumir una latencia mayor y a adaptar sus pipelines con las precauciones adecuadas. En Q2BSTUDIO ayudamos a nuestros clientes a navegar este ecosistema, seleccionando las herramientas óptimas para cada caso y asegurando que el rendimiento, el coste y la calidad del agente estén alineados con los objetivos de negocio.