Cursor testete einen verbesserten Agentenschwarm gegen sein früheres System, indem beide SQLite in Rust nur anhand von Dokumentation neu erstellen sollten — ohne Zugriff auf Quellcode oder das Internet. Jede Konfiguration des neuen Systems erreichte am Ende 100 Prozent in der Testsuite, während der ältere Schwarm durch umfangreiche Merge-Konflikte und doppelte Arbeit ausgebremst wurde.

Bei Cursor haben sich Agentenflotten von einem Forschungsprojekt zu einem Kernprodukt entwickelt. Mit Cursor 3 können Entwickler Flotten von KI-Agenten parallel ausführen. Anysphere, das Unternehmen hinter Cursor, wurde kürzlich von Elon Musks SpaceX für $60 billion übernommen.

Das System trennt Agenten in zwei Rollen. Planner-Agenten, die von Frontier-Modellen angetrieben werden, zerlegen ein Ziel rekursiv in kleinere Aufgaben. Worker-Agenten, die schnellere und günstigere Modelle verwenden, erledigen diese Aufgaben. Der Prozess erzeugt einen Aufgabenbaum, der sich im Verlauf der Arbeit ändern kann.

Cursor zufolge adressiert diese Aufteilung vor allem ein Problem des Kontextmanagements. Ein einzelner Agent muss sich durch den gesamten Aufgabenbaum bewegen und dabei sowohl das Gesamtziel als auch die unmittelbare Aufgabe im Blick behalten. Das kann erklären, warum Agenten bei lang laufenden Aufgaben vom Kurs abkommen. In Cursors Schwarmdesign schreiben Planner keinen Code, und Worker planen nicht.

Git konnte mit 1,000 Commits pro Sekunde nicht mithalten

Ein früherer Browser-Schwarm von Cursor erreichte auf Git etwa 1,000 Commits pro Stunde. Dieses System nutzte Worker-Agenten, einen Judge-Agenten und einen Integrator, der für das Lösen von Konflikten zuständig war. Der Integrator wurde letztlich eher zu einem Engpass als zu einer Lösung.

Der neue Schwarm erreichte 1,000 Commits pro Sekunde. Cursor baute deshalb ein eigenes Versionskontrollsystem und erklärte, dass Agenten, die mit dieser Geschwindigkeit arbeiten, Fehlermodi erzeugen, die menschliche Engineering-Teams normalerweise nicht erleben. Damit geht es in dem Experiment weniger allein um reine Codegenerierung, sondern auch darum, ob Softwareentwicklungsinfrastruktur Tausende automatisierte Änderungen koordinieren kann, ohne in doppelter Arbeit zusammenzubrechen.

Ein Problem war das, was Cursor als "split-brain design" bezeichnete. In diesem Muster bauten zwei Planner unwissentlich dasselbe Konzept in verschiedenen Bereichen der Codebasis und implementierten es auf unterschiedliche Weise. Noch schwieriger wurde es, Konkurrenzsituationen zu steuern, wenn Planner voneinander wussten und sich gegenseitig mit konkurrierenden Änderungen blockierten.

Um diese Probleme zu verringern, ließ Cursor Agenten Entscheidungen in gemeinsamen Designdokumenten festhalten. Code, der mit einer Entscheidung verbunden war, verwies über eine zur Compile-Zeit geprüfte Referenz zurück auf das relevante Dokument.

Wenn Merge-Konflikte auftraten, griff ein neutraler Agent ein, um sie zu lösen. Worker markierten außerdem übergroße Dateien, damit ein externer Agent sie in kleinere Module aufteilen konnte. Weil Agenten gelernt hatten, bei der Arbeit in bestehenden, von Menschen überwachten Codebasen keinen Kerncode anzufassen, erlaubte Cursor ihnen bewusst, Dinge kaputtzumachen. Ein Agent konnte Code außerhalb seines zugewiesenen Bereichs patchen, und der Compiler trug die Änderung durch das System.

Cursor testete mehrere Reviewer und einen von Agenten gepflegten Field Guide

Cursor bewertete mehrere Review-Methoden. Ein Reviewer erhielt das vollständige Transkript des Workers, ein anderer sah nur die Ausgabe des Workers, und ein dritter sah nur die Codebasis. Keine einzelne Perspektive erkannte jedes Problem, doch Cursor stellte fest, dass die Kombination nicht korrelierter Perspektiven die Zuverlässigkeit verbesserte.

Das Unternehmen testete außerdem einen "field guide", einen Wissensordner, der von den Agenten selbst unter einer festen Zeilenbegrenzung gepflegt wurde. Jeder Agent erhielt beim Start den Inhalt des Ordners. Da Modellgewichte nach dem Training fixiert sind, war es laut Cursor nützlich, überraschende Erkenntnisse festzuhalten, damit spätere Agenten Abkürzungen nehmen konnten.

Für den Benchmark gab Cursor dem Schwarm das 835-seitige SQLite-Handbuch und wies ihn an, eine Rust-Implementierung zu bauen. Die Agenten erhielten weder den SQLite-Quellcode noch Testsuiten, die SQLite-Binärdatei oder Internetzugang. Der Benchmark war sqllogictest, eine Testsuite mit Millionen von SQL-Abfragen und bekannten Antworten. Der Schwarm wusste nicht, dass der Benchmark existierte. Dadurch wurde die Aufgabe eher zu einem Test für das Befolgen von Spezifikationen und Systemintegration als zu einer Quellcodeübersetzung oder benchmark-spezifischen Optimierung.

Cursor testete vier Konfigurationen: GPT-5.5 solo, Grok 4.5 solo, Opus 4.8 als Planner mit Composer 2.5 als Worker und Fable 5 als Planner mit Composer 2.5 als Worker. Das neue System übertraf das alte System in jeder Konfiguration. Nach vier Stunden erzielten die neuen Läufe Werte zwischen 73 und 85 Prozent, verglichen mit 11 bis 77 Prozent bei den alten Läufen. Jede Konfiguration des neuen Systems erreichte später 100 Prozent.

Der alte Schwarm erzeugte mehr Arbeit, als er erledigte

Die Grok 4.5-Läufe zeigten, warum das frühere System zurückfiel. Der alte Schwarm erzeugte in zwei Stunden 68,000 Commits, etwa 70-mal so viele wie das neue System. Cursor zufolge war der Großteil dieser Aktivität verschwendet. Der alte Lauf sammelte mehr als 70,000 Merge-Konflikte an, während der neue Lauf während des gesamten Tests unter 1,000 blieb.

Die am stärksten umkämpfte Datei im alten Lauf verzeichnete 7,771 Konflikte mit Beteiligung von 1,173 Agenten. Der vergleichbare Wert im neuen Lauf lag bei 47 Konflikten. Dasselbe Split-Brain-Problem zeigte sich auch in der Paketstruktur. Der alte Lauf teilte das Projekt in 54 Rust-Crates auf und erzeugte drei separate SQL-Pakete, während sich der neue Lauf früh auf neun Crates festlegte.

In der Fable 5-Konfiguration benötigte der alte Schwarm 64,305 Zeilen Engine-Code, verglichen mit 9,908 Zeilen beim neuen System. In der Opus-Konfiguration erzeugte das alte System 19,013 Zeilen und erreichte 97 Prozent. Das neue System erreichte 100 Prozent mit 4,645 Zeilen. Für Cursor waren weniger Zeilen und weniger Konflikte Teil desselben Ergebnisses: Der verbesserte Schwarm leistete weniger redundante Implementierungsarbeit und erzielte zugleich eine höhere Testleistung.

Günstigere Worker-Modelle sorgten für den größten Kostenunterschied

Die Gesamtkosten reichten von $1,339 für die Opus-Hybridkonfiguration bis zu $10,565 für GPT-5.5 im Alleinbetrieb. Worker machten in jedem Lauf mindestens 69 Prozent der Tokens aus, meist sogar mehr als 90 Prozent. Da Planner-Tokens teurer waren, unterschied sich die Kostenverteilung von der Token-Verteilung. Im Opus-Hybridlauf erzeugte der Planner nur einen kleinen Anteil der Tokens, verursachte aber zwei Drittel der Gesamtrechnung.

Die Wahl des Worker-Modells führte zur größten Kostenlücke. Im GPT-5.5-Lauf kosteten allein die Worker $9,373. Im Lauf mit Opus und Composer kostete die gesamte Worker-Flotte bei vergleichbarer Qualität $411. Cursor führte den Unterschied fast vollständig auf die Preisgestaltung zurück. Composer 2.5 benchmarked auf dem Niveau von Opus 4.7 und GPT-5.5, kostet aber $0.50 pro Million Input-Tokens und $2.50 pro Million Output-Tokens. Laut Cursor-Gründer Michael Truell basiert das Modell auf Kimi K2.5.

Cursor argumentiert, dass nur bestimmte Teile einer großen Aufgabe die Intelligenz eines Frontier-Modells benötigen, darunter Aufgabenzerlegung und zentrale Designentscheidungen. Sobald ein Frontier-Planner Mehrdeutigkeit aufgelöst hat, können günstigere Modelle dem Plan folgen. Die Hybridläufe zeigten jedoch auch, dass die Qualität des Planners weiterhin wichtig war. Der Fable 5-Planner verwendete weniger Planning-Tokens als Opus, aber seine Worker benötigten deutlich mehr Tokens, um die Aufgabe abzuschließen, wodurch der Fable-Lauf insgesamt teurer wurde.

Cursor beschreibt Schwärme als eine Art probabilistischen Compiler, der Absicht Schritt für Schritt in ausführbare Arbeit umwandelt. Das Unternehmen erklärte, die wichtigste Einschränkung im Experiment sei gewesen, diese Absicht präzise zu beschreiben. Cursor veröffentlichte die Codebasis aus dem Opus-Solo-Lauf als minisqlite auf GitHub.

Dem Artikel zufolge sind Läufe dieser Art nicht mehr auf Laborexperimente beschränkt. Eine Vorabversion von Fable 5 übernahm den Großteil von Buns Rewrite von Zig zu Rust. Vierundsechzig Instanzen schrieben in 11 Tagen mehr als eine Million Codezeilen zu Kosten von etwa $165,000. Der Produktionseinsatz bleibt anders: Eine Ende 2025 veröffentlichte Studie ergab, dass 68 Prozent der in Produktion eingesetzten Agenten höchstens zehn Schritte abschlossen, bevor ein Mensch eingriff. Bei 47 Prozent lag die Grenze bei weniger als fünf Schritten. Dieser Gegensatz lässt die zentrale praktische Frage offen, wie viel von Cursors kontrolliertem, hochgradig parallelem Workflow auf Produktionsumgebungen übertragen werden kann, in denen Menschen die meisten Agentenläufe weiterhin schnell unterbrechen.