Cohere rechnet Coding-Agententeams als Budgetfrage durch

Teams schlagen Einzelagenten auf ProgramBench, kosten aber das Drei- bis Siebenfache

Cohere behandelt den Aufbau von Multi-Agenten-Teams für Coding-Agenten als Frage der Rechenzuteilung. Konkret geht es darum, wohin zusätzlicher Inferenz-Compute fließen soll, wenn man von einem Einzelagenten ausgeht und die Pareto-Frontier aus Reward und Kosten erreichen will. Mehr Agenten erzeugen schnell doppelte Arbeit, Koordinationsfehler und höhere Kosten. Eine Aufteilung der Aufgabe garantiert also keinen Gewinn, so das Unternehmen in seinem Beitrag.

Das zentrale Ergebnis auf ProgramBench ist zweischneidig. Teams übertreffen Einzelagenten, kosten aber drei- bis siebenmal so viel. Wer die Leistung des Teams will, zahlt einen deutlichen Aufpreis. Die eigentliche Frage lautet daher, wie sich dieser Aufpreis begrenzen lässt.

Dafür baut Cohere nach eigenen Angaben ein minimales Multi-Agenten-Harness von Grund auf. Darin lassen sich einzelne Stellschrauben getrennt verändern: die Stufe, auf der ein Lead an Worker delegiert (Planung, Implementierung oder Verifikation), die Modelle im Team und die Zahl der Worker. Weil jeweils nur eine Variable wechselt, lässt sich der Beitrag jeder Entscheidung zu Reward und Kosten zuordnen. Dies ist eine Herstellerangabe; der Volltext lag der Redaktion nicht vor.

Laut Cohere halbiert Planung als einzige Delegation die Kosten bei gleichem Reward

Der erste der drei Befunde betrifft die Delegationsstufe. Cohere nennt Planung den wertvollsten Einsatz für Worker. In einem homogenen Team, in dem der Lead selbst entscheidet, wie viele Worker er startet, erreicht ein Lead denselben Reward wie ein durchgehend delegierender Lead, sofern er nur die Planung abgibt und Implementierung wie Verifikation selbst übernimmt. Die Kosten liegen dabei laut Cohere bei der Hälfte.

Plausibel wirkt das, weil Planung viele Alternativen parallel durchspielen kann, ohne dass Code geschrieben und geprüft werden muss. Der Beleg begründet das jedoch nur teilweise. Die Erklärung ist deshalb eine Lesart und keine belegte Aussage der Autoren.

Der zweite Befund soll laut Cohere lauten, dass billige Modelle als Planer taugen, als Implementierer aber nicht. Hier ist Vorsicht geboten: Der Satz bricht im vorliegenden Beleg ab. Welche Kombination aus starkem Lead und billigen Planern verglichen wurde und mit welchem Ergebnis, bleibt offen. Auch den dritten Befund kennt die Redaktion nicht. Er wird hier deshalb nicht rekonstruiert.

17 gemischte Agenten liegen laut Cohere 1,4 Punkte hinter 5 starken, kosten aber 70 Prozent weniger

Das am stärksten verdichtete Resultat: Mit passender Rechenzuteilung kommt ein heterogenes Team aus 17 Agenten laut Cohere bis auf 1,4 Punkte an ein starkes homogenes Team aus fünf Agenten heran, bei 70 Prozent geringeren Kosten. Die Anzahl der Agenten sagt demnach wenig über Leistung oder Preis. Entscheidend ist, wofür welche Agenten eingesetzt werden.

Für Betreiber verschiebt sich damit die Frage. Statt pauschal mehr Agenten zu starten, lässt sich die Teamstruktur gezielt budgetieren: welche Stufen delegiert werden, welche Modelle wo laufen und wie viele Worker überhaupt nötig sind. Der Abstand von 1,4 Punkten ist dann der Preis der Einsparung, und er lässt sich gegen den Kostenvorteil abwägen.

Welche Modelle in beiden Teams steckten und wie hoch die absoluten Budgets waren, geht aus dem vorliegenden Material nicht hervor. Ohne diese Angaben lässt sich schwer beurteilen, wie stark der Effekt von der Modellwahl abhängt und ob er sich auf andere Konfigurationen übertragen lässt.

Vom C-Compiler bis GDAL: Wie bekannte Teamprojekte mit Kosten umgehen

Cohere grenzt sich von mehreren bekannten Teamprojekten ab. Nach diesen Angaben schrieben 16 Claude-Agenten einen C-Compiler mit 100.000 Zeilen, der den Linux-Kernel bauen kann. Das Projekt umfasste rund 2.000 Sessions und etwa 20.000 US-Dollar an API-Kosten. Cursor ließ hunderte Agenten einen Browser schreiben. Bun wurde in 11 Tagen von Zig nach Rust portiert, mit bis zu 64 parallel arbeitenden Claude-Agenten. Dabei arbeiteten je ein Implementierer, zwei adversariale Reviewer und ein Fixer zusammen.

Dazu kommt eine Studie von Factory zum eigenen System. Bei der Neuentwicklung der Bibliothek GDAL hob das Dreirollenteam aus Orchestrator, Implementierer und Validator den Reward gegenüber einem Einzelagenten mehr als auf das Doppelte. Cohere liest das auch als Beleg dafür, wie hoch die Kosten ausfallen können.

Der methodische Punkt: Diese Systeme unterscheiden sich zugleich in Modellen, Rollen und Projektumfang. Ein Vergleich sagt deshalb wenig darüber, welche Designentscheidung den Erfolg trug. Cohere betrachtet keine fertigen Systeme als Ganzes, sondern isoliert einzelne Variablen in einem selbst gebauten Harness. Das macht die Ergebnisse besser zuordenbar. Auf diese Produktivsysteme lassen sie sich aber nicht ohne Weiteres übertragen.

Test-Time-Scaling setzt auf Rollouts und Selektion, Cohere auf Teamstruktur

Bisherige Forschung zum Test-Time-Scaling für Agenten setzt vor allem auf mehrere Versuche und deren Auswertung. Eine Arbeit zu agentischem Coding wandelt Rollouts in kompakte Trajektorien-Zusammenfassungen um. Recursive Tournament Voting wählt daraus aus, während Parallel-Distill-Refine neue Rollouts sequenziell auf Zusammenfassungen früherer Versuche konditioniert. Damit steigt Claude-4.5-Opus auf SWE-Bench Verified von 70,9 auf 77,6 Prozent.

Kozuchi Agent löst mit dem Open-Weight-Modell Qwen3.5-27B und Test-Time-Selection über acht Kandidaten (TTS@8) 374 von 500 Instanzen auf SWE-Bench Verified. Eine frühere Untersuchung zu Sprachagenten fand, dass Skalierung die Leistung steigern kann. Der Zeitpunkt der Reflexion ist dabei wichtig, listenweise Verifikation schneidet am besten ab, und diversifizierte Rollouts helfen.

Der Unterschied zu Cohere liegt in der Stellschraube. Die genannten Arbeiten erzeugen parallele Rollouts, wählen aus und überarbeiten. Cohere fragt dagegen, welche Teile der Arbeit ein Lead an welche Worker mit welchen Modellen delegiert und was das kostet. Die Prozentwerte und Lösungszahlen stammen aus verschiedenen Benchmarks, Modellen und Aufbauten und sind nicht direkt vergleichbar.

Plateau und Verification Gap: Gegenbefunde zu mehr Compute

Einen Gegenbefund liefert eine Studie der Carnegie Mellon University. Sie untersucht Agenten in einer heterogenen Umgebung aus Suche, Coding, Reasoning und Tool-Nutzung. Skaliert wird sequenziell über längere Interaktion und parallel über Trajektorien-Sampling. Keine der beiden Achsen bringe verlässlich nennenswerte Gewinne, so die Autoren. Sie führen das auf ein Plateau beim sequenziellen Skalieren und eine Verification Gap beim parallelen Skalieren zurück. Außerdem stellen sie bei zehn getesteten Agenten deutliche Leistungseinbußen fest, sobald man von domänenspezifischen Tests zu diesem realistischeren Setting wechselt.

Der Widerspruch zu den Coding-Ergebnissen dürfte zum Teil an der Testumgebung liegen. Die CMU-Studie nutzt einen gemischten Benchmark, die übrigen Arbeiten messen auf reinen Coding-Benchmarks wie ProgramBench oder SWE-Bench. Hinzu kommt die Achse: Die CMU-Arbeit skaliert Rollouts und Interaktion, Cohere die Teamstruktur. Ob beide Befunde vergleichbar sind, ist nicht belegt.

Für die Cohere-Aussagen gilt: Es handelt sich um eine Herstellerdarstellung. Zahlen liegen nur für ProgramBench vor, und der Beitrag formuliert Effizienz tendenziell allgemein. Volltext, Code und Daten sowie eine unabhängige Replikation auf weiteren Benchmarks und Modellen fehlen bislang. Bis dahin taugen die Befunde als begründete Hypothese für die Budgetierung von Coding-Teams, nicht als allgemeine Regel.