GLM 5.3 vs. DeepSeek V4 Pro: resultados, tiempo y coste

Empieza probando GLM 5.3 si conseguir un resultado aceptado adicional en una tarea difícil puede justificar un gasto mayor. DeepSeek V4 Pro-0813 merece una comparación cuando importa especialmente el coste de repetir intentos. En una evaluación publicada, GLM completó más tareas y tuvo una menor mediana de tiempo entre las completadas; Pro costó menos. Eso no establece un ganador universal.

Hay una limitación de disponibilidad cercana. DeepSeek prevé retirar V4 Pro el 14 de septiembre de 2026 a las 12:00 de Pekín: 04:00 UTC o 07:00 de Moscú. Un aviso de la plataforma oficial, visible tras iniciar sesión, indica que las solicitudes Pro se dirigirán a V4.1 Flash y se facturarán con sus tarifas. No bases una nueva integración duradera con la API oficial en que el nombre antiguo seguirá sirviendo Pro-0813.

Esta comparación trata de GLM 5.3 y Pro-0813, no de GLM 5.3 Flash ni de V4.1 Flash. Los resultados históricos de Pro pueden servir como referencia para evaluar su sustitución; no describen el modelo que responderá tras ese nombre después de la retirada.

Qué muestra la evaluación de 30 tareas

El 27 de agosto, Composio publicó una comparación de cinco modelos con 30 tareas de agente de varios pasos:

Métrica de Composio	GLM 5.3	DeepSeek V4 Pro-0813
Tareas completadas	22 de 30	19 de 30
Coste total de las 30 tareas	$5.31	$1.23
Coste publicado por tarea exitosa	$0.24	$0.065
Mediana de tiempo entre tareas completadas	2 min 54 s	4 min 41 s
Agotamientos del tiempo límite	1	3

Resultados originales: finalización, coste total, coste por éxito, tiempo y tiempos agotados.

GLM completó tres tareas más en esta muestra. El coste por éxito de Pro fue unas 3,7 veces menor: $0.24 / $0.065. Son gastos históricos de esa evaluación, sin retrabajo humano, no precios actuales de API.

Las medianas solo incluyen éxitos y los conjuntos de tareas resueltas difieren. No demuestran que GLM sea más rápido en cada tarea idéntica ni que toda una sesión termine proporcionalmente antes. Los intentos fallidos y los tiempos agotados también consumen tiempo.

Es una evaluación de Composio, no una prueba nuestra. Sin parámetros completos, entorno de ejecución y repeticiones, 22 frente a 19 no predice de forma fiable los éxitos en tu proyecto. Trabajar en varios pasos con herramientas externas también difiere de corregir un fallo en un repositorio.

Los benchmarks de programación son más variados

La ficha oficial de GLM 5.3 incluye resultados de Pro-0813:

Prueba de la tabla de Z.ai	GLM 5.3	Pro-0813
Terminal Bench 2.1	88.2	87.9
DeepSWE v1.1	66.9	62.7
NL2Repo	58.0	61.1
Toolathlon Verified	73.0	74.1

GLM lidera las dos primeras filas y Pro las siguientes. Son resultados publicados por Z.ai bajo las condiciones de su ficha, no un sustituto de probar ambos modelos de forma independiente en tu cliente. No se pueden sumar tareas y criterios de puntuación distintos en un único porcentaje de calidad.

También cambian los valores predeterminados. GLM 5.3 usa reasoning_effort = max. La guía actual de DeepSeek V4 activa el razonamiento con esfuerzo high. Dos ejecuciones sin configurar usan modos distintos; igualar los nombres del esfuerzo tampoco demostraría presupuestos de cómputo iguales.

Para reproducir un benchmark, usa sus condiciones publicadas. Para elegir un modelo de trabajo, define coste y tiempo aceptables y prueba ajustes adecuados para cada modelo dentro de esos límites.

Cuenta todos los intentos antes de aceptar el resultado

Define primero el éxito. Un arreglo puede exigir que pase la prueba que fallaba sin introducir regresiones. Un agente que actúa en varios sistemas puede necesitar dejarlos todos en el estado correcto, sin registros adicionales ni acciones duplicadas.

cost_per_accepted_task = total_api_cost_of_all_attempts / accepted_tasks

Incluye en el numerador los fallos, reintentos y llamadas a modelos de respaldo. Sin tareas aceptadas, la métrica no está definida: registra cero éxitos y todo el gasto, no un coste por éxito de cero.

Registra por separado el tiempo humano de revisión y reparación. Si lo conviertes en dinero, usa tu coste por hora y sepáralo del gasto API. Un retrabajo largo puede superar el ahorro en el modelo; mídelo con tus tareas.

En el Dashboard de BetterToken puedes consultar modelo, hora de solicitud, tokens de entrada, salida y caché, y gasto correspondiente. La aceptación y el esfuerzo humano requieren registros separados. Un nombre de modelo registrado no demuestra de forma independiente qué pesos sirvió un proveedor externo.

Decide con tu propia carga de trabajo

Selecciona pocas tareas recurrentes y da a ambos modelos el mismo estado inicial del proyecto, instrucciones, permisos de herramientas y criterios de aceptación. Usa datos de prueba para que repetir acciones externas no genere duplicados reales.

Registra versiones del modelo y cliente, proveedor, modo de razonamiento, tiempo límite y máximo de reintentos. Conserva gasto y resultado de cada ejecución, incluidos los fallos. Compara qué tareas concretas resolvió cada uno, no solo la factura total.

• Cambios complejos con reparación humana cara: prueba primero GLM 5.3 y comprueba si sus ventajas en algunas evaluaciones producen más cambios aceptados en tu caso.
• Tareas bien delimitadas y presupuesto estricto: los resultados históricos de Pro-0813 muestran la utilidad del coste por éxito. Puedes compararlo con tu modelo actual antes de su retirada; continuar exige una opción cuya disponibilidad esté confirmada.
• Procesos largos con varias herramientas: limita el tiempo total, incluidos los reintentos. Las medianas de éxitos omiten el tiempo perdido en tareas inconclusas.

Después del 14 de septiembre, una nueva solicitud oficial a deepseek-v4-pro no cuenta automáticamente como prueba de Pro-0813. Verifica primero el enrutamiento. Si responde V4.1 Flash, es una comparación nueva con GLM 5.3 que necesita resultados nuevos. Comprueba por separado fechas y disponibilidad de terceros.