Cursor a testé un essaim d’agents amélioré face à son système précédent en demandant aux deux de reconstruire SQLite en Rust uniquement à partir de la documentation, sans accès au code source ni à Internet. Toutes les configurations du nouveau système ont finalement atteint 100 percent sur la suite de tests, tandis que l’ancien essaim a été ralenti par de nombreux conflits de fusion et du travail dupliqué.

Chez Cursor, les flottes d’agents sont passées du statut de projet de recherche à celui de produit central. Avec Cursor 3, les développeurs peuvent exécuter des flottes d’agents IA en parallèle. Anysphere, l’entreprise derrière Cursor, a récemment été acquise par SpaceX d’Elon Musk pour $60 billion.

Le système répartit les agents en deux rôles. Les agents planificateurs, alimentés par des modèles de pointe, décomposent récursivement un objectif en tâches plus petites. Les agents exécutants, qui utilisent des modèles plus rapides et moins coûteux, accomplissent ces tâches. Le processus crée un arbre de tâches qui peut évoluer à mesure que le travail progresse.

Cursor explique que cette séparation répond principalement à un problème de gestion du contexte. Un agent unique doit parcourir tout l’arbre de tâches tout en conservant à l’esprit l’objectif général et la tâche immédiate, ce qui peut aider à expliquer pourquoi les agents dérivent lors de travaux de longue durée. Dans la conception en essaim de Cursor, les planificateurs n’écrivent pas de code, et les exécutants ne planifient pas.

Git ne pouvait pas suivre 1,000 commits par seconde

Un ancien essaim de navigateur de Cursor atteignait environ 1,000 commits par heure sur Git. Ce système utilisait des agents exécutants, un agent juge et un intégrateur chargé de résoudre les conflits. L’intégrateur a finalement créé davantage de goulots d’étranglement qu’il n’en a résolus.

Le nouvel essaim a atteint 1,000 commits par seconde. Cursor a donc construit son propre système de contrôle de version, affirmant que des agents opérant à cette vitesse produisaient des modes de défaillance que les équipes d’ingénierie humaines ne rencontrent normalement pas. Le résultat fait que l’expérience porte moins sur la seule génération brute de code que sur la capacité de l’infrastructure de développement logiciel à coordonner des milliers de modifications automatisées sans s’effondrer dans du travail dupliqué.

L’un des problèmes était ce que Cursor a appelé le "split-brain design". Dans ce schéma, deux planificateurs construisaient sans le savoir le même concept dans différentes zones de la base de code et l’implémentaient de manières différentes. La contention devenait encore plus difficile à gérer lorsque les planificateurs avaient connaissance les uns des autres et se bloquaient mutuellement avec des modifications concurrentes.

Pour réduire ces problèmes, Cursor a demandé aux agents de documenter leurs décisions dans des documents de conception partagés. Le code associé à une décision renvoyait au document pertinent au moyen d’une référence vérifiée à la compilation.

Lorsque des conflits de fusion apparaissaient, un agent neutre intervenait pour les résoudre. Les exécutants signalaient aussi les fichiers trop volumineux afin qu’un agent externe puisse les diviser en modules plus petits. Comme les agents avaient appris à éviter de toucher au code central lorsqu’ils travaillaient dans des bases de code existantes supervisées par des humains, Cursor les a délibérément autorisés à casser des choses. Un agent pouvait modifier du code en dehors de la zone qui lui était attribuée, et le compilateur propageait le changement dans le système.

Cursor a testé plusieurs relecteurs et un guide de terrain maintenu par les agents

Cursor a évalué plusieurs méthodes de relecture. Un relecteur recevait la transcription complète de l’exécutant, un autre ne voyait que la sortie de l’exécutant, et un troisième ne voyait que la base de code. Aucun point de vue unique ne détectait tous les problèmes, mais Cursor a constaté que la combinaison de perspectives non corrélées améliorait la fiabilité.

L’entreprise a également testé un "guide de terrain", un dossier de connaissances maintenu par les agents eux-mêmes avec une limite fixe de lignes. Chaque agent recevait le contenu du dossier au démarrage. Comme les poids des modèles sont figés après l’entraînement, Cursor a indiqué qu’il était utile de consigner les découvertes surprenantes afin que les agents ultérieurs puissent prendre des raccourcis.

Pour le benchmark, Cursor a fourni à l’essaim le manuel SQLite de 835 pages et lui a demandé de construire une implémentation en Rust. Les agents n’ont pas reçu le code source de SQLite, les suites de tests, le binaire SQLite ni l’accès à Internet. Le benchmark était sqllogictest, une suite de tests contenant des millions de requêtes SQL avec des réponses connues. L’essaim ne savait pas que ce benchmark existait. Cette configuration faisait de la tâche un test de respect des spécifications et d’intégration système plutôt qu’une traduction de code source ou une optimisation spécifique au benchmark.

Cursor a testé quatre configurations : GPT-5.5 seul, Grok 4.5 seul, Opus 4.8 comme planificateur avec Composer 2.5 comme exécutant, et Fable 5 comme planificateur avec Composer 2.5 comme exécutant. Le nouveau système a surpassé l’ancien dans toutes les configurations. Après quatre heures, les nouvelles exécutions obtenaient des scores compris entre 73 et 85 percent, contre 11 à 77 percent pour les anciennes. Toutes les configurations du nouveau système ont ensuite atteint 100 percent.

L’ancien essaim générait plus de travail qu’il n’en accomplissait

Les exécutions avec Grok 4.5 ont montré pourquoi le système précédent accusait du retard. L’ancien essaim a produit 68,000 commits en deux heures, soit environ 70 fois plus que le nouveau système. Cursor a indiqué que la majeure partie de cette activité était du travail perdu. L’ancienne exécution a accumulé plus de 70,000 conflits de fusion, tandis que la nouvelle est restée sous 1,000 pendant toute la durée du test.

Le fichier le plus disputé dans l’ancienne exécution a enregistré 7,771 conflits impliquant 1,173 agents. Le chiffre comparable dans la nouvelle exécution était de 47 conflits. Le même problème de split-brain est également apparu dans l’organisation des packages. L’ancienne exécution a divisé le projet en 54 crates Rust et créé trois packages SQL distincts, tandis que la nouvelle s’est rapidement stabilisée autour de neuf crates.

Dans la configuration Fable 5, l’ancien essaim a nécessité 64,305 lignes de code moteur, contre 9,908 lignes pour le nouveau système. Dans la configuration Opus, l’ancien système a produit 19,013 lignes et obtenu 97 percent. Le nouveau système a atteint 100 percent avec 4,645 lignes. Pour Cursor, la réduction du nombre de lignes et de conflits relevait du même résultat : l’essaim amélioré a effectué moins de travail d’implémentation redondant tout en obtenant de meilleures performances aux tests.

Les modèles exécutants moins coûteux ont produit le plus grand écart de coûts

Les coûts totaux allaient de $1,339 pour la configuration hybride Opus à $10,565 pour GPT-5.5 exécuté seul. Les exécutants représentaient au moins 69 percent des tokens dans chaque exécution, et généralement plus de 90 percent. Comme les tokens des planificateurs étaient plus chers, la répartition des coûts différait de la répartition des tokens. Dans l’exécution hybride Opus, le planificateur ne produisait qu’une faible part des tokens, mais représentait deux tiers de la facture totale.

Le choix du modèle exécutant a produit le plus grand écart de coûts. Dans l’exécution GPT-5.5, les exécutants seuls ont coûté $9,373. Dans l’exécution utilisant Opus et Composer, l’ensemble de la flotte d’exécutants a coûté $411 à qualité comparable. Cursor a attribué cette différence presque entièrement à la tarification. Composer 2.5 obtient des benchmarks au niveau d’Opus 4.7 et de GPT-5.5, mais coûte $0.50 par million de tokens d’entrée et $2.50 par million de tokens de sortie. Selon Michael Truell, fondateur de Cursor, le modèle est basé sur Kimi K2.5.

Cursor soutient que seules certaines parties d’une grande tâche nécessitent l’intelligence d’un modèle de pointe, notamment la décomposition des tâches et les décisions de conception clés. Une fois qu’un planificateur de pointe a levé l’ambiguïté, des modèles moins coûteux peuvent suivre le plan. Toutefois, les exécutions hybrides ont aussi montré que la qualité du planificateur restait importante. Le planificateur Fable 5 a utilisé moins de tokens de planification qu’Opus, mais ses exécutants ont eu besoin de beaucoup plus de tokens pour terminer le travail, ce qui a rendu l’exécution Fable plus coûteuse au total.

Cursor décrit les essaims comme une forme de compilateur probabiliste qui convertit une intention en travail exécutable, étape par étape. L’entreprise a indiqué que la principale contrainte de l’expérience était de décrire précisément cette intention. Cursor a publié la base de code issue de l’exécution Opus en solo sous le nom minisqlite sur GitHub.

L’article indique que des exécutions de ce type ne se limitent plus aux expériences de laboratoire. Une version préliminaire de Fable 5 a pris en charge l’essentiel de la réécriture de Bun de Zig vers Rust. Soixante-quatre instances ont écrit plus d’un million de lignes de code en 11 jours pour un coût d’environ $165,000. L’usage en production reste différent : une étude publiée fin 2025 a constaté que 68 percent des agents utilisés en production accomplissaient au plus dix étapes avant l’intervention d’un humain. Pour 47 percent, la limite était inférieure à cinq étapes. Ce contraste laisse ouverte la principale question pratique : dans quelle mesure le workflow contrôlé et fortement parallélisé de Cursor peut-il être transféré à des environnements de production où les humains interrompent encore rapidement la plupart des exécutions d’agents.