Nuevo enjambre de agentes alcanzó 100% en pruebas de SQLite a menor costo

Cursor afirma que su último enjambre de agentes ahora realiza la misma tarea de codificación a gran escala con mucho menos caos —y con resultados mucho mejores. En una nueva comparación, la compañía volvió a ejecutar un antiguo desafío que previamente había expuesto los límites de su sistema: construir SQLite desde cero en Rust usando únicamente el manual de SQLite de 835 páginas, sin código fuente, suites de pruebas, binario de SQLite ni acceso a Internet.

Usando los mismos modelos y el mismo presupuesto de tiempo, el nuevo enjambre superó al anterior en todas las configuraciones. Con Grok 4.5, la nueva configuración alcanzó el 80% de una suite de pruebas SQL reservada en cuatro horas, mientras que el enjambre antiguo se degradó lo suficiente como para que Cursor lo pausara antes de la marca de dos horas. En todas las nuevas configuraciones, las ejecuciones se situaron entre 73% y 85% para el corte de cuatro horas, frente al 11% al 77% del arnés antiguo. Cursor afirma que cada nueva configuración eventualmente alcanzó el 100% de la suite.

Cómo Cursor cambió el enjambre

La idea central es un flujo de trabajo con forma de árbol. Agentes planificadores que usan modelos más potentes descomponen un objetivo en subproblemas, mientras que agentes trabajadores que usan modelos más baratos y rápidos los ejecutan. Cursor sostiene que esto importa menos para el paralelismo y más para la eficiencia del contexto: los planificadores evitan los detalles de implementación de bajo nivel y los trabajadores evitan cargar todo el plan del proyecto en su contexto.

Recomendado

El acuerdo de 1.500 millones de dólares de Anthropic con autores recibe la aprobación judi

La compañía también reconstruyó la infraestructura alrededor del enjambre. Su experimento anterior de construir un navegador alcanzó aproximadamente 1,000 commits por hora en Git. El nuevo sistema llega a aproximadamente 1,000 commits por segundo, lo que llevó a Cursor a construir un sistema de control de versiones personalizado.

Ese sistema está diseñado para manejar modos de fallo que, dice la compañía, aparecen a escala de enjambre, incluyendo:

• Diseño split-brain, donde los planificadores toman de forma independiente decisiones arquitectónicas conflictivas
• Contención entre planificadores, con agentes reescribiendo repetidamente los mismos archivos
• Conflictos de fusión a una tasa demasiado alta para las herramientas habituales
• Megaficheros que atraen demasiadas ediciones y se convierten en cuellos de botella
• Ossificación, donde los agentes evitan tocar el código central aunque necesite cambiar

Cursor también añadió sistemas de revisión por capas y una carpeta compartida Field Guide que los agentes mantienen para ejecuciones futuras.

Lo que mostraron las ejecuciones de SQLite

El benchmark utilizó sqllogictest, una suite de pruebas del proyecto SQLite con millones de consultas. Cursor afirma que no se le dijo al enjambre que la suite existía, y que cada ejecución fue revisada manualmente para comprobar atajos o sobreajuste específico a las pruebas.

La diferencia de comportamiento entre los sistemas antiguo y nuevo fue notable. En la antigua ejecución con Grok 4.5, los agentes produjeron 68,000 commits en las primeras dos horas —aproximadamente 70 veces el ritmo de la nueva ejecución— pero también generaron más de 70,000 conflictos antes de que se detuviera la ejecución. La nueva ejecución registró menos de mil conflictos durante las cuatro horas completas.

La estructura de paquetes del enjambre antiguo también se expandió desordenadamente. Creó 54 crates, incluyendo tres paquetes SQL separados. El nuevo enjambre se decidió por nueve crates desde temprano y permaneció allí.

Eso también se reflejó en el tamaño del código. En la mezcla Fable 5, tanto el enjambre antiguo como el nuevo eventualmente pasaron la suite completa, pero el sistema antiguo necesitó 64,305 líneas de código del motor frente a 9,908 del nuevo. En la mezcla Opus, el arnés antiguo usó 19,013 líneas para una calificación del 97%; el nuevo usó 4,645 líneas y alcanzó el 100%.

La economía fue tan desigual. Cursor dice que la calidad fue en general similar entre las mezclas de modelos, pero el costo osciló entre $1,339 para el híbrido Opus 4.8 + Composer 2.5 y $10,565 para GPT-5.5 en solitario. Los trabajadores representaron al menos el 69% de los tokens, y más del 90% en la mayoría de las ejecuciones, pero los tokens de los planificadores impulsaron una parte desproporcionada del gasto. La conclusión de Cursor: usar modelos de vanguardia para la descomposición y la toma de decisiones, y luego delegar la mayor parte de la ejecución a modelos más baratos.