3 min de lectura

Revolut trasladó a sus desarrolladores de Claude a GLM

RevolutGLMopen-weight модели

Según informes, Revolut convirtió el modelo chino open-weight GLM en el asistente de programación predeterminado para unos 2.000 ingenieros y redujo su gasto en IA cerca de un 90%. El caso muestra cómo las tareas rutinarias pueden pasar a infraestructura propia más barata sin abandonar modelos frontier para los casos complejos.

Qué cambió Revolut en su stack de IA

Para mí, el dato principal no es el origen chino del modelo, sino la escala del cambio: según los informes, Revolut convirtió GLM open-weight en el modelo de programación estándar para unos 2.000 ingenieros. Dealroom habló de un reemplazo de Claude Code, aunque otras publicaciones precisan que las herramientas caras siguen disponibles para tareas complejas y multimodales.

Existe confusión sobre el checkpoint exacto. Algunos informes citan GLM 5.3 de Z.ai y otros GLM-4.5, por lo que no puede atribuirse el resultado con seguridad a una versión concreta. Para un análisis de ingeniería, no es un detalle menor: las versiones implican niveles de calidad, requisitos de infraestructura y reproducibilidad distintos.

La economía declarada es agresiva: unas 56 Nvidia B200 para alojamiento propio, cerca de 0,30 dólares por millón de tokens en un cálculo combinado y una reducción aproximada del 90% en el gasto previo con Anthropic y OpenAI. Sin embargo, los 0,30 dólares son una estimación interna de infraestructura, no una tarifa pública de API. Compararla directamente con precios separados de tokens de entrada y salida de un modelo comercial sería incorrecto.

La calidad resulta menos espectacular que el ahorro. En el benchmark GDPx mencionado, GLM obtuvo un 2,7%, frente al 12,0% de Claude Opus 5.5. Artificial Analysis Intelligence Index v5 no valida una comparación separada realizada por Revolut: sus resultados publicados corresponden a otras condiciones y modelos.

También se informó de una mejora del 70% en el engineering lead time, pero esa cifra está menos respaldada que la estimación de costes. No la atribuiría solo al cambio de modelo sin datos sobre tipos de tareas, proporción de sugerencias aceptadas y volumen de correcciones posteriores.

El ahorro es real; la equivalencia de modelos no

No es una historia de que GLM barata se haya vuelto de repente más inteligente que Claude. Es una historia de enrutamiento por calidad: el flujo rutinario va a un modelo propio económico, mientras las herramientas frontier se reservan para excepciones en las que un error cuesta más que los tokens.

Este enfoque funciona mejor con grandes volúmenes de trabajo repetitivo. Aun así, un modelo más débil puede trasladar silenciosamente costes de la factura de inferencia a revisión, prompts repetidos y corrección de código. Antes que un benchmark promedio, revisaría el tiempo de finalización, la frecuencia de rollbacks y los defectos tras la integración.

La reacción de los desarrolladores también puede ser negativa, aunque el modelo financiero cierre. El ingeniero percibe una respuesta peor de inmediato, mientras la empresa ve el ahorro agregado más tarde. La pregunta central sigue siendo simple: ¿dónde está el límite a partir del cual un token barato empieza a producir código demasiado caro?

Anteriormente analizamos cómo el precio de Claude Opus, los costes de contexto y las decisiones de configuración determinan la economía de los despliegues de IA. Ese análisis aporta contexto a la decisión de Revolut de sustituir Opus por una alternativa más económica.