Cursor prueba enjambres de agentes: un modelo caro planifica, los baratos ejecutan y el coste baja de 10.565 a 1.339 dólares

Cursor prueba enjambres de agentes: un modelo caro planifica, los baratos ejecutan y el coste baja de 10.565 a 1.339 dólares
Fuente: the-decoder.com

Cursor ha publicado un experimento que pone número a algo que muchos sospechábamos: si un modelo caro planifica bien el trabajo, los modelos baratos pueden hacer casi todo lo demás. La prueba, recogida por The Decoder, consistió en reescribir SQLite en Rust usando solo la documentación. Sin código fuente. Sin internet.

El resultado en dinero: la configuración híbrida más barata costó 1.339 dólares. Un modelo frontera trabajando solo costó 10.565. Ocho veces más para llegar al mismo sitio.

Puntos clave

  • Tarea: reimplementar SQLite en Rust partiendo solo de documentación, medido contra sqllogictest (millones de consultas SQL con respuesta conocida).
  • Arquitectura: agentes planificadores con modelos frontera que descomponen el objetivo, y agentes trabajadores con modelos baratos que ejecutan.
  • A las cuatro horas, las configuraciones nuevas puntuaban entre 73% y 85% y terminaron llegando al 100%. El sistema anterior se quedaba entre 11% y 77%.
  • Conflictos de merge: más de 70.000 en el sistema viejo frente a menos de 1.000 en el nuevo.

El cambio no es el modelo, es la estructura

Lo que Cursor cambió no fue la potencia bruta. Fue partir el cerebro en dos.

En el diseño anterior, un mismo agente planificaba, ejecutaba, revisaba y recordaba. Con proyectos largos eso revienta: el contexto se llena, el agente pierde el hilo y empieza a contradecirse a sí mismo. Los 70.000 conflictos de merge son la firma de ese fallo. Muchos agentes tocando lo mismo sin saber qué estaba haciendo el de al lado.

En el diseño nuevo, un planificador con modelo frontera descompone el objetivo en un árbol de tareas. Cada rama va a un trabajador con modelo barato, con un contexto pequeño y acotado. Y hay una pieza que a mí me parece la más lista de todas: un documento compartido, una especie de cuaderno de campo, donde los agentes anotan lo que van descubriendo. Así el trabajador número 40 no repite el error que ya cometió el número 3.

Menos código para el mismo resultado

El dato que más dice de la calidad no es la puntuación, es el volumen de código.

Con Fable 5 como planificador, el sistema viejo escribió 64.305 líneas y el nuevo 9.908. Con Opus, de 19.013 a 4.645. Los dos alcanzaron entre 97% y 100% de acierto. Seis veces menos código para hacer lo mismo.

Cualquiera que haya revisado un pull request generado por un agente reconoce el patrón. Cuando el modelo no tiene claro el plan, escribe de más: abstracciones que no hacen falta, capas defensivas, código muerto. El código sobrante es la huella de la falta de plan.

Dónde se va el dinero

Los trabajadores consumieron entre el 69% y el 90% de los tokens, pero una fracción mucho menor del coste. Ahí está toda la gracia del reparto: el volumen se lo lleva el modelo barato y el criterio se lo lleva el caro.

The Decoder cita que Composer 2.5 rinde al nivel de Opus 4.7 y GPT-5.5 en benchmarks, y cuesta 0,50 dólares por millón de tokens de entrada. Con esa diferencia de precio, mandar cada subtarea al modelo más potente es tirar dinero.

Hay un dato de contexto que conviene tener presente antes de emocionarse: un estudio de finales de 2025 encontró que el 68% de los agentes en producción no pasaban de diez pasos sin intervención humana, y el 47% necesitaba a alguien antes de cinco. Esto es un experimento controlado con un benchmark que da respuesta correcta, no tu backlog.

Por qué importa

Esto es aplicable el lunes por la mañana, y no hace falta ser Cursor.

La receta, en tres pasos. Usa tu modelo más potente solo para escribir el plan y definir los límites de cada tarea. Manda cada subtarea a un modelo más barato o a un hilo aparte. Y mantén un único documento de decisiones compartido con la arquitectura, las restricciones y los hallazgos raros, para que cada trabajador arranque sabiendo lo que ya se sabe.

Es exactamente la lógica que aplico cuando construyo sistemas con Claude: Opus para pensar y decidir la estructura, Sonnet para la ejecución repetitiva. No es una intuición, es lo que sale a cuenta cuando miras la factura a fin de mes.

Y la revisión, en dos ángulos: el resultado final y el razonamiento que llevó hasta él. Un output correcto por el motivo equivocado te explota tres semanas después.


Relacionado