Cursor puso sus enjambres de agentes en una tarea real: reconstruir SQLite en Rust usando solo las 835 páginas de documentación, sin código fuente ni internet. El sistema nuevo divide los agentes en dos roles: planificadores con modelos frontier que descomponen el trabajo, y ejecutores con modelos económicos que lo llevan a término. Cada configuración del nuevo sistema alcanzó el 100% de la suite de pruebas; la versión anterior se detenía entre 11 y 77%.

Por qué te importa: la arquitectura cuenta más que el modelo individual, y ahora hay un número que lo demuestra. La configuración híbrida Opus 4.8 como planificador y Composer 2.5 como ejecutor gastó 1.339 dólares contra los 10.565 de GPT-5.5 usado solo, con el mismo resultado final (fuente: The Decoder, 26 de julio de 2026). Los ejecutores consumen entre el 69 y el 90% de los tokens en cada ejecución: ahí es donde el ahorro se materializa, porque usas el modelo costoso solo donde importa el juicio, no donde importa el esfuerzo.

El principio va más allá del código. Si tienes una tarea larga con pasos repetitivos, separar quién decide de quién ejecuta cambia la ecuación costo-calidad. Es la misma dirección de tres papers que contábamos el 20 de julio: la orquestación gana a la potencia bruta.

En detalle

El test de Cursor es serio en su configuración. Los agentes reciben el manual SQLite de 835 páginas y deben producir una implementación en Rust que pase sqllogictest, una suite con millones de consultas SQL y respuestas conocidas. Nada de código fuente, nada de suite de pruebas visible, nada de internet. Cuatro configuraciones en comparación: GPT-5.5 solo, Grok 4.5 solo, Opus 4.8 como planificador con Composer 2.5 como ejecutor, y Fable 5 como planificador con Composer 2.5 como ejecutor.

Después de cuatro horas, las configuraciones del nuevo sistema marcaban entre 73 y 85%, para luego llegar todas al 100%. El sistema anterior llegaba como máximo al 77% y en un caso se detenía en 11%.

Dónde el sistema anterior fallaba. La versión anterior producía 68.000 commits en dos horas, aproximadamente 70 veces más que el nuevo sistema. La mayoría era trabajo desperdiciado: más de 70.000 conflictos de fusión acumulados, contra menos de 1.000 en el nuevo. El problema principal era el llamado “split-brain”: dos planificadores construían la misma idea en lugares diferentes, con implementaciones distintas. Cuando los planificadores se conocían, se bloqueaban mutuamente con cambios en competencia.

Cómo lo resolvieron. Los agentes registran las decisiones en documentos de diseño compartidos. El código vinculado a una decisión lleva una referencia verificada por el compilador. Cuando emergen conflictos, un agente neutral los resuelve. Los archivos demasiado grandes se marcan para descomposición en módulos más pequeños.

Un detalle interesante es la guía de campo, una carpeta de conocimiento mantenida por los agentes mismos con un límite de líneas fijo. Cada agente recibe su contenido al inicio. Dado que los pesos del modelo están congelados, capturar los descubrimientos sorprendentes permite a los agentes posteriores tomar atajos. Es memoria externa, no entrenamiento.

El costo. Los totales van desde 1.339 dólares de la configuración Opus híbrida hasta 10.565 de GPT-5.5 solo. Los ejecutores consumen al menos el 69% de los tokens en cada ejecución, generalmente más del 90%. Los planificadores cuestan más por token pero usan muchos menos. La economía es clara: gasta donde importa el juicio, ahorra donde importa la perseverancia.

Una limitación de lectura. Los números provienen de la implementación de Cursor en una sola tarea, por muy ambiciosa que sea. SQLite tiene una especificación excelente y una suite de pruebas rigurosa: condiciones casi ideales para un agente. No es seguro que la misma ventaja se mantenga en tareas con requisitos vagos o documentación fragmentaria. Y el hecho de que Cursor haya tenido que construir un sistema de control de versiones propio para gestionar 1.000 commits por segundo dice cuánto esta arquitectura está vinculada a una infraestructura específica, no replicable con un prompt.

Si quieres entender cómo aplicar el principio de separación entre planificación y ejecución a tus tareas, la lección del curso sobre cómo orquestar múltiples agentes parte de aquí: roles claros en lugar de responsabilidades duplicadas.