Das System basiert auf einer Zweiteilung: Planer-Agenten mit starken Frontier-Modellen zerlegen ein Ziel rekursiv in Teilaufgaben. Arbeiter-Agenten mit schnelleren und günstigeren Modellen führen sie aus. Die Aufgabenstruktur wächst wie ein Baum, der sich an das Problem anpasst.
Cursor argumentiert, dass die Rollenteilung vor allem ein Kontextproblem löst. Ein einzelner Agent müsse den gesamten Baum selbst durchlaufen und dabei sowohl das übergeordnete Ziel als auch das aktuelle Detail im Kopf behalten. Das erkläre, warum langlaufende Einzelagenten abdriften. Im Schwarm implementiert ein Planer nie selbst, ein Arbeiter plant nie.
Cursor begründet die Skalierbarkeit des Schwarms weniger mit Parallelität als mit der Aufteilung des Kontexts: Planner entscheiden, Worker führen aus. | Bild: CursorEigenes Versionskontrollsystem für 1.000 Commits pro Sekunde
Ein früherer Browser-Schwarm von Cursor erreichte auf Git rund 1.000 Commits pro Stunde. Schon dort arbeitete das System mit getrennten Rollen aus Worker-Agenten, einem Judge Agent und einer Integrator-Rolle für die Konfliktlösung, die am Ende mehr Engpässe schuf, als sie auflöste. Der neue Schwarm schafft 1.000 Commits pro Sekunde. Cursor hat deshalb unter anderem ein eigenes Versionskontrollsystem gebaut, weil bei dieser Frequenz Fehlermodi auftreten, die menschliche Teams nicht kennen.
Ein Problem nennt Cursor „Split-Brain-Design". Zwei Planer implementieren dabei unwissentlich dasselbe Konzept an unterschiedlichen Stellen auf unterschiedliche Weise. Noch schwieriger sei die Kontention, wenn Planer voneinander wissen und sich durch gegenseitige Änderungen blockieren. Cursor lässt Agenten deshalb Entscheidungen in gemeinsamen Design-Dokumenten festhalten. Code, der auf einer Entscheidung basiert, verweist per compile-geprüfter Referenz zurück auf das Dokument.
Bei Merge-Konflikten greift ein neutraler Drittagent ein und löst sie stellvertretend auf. Aufgeblähte Dateien werden von Arbeitern markiert und von einem externen Agenten in kleinere Module zerlegt. Weil Agenten aus der Arbeit in bestehenden Codebasen mit Menschen im Loop gelernt haben, Kerncode nicht anzufassen, erlaubt Cursor absichtliches Brechen. Ein Agent darf einen Patch außerhalb seines Bereichs vornehmen, der Compiler trägt die Änderung dann durch das System.
Mehrere Review-Perspektiven und ein selbst geführter Feldführer
Cursor hat verschiedene Review-Ansätze getestet. Ein Reviewer erhält das vollständige Transkript des Arbeiters, ein anderer nur den Output, ein dritter nur die Codebasis. Keine einzelne Perspektive fange alles ab, doch dekorrelierte Perspektiven ergänzten sich zu höherer Zuverlässigkeit.
Ergänzend testet Cursor einen "Field Guide", einen von Agenten selbst gepflegten Wissensordner mit fester Zeilenbegrenzung. Sein Inhalt wird jedem Agenten beim Start mitgegeben. Da Modellgewichte eingefroren sind, lohne es sich, überraschende Erkenntnisse festzuhalten, damit spätere Agenten kürzere Wege nehmen.
Cursor gab dem Schwarm das 835-seitige SQLite-Handbuch und die Aufgabe, es in Rust zu implementieren. Quellcode, Testsuiten, die SQLite-Binary und Internetzugang wurden zurückgehalten. Bewertet wurde gegen sqllogictest, eine Testsuite mit Millionen von SQL-Anfragen mit bekannten Antworten. Der Schwarm erfuhr nichts von deren Existenz.
Vier Konfigurationen kamen zum Einsatz. GPT-5.5 solo, Grok 4.5 solo, Opus 4.8 als Planer mit Composer 2.5 als Arbeiter sowie Fable 5 als Planer mit Composer 2.5 als Arbeiter. Das neue System schlug das alte in jeder Konfiguration. Nach vier Stunden lagen die neuen Läufe zwischen 73 und 85 Prozent, die alten zwischen 11 und 77 Prozent. Jede neue Konfiguration erreichte im weiteren Verlauf 100 Prozent.
Der alte Schwarm scheiterte an sich selbst
Der Vergleich der Grok-4.5-Läufe zeigt, warum. Der alte Schwarm produzierte 68.000 Commits in zwei Stunden, rund 70-mal so viele wie der neue. Die Aktivität war größtenteils Leerlauf. Der alte Lauf sammelte über 70.000 Merge-Konflikte an, der neue blieb über den gesamten Zeitraum unter tausend.
Die Konfliktkurve der alten Version beschleunigt sich, statt sich zu stabilisieren. | Bild: CursorDie am stärksten umkämpfte Datei im alten Lauf verzeichnete 7.771 Konflikte von 1.173 verschiedenen Agenten. Im neuen Lauf waren es 47. Das Split-Brain-Problem zeigt sich auch in der Paketstruktur. Der alte Lauf zersplitterte in 54 Rust-Crates mit drei separaten SQL-Paketen. Der neue einigte sich früh auf neun. Im Fable-5-Mix brauchte der alte Schwarm 64.305 Zeilen Engine-Code, der neue 9.908. Im Opus-Mix waren es 19.013 Zeilen bei 97 Prozent gegenüber 4.645 Zeilen bei 100 Prozent.
Bei gleichem oder besserem Testergebnis fällt die Codebasis unter der neuen Architektur um bis zu 85 Prozent kleiner aus. | Bild: CursorKostenhebel liegt bei den Arbeitern
Die Gesamtkosten reichten von 1.339 Dollar für den Opus-Hybrid bis 10.565 Dollar für GPT-5.5 solo. Arbeiter trugen in allen Läufen mindestens 69 Prozent der Tokens bei, meist über 90 Prozent. Weil Planer-Tokens teurer sind, verteilen sich die Kosten allerdings anders. Im Opus-Hybrid produzierte Opus als Planer einen kleinen Bruchteil der Tokens, verursachte aber zwei Drittel der Kosten.
Zwischen der günstigsten und der teuersten Konfiguration liegt der Faktor 15, bei vergleichbarer Ergebnisqualität. | Bild: Cursor Die Wahl des Arbeiter-Modells macht den größten Kostenunterschied. Im GPT-5.5-Solo-Lauf kosteten die Arbeiter allein 9.373 Dollar. Im Opus-Composer-Lauf kostete die gesamte Arbeiter-Flotte 411 Dollar bei vergleichbarer Qualität. Der Unterschied erklärt sich fast vollständig über den Preis. Composer 2.5 liegt in Benchmarks auf dem Niveau von Opus 4.7 und GPT-5.5, kostet aber nur 0,50 Dollar pro Million Input- und 2,50 Dollar pro Million Output-Tokens. Das Modell basiert nach Angaben von Cursor-Gründer Michael Truell auf Kimi K2.5.
Cursor argumentiert, dass nur wenige Momente in einer großen Aufgabe wirklich Frontier-Intelligenz erfordern, etwa die Zerlegung und zentrale Design-Entscheidungen. Hat ein Frontier-Planer die Mehrdeutigkeit einmal aufgelöst, müssen günstige Modelle nur noch folgen.
Ein Detail aus dem Vergleich der Hybrid-Läufe zeigt allerdings, dass der Planer trotzdem zählt. Der Fable-5-Planer produzierte weniger Planungs-Tokens als Opus, seine Arbeiter brauchten dafür deutlich mehr Tokens. Der Lauf wurde insgesamt teurer.
Die Worker verbrauchen in jedem Lauf mindestens 69 Prozent der Tokens, verursachen aber nur einen Bruchteil der Kosten. | Bild: CursorCursor beschreibt Schwärme als eine Art probabilistischen Compiler, der Absicht Schritt für Schritt in ausführbare Arbeit übersetzt. Knapp gewesen sei in dem Experiment die richtige Beschreibung der Absicht. Die Codebasis des Opus-Solo-Laufs hat Cursor als minisqlite auf GitHub veröffentlicht.
Technisch sind solche Läufe längst keine Laborgröße mehr. Der Bun-Rewrite von Zig nach Rust wurde größtenteils von einer Vorabversion von Fable 5 erledigt. 64 Instanzen schrieben in elf Tagen über eine Million Zeilen Code für rund 165.000 Dollar. Im breiten Einsatz sieht es anders aus. Laut einer Studie von Ende 2025 führen 68 Prozent der produktiv eingesetzten Agenten höchstens zehn Schritte aus, bevor ein Mensch eingreift. Bei 47 Prozent sind es weniger als fünf.
