Cursor demuestra que modelos baratos pueden codificar si uno caro planifica

Cursor enfrentó dos versiones de su sistema de enjambre de agentes con una tarea extrema: reconstruir SQLite en Rust usando únicamente la documentación oficial de 835 páginas. Sin código fuente, sin suite de tests a la vista, sin acceso a internet. Todas las configuraciones del sistema nuevo alcanzaron el 100% en la batería de pruebas sqllogictest. El sistema viejo se ahogó en sus propios conflictos de merge.

División de roles: planificadores caros, ejecutores baratos

El enfoque de Cursor separa a los agentes en dos castas. Los planificadores usan modelos de frontera (Opus 4.8, Fable 5, GPT-5.5) para descomponer recursivamente un objetivo en tareas más chicas. Los trabajadores usan modelos rápidos y económicos (Composer 2.5) para ejecutar esas tareas. El resultado es un árbol de tareas que se adapta mientras avanza el trabajo.

Según Cursor, esta división resuelve principalmente un problema de contexto: un agente solitario tiene que recorrer todo el árbol manteniendo en mente tanto el objetivo general como la tarea actual. Eso explica por qué los agentes se desvían en trabajos largos. En el enjambre, los planificadores no escriben código y los trabajadores no planifican.

De 1.000 commits por hora a 1.000 por segundo

Una versión anterior del enjambre de Cursor alcanzaba unos 1.000 commits por hora en Git. Usaba agentes trabajadores, un agente juez y un integrador que resolvía conflictos. El integrador terminó generando más cuellos de botella que los que eliminaba.

El sistema nuevo alcanzó 1.000 commits por segundo. A ese ritmo, Git creaba modos de falla que equipos humanos nunca encuentran, así que Cursor construyó su propio sistema de control de versiones. Los problemas típicos: diseño de "cerebro dividido" (dos planificadores construyendo la misma idea en lugares distintos) y contención mutua cuando los planificadores se bloqueaban entre sí con edits competitivos.

La solución incluyó documentos de diseño compartidos donde los agentes registraban decisiones. El código vinculado a una decisión apuntaba al documento mediante una referencia chequeada en tiempo de compilación. Cuando aparecían conflictos de merge, un agente neutral intervenía. Los trabajadores marcaban archivos hinchados para que un agente externo los dividiera en módulos más chicos.

SQLite en Rust: cuatro configuraciones, una ganadora clara

Cursor probó cuatro configuraciones en la prueba de SQLite: GPT-5.5 solo, Grok 4.5 solo, Opus 4.8 como planificador con Composer 2.5 como trabajador, y Fable 5 como planificador con Composer 2.5 como trabajador. El sistema nuevo venció al viejo en todas.

Después de cuatro horas, las ejecuciones nuevas puntuaron entre 73% y 85% en sqllogictest; las viejas entre 11% y 77%. Todas las configuraciones del sistema nuevo llegaron eventualmente al 100%. Ninguna del viejo.

La ejecución de Grok 4.5 mostró por qué el sistema viejo se quedó atrás: produjo 68.000 commits en dos horas, unas 70 veces más que el nuevo. La mayor parte fue trabajo desperdiciado. El sistema viejo acumuló más de 70.000 conflictos de merge; el nuevo se mantuvo bajo 1.000 durante toda la prueba. El archivo más disputado en el sistema viejo registró 7.771 conflictos de 1.173 agentes, contra 47 en el nuevo.

En código, las diferencias fueron brutales. En la configuración Fable 5, el sistema viejo necesitó 64.305 líneas de código para el motor; el nuevo, 9.908. En Opus, el viejo produjo 19.013 líneas y puntuó 97%; el nuevo llegó al 100% con 4.645 líneas. Recorte de hasta 85% en tamaño de codebase con iguales o mejores resultados.

El modelo trabajador marcó la diferencia de costos

Los costos totales fueron de USD 1.339 para el híbrido Opus hasta USD 10.565 para GPT-5.5 corriendo solo. Los trabajadores representaron al menos el 69% de los tokens en cada ejecución, usualmente más del 90%. Como los tokens del planificador cuestan más, el reparto de costos se ve distinto: en el híbrido Opus, el planificador produjo solo una fracción pequeña de los tokens pero representó dos tercios de la factura total.

La configuración más barata y la más cara difirieron por un factor de 15 a pesar de resultados comparables. El mayor diferencial de costo lo creó el modelo trabajador: en la ejecución de GPT-5.5, los trabajadores solos costaron USD 9.373.

Anysphere, la empresa detrás de Cursor, fue recientemente adquirida por SpaceX de Elon Musk por USD 60 mil millones. Con Cursor 3, los desarrolladores pueden correr flotas enteras de agentes de IA en paralelo.

Por qué importa

Este benchmark confirma algo que muchos equipos están probando en producción: no necesitás el modelo más caro para todo. Si un sistema inteligente puede descomponer problemas complejos, modelos más livianos ejecutan la mayor parte del trabajo real con una fracción del costo.

Para una empresa que está adoptando desarrollo asistido por IA, la arquitectura de Cursor sugiere una ruta: invertir presupuesto de inferencia en planificación de alto nivel y dejar que modelos económicos manejen la implementación. La diferencia de 15x en costo entre configuraciones con resultados equivalentes no es teórica.

La otra lección es sobre la coordinación. Un enjambre mal diseñado genera más trabajo del que completa. El sistema viejo de Cursor produjo 70 veces más commits que el nuevo y colapsó. Escalar agentes no es solo agregar paralelismo; es rediseñar cómo comparten contexto, resuelven conflictos y mantienen coherencia.