Agenten-Schwarm: 8-mal billiger, gleiches Ziel
Cursor hat SQLite in Rust nachbauen lassen und die Modellkosten verglichen. Teures Modell plant, günstiges arbeitet: Faktor 7,9 bei gleichem Ergebnis.
Cursor hat vier KI-Agenten-Konfigurationen dieselbe Aufgabe lösen lassen und die Rechnungen verglichen. Die günstigste kostete 1.339 Dollar, die teuerste 10.565. Das Ergebnis war in beiden Fällen dasselbe. Der Bericht stammt vom 20. Juli, wurde aber erst diese Woche breiter aufgegriffen, und die Zahlen darin sind das konkreteste Material, das wir bisher zur Frage der Modell-Staffelung gesehen haben.
Die Aufgabe
Der Auftrag lautete, SQLite in Rust nachzubauen. Als Vorlage gab es ausschließlich das 835-seitige Handbuch. Kein Quellcode, keine Testsuiten, keine kompilierte Binärdatei, kein Internetzugang.
Gemessen wurde mit sqllogictest, einer Suite aus Millionen SQL-Abfragen mit verifizierten Antworten, die den Agenten während der Arbeit nicht zur Verfügung stand. Cursor gibt an, die Ergebnisse zusätzlich manuell durchgesehen zu haben, um Abkürzungen und einseitig entwickelte Bereiche auszuschließen.
Die Architektur
Der Aufbau trennt zwei Rollen sauber voneinander:
Der Punkt ist die Disziplin dahinter: Ein Planer implementiert nie, sein Kontext füllt sich also nicht mit Detailkram. Ein Worker plant nie, er kann seinen gesamten Kontext auf ein eng umrissenes Stück Arbeit verwenden. Genau daran scheitern Einzelagenten bei langen Aufgaben, weil sich Planung und Umsetzung im selben Kontextfenster gegenseitig verdrängen.
Die Zahlen
| Konfiguration | Kosten | Ergebnis |
|---|---|---|
| Opus 4.8 als Planer, Composer 2.5 als Worker | 1.339 $ | 100 % der Testsuite |
| Fable 5 als Planer, Composer 2.5 als Worker | zwischen beiden Extremen | 100 % der Testsuite |
| Grok 4.5 als Planer und Worker | nicht einzeln ausgewiesen | 100 % der Testsuite |
| GPT-5.5 als Planer und Worker | 10.565 $ | 100 % der Testsuite |
Der Faktor zwischen günstigster und teuerster Variante beträgt 7,9 bei identischem Endergebnis.
Die Kostenverteilung innerhalb eines Laufs ist die zweite interessante Zahl. Die Worker verarbeiteten 69 bis über 90 Prozent aller Token. Im Opus-Composer-Lauf entfielen trotzdem rund zwei Drittel der Kosten auf den Planer, obwohl er nur einen kleinen Teil der Token verbrauchte. Genau das ist der Hebel: Teure Token gehen an die Stelle, an der Denken gebraucht wird, billige Token an die Stelle, an der Fleiß gebraucht wird.
Der Vergleich zwischen alter und neuer Schwarm-Architektur zeigt, woran der naive Ansatz scheitert. Beim Grok-4.5-Lauf:
| Kennzahl | Alter Schwarm | Neuer Schwarm |
|---|---|---|
| Commits in 2 Stunden | 68.000 | rund 970 |
| Merge-Konflikte in 4 Stunden | über 70.000 | unter 1.000 |
| Konflikte in der umkämpftesten Datei | 7.771 | 47 |
| Zeilen Code am Ende | 19.013 bis 64.305 | 4.645 bis 9.908 |
| Verschiedene Crates | 54 | 9 |
68.000 Commits in zwei Stunden sind kein Fortschritt, sondern Agenten, die sich gegenseitig überschreiben. Der alte Schwarm kam nach vier Stunden auf 11 bis 77 Prozent der Testsuite, der neue auf 73 bis 85 Prozent, und erreichte die vollen 100 Prozent später in allen Konfigurationen.
Was die Zahlen nicht sagen
Vier Einschränkungen gehören dazu, eine davon nennt Cursor selbst.
Es sind Herstellerzahlen. Cursor verkauft Composer 2.5, also genau das Modell, das in der günstigsten Konfiguration die Worker-Rolle übernimmt. Ein Ergebnis, das die eigene Worker-Schicht als ökonomisch überlegen ausweist, ist nicht neutral. Das macht die Messung nicht falsch, aber es ist kein unabhängiger Test.
GPT-5.6 Sol fehlt in der Tabelle. Cursor schreibt, man habe es testen wollen, sei aber auf ausufernde Endlosschleifen gestoßen, die modellspezifisches Prompt-Tuning erfordert hätten. Das hätte den Vergleich verzerrt, also blieb das Modell draußen. Nachvollziehbar begründet, aber damit fehlt ausgerechnet das aktuell teuerste OpenAI-Modell in der Kostenrechnung.
Dann der Aufbau selbst: SQLite aus dem Handbuch nachbauen ist eine Aufgabe ohne Altlasten, ohne fremde Konventionen, ohne über Jahre gewachsene Abhängigkeiten. Ob sich die Ersparnis auf eine Bestandscodebasis überträgt, in der die Hälfte der Arbeit aus Verstehen besteht, ist damit nicht gezeigt.
Und eine bestandene Testsuite ist nicht dasselbe wie Produktivcode. Die Ergebniscodebasis des Opus-Laufs liegt öffentlich als cursor/minisqlite, das ist anständig und überprüfbar. 100 Prozent auf sqllogictest heißt aber, dass die geprüften Abfragen korrekte Antworten liefern. Über Wartbarkeit, Sicherheit oder Verhalten unter Last sagt das nichts.
Was Teams jetzt mitnehmen
Einordnung
Der Versuch bestätigt eine Annahme, die wir in Sonnet 5: Realkosten pro Aufgabe schon aus einer anderen Richtung beschrieben haben: Der Preis pro Million Token sagt wenig darüber aus, was eine erledigte Aufgabe kostet. Neu ist die Größenordnung. Ein Faktor von fast acht bei identischem Ergebnis ist keine Optimierung am Rand, sondern der Unterschied zwischen einem Budget, das trägt, und einem, das nicht trägt.
Dazu passt die Entwicklung im mittleren Modell-Tier. Mit Claude Opus 5 ist ein Modell verfügbar, das auf Coding-Aufgaben nah an die Spitze reicht und dabei den alten Opus-Preis behält. Der Planer im Cursor-Test war noch Opus 4.8.
Wir würden die Zahlen trotzdem nicht ungeprüft übernehmen, und zwar nicht aus Misstrauen gegenüber Cursor, sondern weil ein Neubau nach Handbuch die freundlichste denkbare Aufgabe für diesen Aufbau ist. Alles ist zerlegbar, nichts muss erst verstanden werden. In gewachsenem Code verschiebt sich das Verhältnis, weil der teure Teil dort das Verstehen ist, und genau das lässt sich nicht an ein günstiges Modell delegieren. Die Richtung stimmt. Der Faktor dürfte im Alltag kleiner ausfallen.