„Teams kosten das 1,8- bis 5,1-Fache eines einzelnen Agenten, und nur einer der gemessenen Punkte-Unterschiede war statistisch signifikant.“ So fasst Katrina Drozdov von Vals AI am 9. Oktober die Messreihe zusammen, die das Unternehmen auf seinem eigenen Benchmark Vibe Code Bench gefahren hat. Ein nüchterner Befund für eine Technik, die als nächster großer Schritt der KI-Entwicklung gilt. Wer heute Multi-Agenten-Systeme baut, sollte diese Zahlen kennen — nicht weil sie gegen Agenten-Teams sprechen, sondern weil sie zeigen, wo sie sich rechnen und wo nicht. Wie war der Test aufgebaut, was hat er gemessen, und was davon lässt sich übertragen?
Der Testaufbau: 50 Webanwendungen, ein Grader, acht Konstellationen
Sowohl OpenAI als auch Anthropic liefern inzwischen native Unterstützung für Multi-Agenten-Systeme. Ein Lead-Agent kann Subagenten starten, jedem einen Teil der Aufgabe übergeben und anschließend zusammenführen, was zurückkommt. Genau diese Funktion haben die Autoren der Studie gegen den Einzelagenten gestellt. Als Prüfstand diente Vibe Code Bench, ein Benchmark, bei dem aus einer Produktspezifikation eine vollständige Webanwendung entstehen muss. Jede App wird per Docker Compose deployt und von Browser-Agenten bewertet, die sich durch die Workflows klicken. Die Punktzahl ist der Anteil bestandener UI-Tests, gemittelt über 50 Anwendungen.
Der Aufbau passt zu dieser Frage, weil die Arbeit sich fast von selbst in vier Gewerke zerlegt: Datenbank, API, Oberfläche und Deployment. Man kann sich das wie eine Baustelle vorstellen, auf der Rohbau, Elektrik, Sanitär und Fliesen jeweils sauber arbeiten — und am Ende trotzdem die Steckdose über dem Waschbecken sitzt. Solche Übergabefehler schlagen im Benchmark direkt auf die Punktzahl durch. Wer an den Nahtstellen patzt, verliert Punkte.
Getestet wurden GPT-6 Sol und Claude Opus 5.5, jeweils als Einzelagent und als Team, bei mittlerem und maximalem Reasoning-Aufwand. Das ergibt acht Konstellationen, die jeweils einmal über dieselben 50 Apps liefen. Im Team durfte der Lead bis zu fünf Subagenten gleichzeitig beschäftigen; Subagenten durften keine eigenen starten. Beide Leads erhielten dieselbe kurze Anweisung: die Arbeit in unabhängige Teile zerlegen, jeden Teil delegieren, danach integrieren und das Ergebnis prüfen. Aufgabe, Sandbox und Bewertung waren ansonsten identisch.
Teams kosten das Zwei- bis Fünffache — und bringen meist keine gesicherten Punkte
Die Kostenseite ist eindeutig. Ein Team kostete zwischen dem 1,8- und dem 5,1-Fachen eines Einzelagenten derselben Modellstufe. Bei Sol waren das 3,07 statt 1,22 Dollar pro App bei mittlerem Aufwand, also Faktor 2,5, und 8,54 statt 4,82 Dollar bei maximalem Aufwand, Faktor 1,8. Bei Opus fiel der Sprung größer aus: 9,10 statt 4,08 Dollar nach oben, ein Faktor 2,2, und im Maximalmodus rund 122 statt 23,77 Dollar pro App, ein Faktor von 5,1.
Der Punktezugewinn ist dagegen dünn. Nur Sols Team bei mittlerem Aufwand lag mit 7,3 Punkten klar über seinem Einzelagenten, mit p = 0,005 und einem 95-Prozent-Intervall von +2,3 bis +12,4 Punkten. Die drei anderen Differenzen waren statistisch nicht abgesichert: +1,4 Punkte für Sol bei maximalem Aufwand, −0,3 Punkte für Opus bei mittlerem Aufwand und +3,4 Punkte für Opus bei maximalem Aufwand, mit p-Werten zwischen 0,16 und 0,81. Ein Team kann also mehr Punkte bringen — nur belegen lässt sich das in diesem Datensatz fast nirgends.
Woher die Rechnung kommt, lässt sich nachvollziehen. Jeder Subagent hat sein eigenes Kontextfenster mit Spezifikation und aktuellem Arbeitsstand, und dieses Kontextfenster wird bei jedem Modellaufruf erneut mitgeschickt. Bei Opus‘ Maximal-Team lasen die Subagenten im Median 224 Millionen gecachte Tokens pro App, gegenüber 17 Millionen beim Lead und 55 Millionen beim Einzelagenten. Es ist kein Rechenfehler, sondern die Struktur des Verfahrens. Jeder im Team liest mit, und zwar bei jedem Schritt. Ein Opus-Maximal-Team lief in die Zeitgrenze, während es noch verifizierte; seine Kosten von rund 189 Dollar wurden aus den Token-Zahlen geschätzt und in den Mittelwert aufgenommen.
Zwei Lead-Agenten, zwei Arbeitsstile: paralleles Aufteilen gegen einen schriftlichen Vertrag
Interessanter als die Mittelwerte ist, wie unterschiedlich die beiden Leads dieselbe Anweisung umsetzten. Sols Lead zerlegte die App entlang der Architektur — Datenbank samt Seed-Daten, API, Oberfläche, Deployment — und startete alle Subagenten innerhalb etwa einer Minute. Bei maximalem Aufwand teilte er die Oberfläche häufiger in einzelne Funktionsbereiche auf, in 13 von 50 Läufen gegenüber 7 bei mittlerem Aufwand, und legte später im Lauf weitere Subagenten nach. Er beschäftigte etwas mehr Subagenten, 5,1 statt 4,2, und schickte ihnen fast doppelt so viele Nachfass-Anfragen, 31 statt 18 pro App.
Vor allem prüfte dieser Lead das Ergebnis selbst. Er steuerte in 46 von 50 Läufen einen Headless-Browser durch die App und führte dabei etwa doppelt so viele Browsertests aus wie der Einzelagent, überwiegend gegen die öffentliche URL der Anwendung statt gegen localhost innerhalb der Sandbox. Bei mittlerem Aufwand testete der Einzelagent in 18 von 50 Läufen ausschließlich auf localhost, der Team-Lead nur in 4 von 50. In seinen Notizen berichtet der Lead von Fehlern, die erst beim Zusammenkommen der separat gebauten Teile auftreten — eine Oberfläche, die Felder sendet, die nicht zum Datenbankschema passen, oder eine Summe, die in der Oberfläche anders berechnet wird als in der Datenbank. Jede Korrektur ging zurück an den Subagenten, dem die Datei gehörte.
Opus‘ Lead arbeitete genau umgekehrt. Bevor er überhaupt einen Agenten startete, schrieb er ein gemeinsames Dokument, meist `CONTRACT.md`, das Schema, API-Routen und Dateieigentum festhielt — in 42 von 50 Läufen bei mittlerem Aufwand und in 40 von 50 im Maximalmodus; die Einzelagenten taten das praktisch nie. Danach delegierte er in Wellen: bei mittlerem Aufwand erst die Builder, dann meist einen Subagenten für End-to-End-Tests. Bei maximalem Aufwand kam eine Stufe dazu — zuerst das Fundament, dann Features darauf, dann Test und Review. Die READMEs schrieb der Lead in den meisten Läufen selbst, Anwendungscode bearbeitete er in 10 von 50 Läufen bei mittlerem Aufwand und in 26 von 50 im Maximalmodus. Dort umfasste das Team 6,8 Subagenten pro App, in allen 50 Läufen einen Test-Subagenten und rund 1.140 Tool-Aufrufe der Subagenten pro App, gegenüber etwa 270 beim Einzelagenten mit maximalem Aufwand.
Mehr Denkaufwand statt mehr Agenten: Woher der Punktegewinn kam
Team und höherer Reasoning-Aufwand treiben beide die Kosten — nur wirken sie unterschiedlich auf die Punktzahl. Für Sol brachte maximaler Aufwand beim Einzelagenten 11,4 Punkte (p < 0,001), also mehr als die 7,3 Punkte, die ein Team bei mittlerem Aufwand hinzufügte. Der Maximal-Einzelagent lag mit 89,0 Prozent sogar 4,1 Punkte über dem Mittel-Team, ein Unterschied, der nicht signifikant war (p = 0,08) — bei 1,6-fachen Kosten und dreifacher Laufzeit. Bei Sol war die naheliegende Reihenfolge also: erst mehr Aufwand, dann überhaupt über Teams nachdenken.
Bei Opus sah es anders aus. Maximaler Aufwand allein hob die Punktzahl nicht: 89,8 Prozent für 23,77 Dollar gegen 91,5 Prozent für 4,08 Dollar bei mittlerem Aufwand (p = 0,48). Die höchste Punktzahl der ganzen Untersuchung erzielte die Kombination aus maximalem Aufwand und Team mit 93,2 Prozent — zum dreißigfachen Preis des mittleren Einzelagenten, und der Vorsprung von 1,6 Punkten war nicht signifikant (p = 0,36). Über die Modelle hinweg lagen Sols Maximal-Team mit 90,4 Prozent und 8,54 Dollar nur etwa einen Punkt unter Opus‘ mittlerem Einzelagenten, bei doppeltem Preis. Keine dieser Optionen ist ein klarer Standard. Höherer Aufwand brachte Sol mehr, Opus‘ billigste Konfiguration schnitt auf dieser Aufgabenmenge etwa so gut ab wie seine teuerste.
Wo die Zeit hingeht: Der erste Deploy ist nicht der Engpass
Teams und Einzelagenten erreichten ihren ersten Deploy, also das erste erfolgreiche `docker compose up`, ungefähr gleichzeitig. Bei mittlerem Aufwand lagen die Teams jeweils innerhalb einer Minute zum Einzelagenten. Im Maximalmodus deployte Sols Team etwa fünf Minuten früher, Opus‘ Team etwa sechs Minuten später. Der Unterschied entsteht danach. Opus‘ Maximal-Team verbrachte zwei Drittel seiner Laufzeit nach dem ersten Deploy, sein Einzelagent weniger als ein Drittel. In dieser Phase investierten Lead und Subagenten im Median 68 Agenten-Minuten in Tests, zusammengerechnet über alle Beteiligten, gegenüber 10 Minuten beim Einzelagenten.
Parallelität sparte Zeit nur bei Sol, und dort vor allem im Maximalmodus: 28 statt 38 Minuten. Opus‘ Teams brauchten länger, im Maximalmodus bis zum 2,3-Fachen des Einzelagenten. Sie arbeiteten in sequenziellen Wellen, die jeweils auf ihr langsamstes Mitglied warteten, und im Maximalmodus lief ein Subagent im Median 46 Minuten, gegenüber 7 Minuten bei mittlerem Aufwand. Die zusätzliche Zeit war dabei echte Subagenten-Arbeit, keine Wartezeit. Genützt hat sie wenig: Beim Opus-Maximal-Team zeigte sich über die Apps hinweg keine Korrelation zwischen Laufzeit und Punktegewinn gegenüber dem Einzelagenten. Vier Läufe dauerten über vier Stunden, einer riss die Grenze von 5,25 Stunden.
Was das für die Praxis bedeutet
Ob sich Multi-Agenten-Systeme lohnen, lässt sich nach diesem Datensatz so beantworten: manchmal, und im Mittel nur knapp. Der eine belastbare Gewinn entstand dort, wo der Einzelagent noch schwach war und die Arbeit sich sauber an Architekturgrenzen teilen ließ. Sols mittleres Team bei 84,9 statt 77,6 Prozent ist genau dieses Muster. Es war auf 24 Apps besser als der Einzelagent, auf 11 schlechter und auf 15 gleich, und der Gewinn lag fast ganz bei den schwierigeren Apps: dort rund 15 Punkte, bei den leichteren etwa einen. Auf den neun Apps, auf denen das Team 20 Punkte oder mehr zulegte, hatten die Einzelagenten gemeldet, die Tests seien bestanden, obwohl manche Funktionen nie gebaut und ganze Abläufe nie ausprobiert worden waren. Das Team baute diese Funktionen und prüfte die getrennt gebauten Teile gegeneinander. Wo der Einzelagent dagegen schon bei 91,5 Prozent lag, wie Opus bei mittlerem Aufwand, brachte das Team nichts mehr und kostete das Doppelte.
Für die Praxis heißt das, die Reihenfolge umzudrehen. Erst den Einzelagenten mit mehr Reasoning-Aufwand und besserer Werkzeugnutzung ausreizen, das messen, und Agenten erst dann hinzunehmen, wenn der Flaschenhals nachweislich in der Arbeitsmenge liegt und nicht in der Qualität. Achte außerdem auf zwei Details, die in den Logs deutlich sichtbar sind: Ein Lead, der selbst gegen die deployte Anwendung testet, findet Nahtstellenfehler, die kein Subagent in seiner Sandbox sieht. Und Kontext, der pro Subagent mitgeschleppt wird, ist der eigentliche Kostentreiber — nicht die Anzahl der Modellaufrufe an sich. Opus‘ Maximal-Team mit 224 Millionen gecachten Tokens pro App ist dafür das anschaulichste Beispiel.
Man sollte die Studie allerdings nicht überdehnen. Es sind 50 Apps, jede Konstellation lief einmal, und alle Aufgaben stammen aus einem einzigen Feld: vollständige Webanwendungen aus einer Spezifikation. Die Autoren sagen das selbst und nennen weitere Grenzen: Die Teams bekamen zusätzlich eine Delegationsanweisung, verglichen wird also „Subagenten plus Anweisung“ mit keinem von beidem. Die Modelle liefen in verschiedenen Umgebungen, Sol über die Agents API von OpenAI, Opus über Claude Code, sodass Vergleiche zwischen den Modellen immer auch die Umgebung mitmessen. Und bei Sol beruhen die Kosten auf der Annahme, dass die gemeldeten Token die Subagenten enthalten; höhere Preise für sehr lange Kontexte konnten nicht berücksichtigt werden. Für Recherche, Datenanalyse oder Arbeit mit eng verzahnten Abhängigkeiten kann die Bilanz anders aussehen, in beide Richtungen. Festzuhalten bleibt: Agenten-Teams sind kein Schalter, den man umlegt, um besser zu werden. Sie verursachen laufende Kosten. Wer sie einsetzt, sollte sich auf eine Messung stützen, nicht auf das Gefühl, dass mehr Agenten mehr Ergebnis bedeuten.
Quelle: vals.ai
