Cursor probó un enjambre de agentes mejorado frente a su sistema anterior al pedirles a ambos que reconstruyeran SQLite en Rust usando solo documentación, sin acceso al código fuente ni a internet. Todas las configuraciones del nuevo sistema finalmente alcanzaron 100 por ciento en la suite de pruebas, mientras que el enjambre anterior se vio frenado por amplios conflictos de fusión y trabajo duplicado.

En Cursor, las flotas de agentes pasaron de ser un proyecto de investigación a convertirse en un producto central. Con Cursor 3, los desarrolladores pueden ejecutar flotas de agentes de IA en paralelo. Anysphere, la compañía detrás de Cursor, fue adquirida recientemente por SpaceX de Elon Musk por $60 billion.

El sistema separa a los agentes en dos roles. Los agentes planificadores, impulsados por modelos frontier, descomponen recursivamente un objetivo en tareas más pequeñas. Los agentes trabajadores, que usan modelos más rápidos y baratos, completan esas tareas. El proceso crea un árbol de tareas que puede cambiar a medida que avanza el trabajo.

Cursor dice que esta división aborda principalmente un problema de gestión de contexto. Un solo agente tiene que recorrer todo el árbol de tareas mientras retiene tanto el objetivo general como la tarea inmediata, lo que puede ayudar a explicar por qué los agentes se desvían durante trabajos de larga duración. En el diseño de enjambre de Cursor, los planificadores no escriben código y los trabajadores no planifican.

Git no pudo seguir el ritmo de 1,000 commits por segundo

Un enjambre anterior de Cursor para navegador alcanzó alrededor de 1,000 commits por hora en Git. Ese sistema usaba agentes trabajadores, un agente juez y un integrador responsable de resolver conflictos. El integrador terminó convirtiéndose más en un cuello de botella que en una solución.

El nuevo enjambre alcanzó 1,000 commits por segundo. Por eso Cursor construyó su propio sistema de control de versiones, afirmando que los agentes operando a esa velocidad producían modos de fallo que los equipos humanos de ingeniería normalmente no encuentran. El resultado hace que el experimento trate menos sobre la generación bruta de código por sí sola y más sobre si la infraestructura de desarrollo de software puede coordinar miles de ediciones automatizadas sin colapsar en trabajo duplicado.

Un problema fue lo que Cursor llamó "diseño de cerebro dividido". En ese patrón, dos planificadores construían sin saberlo el mismo concepto en distintas áreas del código base y lo implementaban de maneras diferentes. La contención se volvió aún más difícil de gestionar cuando los planificadores eran conscientes unos de otros y se bloqueaban mutuamente con ediciones en competencia.

Para reducir esos problemas, Cursor hizo que los agentes documentaran decisiones en documentos de diseño compartidos. El código asociado con una decisión enlazaba de vuelta al documento relevante mediante una referencia verificada en tiempo de compilación.

Cuando ocurrían conflictos de fusión, intervenía un agente neutral para resolverlos. Los trabajadores también marcaban archivos demasiado grandes para que un agente externo pudiera dividirlos en módulos más pequeños. Debido a que los agentes habían aprendido a evitar tocar el código central mientras trabajaban en bases de código existentes supervisadas por humanos, Cursor les permitió deliberadamente romper cosas. Un agente podía parchear código fuera de su área asignada, y el compilador propagaba el cambio por el sistema.

Cursor probó múltiples revisores y una guía de campo mantenida por agentes

Cursor evaluó varios métodos de revisión. Un revisor recibía la transcripción completa del trabajador, otro veía solo la salida del trabajador y un tercero veía solo el código base. Ningún punto de vista individual detectó todos los problemas, pero Cursor encontró que combinar perspectivas no correlacionadas mejoraba la confiabilidad.

La compañía también probó una "guía de campo", una carpeta de conocimiento mantenida por los propios agentes bajo un límite fijo de líneas. Cada agente recibía el contenido de la carpeta al iniciar. Como los pesos de los modelos quedan fijos después del entrenamiento, Cursor dijo que era útil capturar hallazgos inesperados para que agentes posteriores pudieran tomar atajos.

Para el benchmark, Cursor entregó al enjambre el manual de SQLite de 835 páginas y le indicó que construyera una implementación en Rust. Los agentes no recibieron el código fuente de SQLite, suites de prueba, el binario de SQLite ni acceso a internet. El benchmark fue sqllogictest, una suite de pruebas que contiene millones de consultas SQL con respuestas conocidas. El enjambre no sabía que el benchmark existía. Esa configuración convirtió la tarea en una prueba de seguimiento de especificaciones e integración de sistemas, más que en traducción de código fuente o ajuste específico para el benchmark.

Cursor probó cuatro configuraciones: 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 nuevo sistema superó al antiguo en todas las configuraciones. Después de cuatro horas, las nuevas ejecuciones obtuvieron entre 73 y 85 por ciento, frente a 11 a 77 por ciento en las ejecuciones antiguas. Todas las configuraciones del nuevo sistema alcanzaron posteriormente 100 por ciento.

El enjambre anterior generó más trabajo del que completó

Las ejecuciones con Grok 4.5 mostraron por qué el sistema anterior quedó rezagado. El enjambre antiguo produjo 68,000 commits en dos horas, alrededor de 70 veces más que el nuevo sistema. Cursor dijo que la mayor parte de esa actividad fue trabajo desperdiciado. La ejecución antigua acumuló más de 70,000 conflictos de fusión, mientras que la nueva se mantuvo por debajo de 1,000 durante toda la prueba.

El archivo más disputado en la ejecución antigua registró 7,771 conflictos que involucraron a 1,173 agentes. La cifra comparable en la nueva ejecución fue de 47 conflictos. El mismo problema de cerebro dividido también apareció en la estructura de paquetes. La ejecución antigua dividió el proyecto en 54 crates de Rust y creó tres paquetes SQL separados, mientras que la nueva ejecución se estabilizó pronto en nueve crates.

En la configuración con Fable 5, el enjambre antiguo requirió 64,305 líneas de código de motor, frente a 9,908 líneas en el nuevo sistema. En la configuración con Opus, el sistema antiguo produjo 19,013 líneas y obtuvo 97 por ciento. El nuevo sistema alcanzó 100 por ciento con 4,645 líneas. Para Cursor, menos líneas y menos conflictos fueron parte del mismo resultado: el enjambre mejorado hizo menos trabajo de implementación redundante mientras lograba un mejor desempeño en las pruebas.

Los modelos trabajadores más baratos produjeron la mayor diferencia de costos

Los costos totales oscilaron entre $1,339 para la configuración híbrida con Opus y $10,565 para GPT-5.5 ejecutándose solo. Los trabajadores representaron al menos 69 por ciento de los tokens en cada ejecución y, por lo general, más de 90 por ciento. Como los tokens de los planificadores eran más caros, la distribución de costos fue distinta de la distribución de tokens. En la ejecución híbrida con Opus, el planificador produjo solo una pequeña parte de los tokens, pero representó dos tercios de la factura total.

La elección del modelo trabajador produjo la mayor brecha de costos. En la ejecución con GPT-5.5, solo los trabajadores costaron $9,373. En la ejecución que usó Opus y Composer, toda la flota de trabajadores costó $411 con una calidad comparable. Cursor atribuyó la diferencia casi por completo a los precios. Composer 2.5 obtiene resultados de benchmark al nivel de Opus 4.7 y GPT-5.5, pero cuesta $0.50 por millón de tokens de entrada y $2.50 por millón de tokens de salida. Según el fundador de Cursor, Michael Truell, el modelo se basa en Kimi K2.5.

Cursor sostiene que solo ciertas partes de una tarea grande requieren la inteligencia de un modelo frontier, incluida la descomposición de tareas y las decisiones clave de diseño. Una vez que un planificador frontier resuelve la ambigüedad, los modelos más baratos pueden seguir el plan. Sin embargo, las ejecuciones híbridas también mostraron que la calidad del planificador seguía siendo importante. El planificador Fable 5 usó menos tokens de planificación que Opus, pero sus trabajadores requirieron muchos más tokens para terminar el trabajo, lo que hizo que la ejecución con Fable fuera más cara en conjunto.

Cursor describe los enjambres como una especie de compilador probabilístico que convierte la intención en trabajo ejecutable paso a paso. La compañía dijo que la principal limitación del experimento fue describir con precisión esa intención. Cursor publicó el código base de la ejecución con Opus solo como minisqlite en GitHub.

El artículo dijo que las ejecuciones de este tipo ya no se limitan a experimentos de laboratorio. Una versión preliminar de Fable 5 manejó la mayor parte de la reescritura de Bun de Zig a Rust. Sesenta y cuatro instancias escribieron más de un millón de líneas de código en 11 días con un costo de alrededor de $165,000. El uso en producción sigue siendo diferente: un estudio publicado a fines de 2025 encontró que 68 por ciento de los agentes usados en producción completaron no más de diez pasos antes de que interviniera un humano. Para 47 por ciento, el límite fue de menos de cinco pasos. Ese contraste deja la pregunta práctica clave sobre cuánto del flujo de trabajo controlado y altamente paralelo de Cursor puede trasladarse a entornos de producción donde los humanos todavía interrumpen rápidamente la mayoría de las ejecuciones de agentes.