Niklaus Harness Leaderboard testet Kimi Code, Hermes, Pi, Claude Code und Codex jenseits von Markenrankings
Joël Niklaus verglich neun Coding-Agent-Harnesses in 28.849 Durchläufen und stellte damit die Annahme infrage, dass die Modellwahl die Leistungsfrage abschließend klärt. Die Niklaus Harness Leaderboard bewertet die Software, welche die Arbeit eines Modells steuert, während zugrunde liegendes Modell und Reasoning-Einstellungen kontrolliert werden. Die ersten Ergebnisse platzieren mehrere bekannte Tools in einem ähnlichen Genauigkeitsbereich; Unterschiede bei Effizienz und Reproduzierbarkeit erschweren jedoch die Kür eines eindeutigen Gewinners.
Der Vergleich umfasst Kimi Code, Hermes Agent, Pi, Claude Code, Codex, OpenCode, mini-swe-agent, Qwen Code und OpenClaw. Ein Harness ist die Software, die Anweisungen, Tools und Ausführungsschleifen eines KI-Modells verwaltet. Hier wird genau diese umgebende Software zur untersuchten Variable.
Im Zentrum steht die Spannung zwischen dem Ruf eines Produkts und dem Verhalten einer konkret getesteten Konfiguration. Die Ergebnisse belegen nicht, dass Claude Code oder Codex mit ihrem Standardmodell generell besser abschneiden. Sie untersuchen, was passiert, wenn verschiedene Harnesses ausgewählte offene Modelle unter kontrollierten Bedingungen betreiben – eine engere Fragestellung mit praktischen Folgen für Entwickler.
Was die Niklaus Harness Leaderboard tatsächlich vergleicht
Das Experiment isoliert die umgebende Agentensoftware, statt jedes Coding-Produkt als untrennbares Gesamtpaket zu behandeln.
In seiner Beschreibung der Veröffentlichung erklärt Niklaus, dass Modell, Anbieter und Reasoning-Aufwand konstant bleiben, während der Harness wechselt. Jede Aufgabe erhält drei Versuche. Die erste Bewertung umfasst GLM-5.3-Flash, DeepSeek-V4.1-Flash und Flint und verwendet Terminal-Bench 2.1 sowie DeepSWE.
Dieses Design ist relevant, weil bei üblichen Produktvergleichen oft mehrere Variablen gleichzeitig verändert werden. Ein Entwickler, der Coding-Assistenten wechselt, kann zugleich Modell, Anweisungen, verfügbare Tools, Berechtigungen und Ausführungsverhalten ändern. Ein Leistungsunterschied lässt sich dann nur schwer zuordnen.
Die Beschreibung der Veröffentlichung berichtet für mini-swe-agent eine durchschnittliche Lösungsrate von 51,4 % über die drei Modelle hinweg, verglichen mit 27,3 % für OpenClaw. Niklaus sagt zudem, dass vier weitere Harnesses statistisch mit dem führenden Ergebnis gleichauf liegen. Diese Zahlen beschreiben die erste Veröffentlichung, nicht eine dauerhafte Rangliste.
Seine modellspezifischen Ergebnisse verkomplizieren diesen Gesamtdurchschnitt. Laut Niklaus führt mini-swe-agent bei GLM-5.3-Flash, Hermes Agent bei DeepSeek-V4.1-Flash und Kimi Code bei Flint. Die Reihenfolge hängt somit davon ab, welches Modell ein Entwickler einsetzen möchte.
Die unmittelbare Schlussfolgerung ist begrenzt, aber folgenschwer. Ein Harness, der mit einem Modell gut funktioniert, erzielt nicht automatisch dieselbe relative Leistung mit einem anderen. Ein Gesamtscore kann bei der Auswahl von Kandidaten helfen, zugleich aber gerade die Paarung verdecken, die für einen realen Einsatz entscheidend ist.
Terminal-Bench bewertet Agenten bei Aufgaben in Terminalumgebungen, in denen Software Befehle ausführt und mit Dateien interagiert. DeepSWE liefert eine separate Bewertung für Software Engineering. Beide zusammen erweitern den Vergleich, doch die Kombination der Ergebnisse macht die Aufgabensammlungen nicht automatisch repräsentativ für jeden Entwicklungsworkflow.
Das Experiment benötigt zudem ein Datum für seine Schlussfolgerungen. Bei der Prüfung für diesen Artikel zeigte die Live-Anwendung Version v0.1.2 an. Ihre aktuelle Beschreibung verweist auf die Prüfung gleichwertiger Anbieter, statt lediglich die Formulierung der ersten Veröffentlichung zu festen Anbietern zu wiederholen.
Diese Unterscheidung verdient Aufmerksamkeit, weil sich ein Benchmark nach seiner ersten Ankündigung weiterentwickeln kann. Neue Harness-Versionen, zusätzliche Durchläufe oder überarbeitete Kontrollen können die Bedeutung eines Screenshots verändern. Startwerte bleiben Belege für die Startkonfiguration, selbst wenn das aktuelle Board eine andere Reihenfolge zeigt.
Für Leser der ursprünglichen Reddit-Diskussion betrifft die wesentliche Korrektur daher den Umfang. Dies ist ein Vergleich ausgewählter Harness-und-Modell-Kombinationen. Es ist kein umfassender Test jeder Funktion, jedes Abonnementerlebnisses oder jeder Standardkonfiguration, die mit den aufgeführten Produktnamen verbunden ist.
Anbieter von Coding-Agenten geraten unter Druck, die gesamte Konfiguration zu erklären
Die Ergebnisse setzen Behauptungen unter Druck, die die Leistung eines Agenten vollständig seinem zugrunde liegenden Modell zuschreiben.
Für Harness-Entwickler macht der Vergleich Implementierungsentscheidungen sichtbarer. Anweisungen, Tool-Schnittstellen, Wiederholungsverhalten und Entscheidungen zum Abbruch prägen sämtliche Arbeit, die ein Modell verrichtet. Selbst ein starkes Modell kann durch die Software, die es steuert, auf Reibung stoßen.
Für Modellanbieter führt dasselbe Experiment zu einem Zuordnungsproblem. Ein enttäuschendes Ergebnis innerhalb eines bestimmten Agenten weist nicht das Modell als alleinige Ursache aus. Umgekehrt belegt ein starkes Ergebnis nicht, dass jede Anwendung mit denselben Gewichten es reproduzieren wird.
Für Unternehmenskäufer verändert dies, was eine aussagekräftige Bewertung beschreiben muss. Die Nennung eines Modells und eines Assistenten reicht nicht aus, wenn Konfigurationsentscheidungen die Ergebnisse beeinflussen. Käufer benötigen genügend Informationen, um die getestete Kombination zu verstehen und das für ihre Arbeit relevante Verhalten nachzuvollziehen.
Eine hypothetische Wartungsaufgabe macht den Unterschied greifbar. Ein Agent könnte ein Repository untersuchen, einen fehlgeschlagenen Test identifizieren, eine Funktion ändern und die Änderung überprüfen müssen. Jede Stufe hängt davon ab, wie der Harness Informationen bereitstellt und die Abfolge der Aktionen steuert.
Wenn der Agent nach der Bearbeitung stoppt, ohne den relevanten Test auszuführen, bleibt ein plausibler Patch ungeprüft. Wenn er weiterhin unproduktive Befehle ausführt, wird der Abschluss langsamer und ressourcenintensiver. Das sind operative Unterschiede, selbst wenn das zugrunde liegende Modell unverändert bleibt.
Damit ist nicht belegt, welche Implementierung ein bestimmtes Leaderboard-Ergebnis verursacht hat. Dafür müssten Ausführungsprotokolle geprüft und Eingriffe getestet werden. Es erklärt jedoch, warum der kontrollierte Vergleich eine nützliche Frage stellt, die ein reines Modellranking nicht beantworten kann.
Die Ergebnisse zum Start ziehen auch eine Grenze um die bekannte Debatte Claude Code vs Codex. Diese Produktnamen stehen häufig für vollständige Erfahrungen, die um bestimmte Modellfamilien herum aufgebaut sind. Ihre Harnesses mit ausgewählten offenen Modellen zu testen, stellt eine andere Frage dar als der Vergleich dieser vollständigen Erfahrungen.
Eine niedrige Platzierung in diesem Experiment würde nicht belegen, dass der Standarddienst eines Produkts schlecht arbeitet. Eine hohe Platzierung würde keine Überlegenheit bei Code Review, interaktiver Zusammenarbeit oder organisationsspezifischen Workflows belegen. Solche Behauptungen benötigen Bewertungen, die diese Aktivitäten direkt messen.
Das Kimi Code Benchmark-Ergebnis unterliegt derselben Einschränkung. Die berichtete Führung mit Flint spricht dafür, diese Paarung unter den getesteten Bedingungen weiter zu untersuchen. Sie belegt keine allgemeine Führung über nicht verwandte Modelle oder Repositories hinweg.
Für Anbieter besteht die konstruktive Reaktion darin, Konfigurationen zu veröffentlichen und Änderungen zu erläutern, die Ergebnisse beeinflussen. Käufer können dann zwischen einem Modell-Upgrade und einer Harness-Verbesserung unterscheiden. Das erleichtert die Bewertung von Leistungsbehauptungen und die Untersuchung von Fehlern.
Der Druck ist besonders relevant für Teams, die offene Modelle über austauschbare Agentensoftware betreiben. Ihre Kaufentscheidung umfasst die Ausführungsebene. Sie benötigen Belege dafür, welchen Beitrag diese Ebene leistet, statt sich vollständig auf einen bekannten Produktnamen zu verlassen.
Ähnliche Genauigkeit kann unterschiedliches Betriebsverhalten verbergen
Ein knappes Genauigkeitsergebnis lässt Raum für bedeutende Unterschiede bei Ressourceneinsatz, Latenz und Konsistenz.
Das aktuelle Board trennt mehrere Messgrößen, statt Genauigkeit als vollständige Antwort darzustellen. Seine Bewertungsmethode beschreibt die externe Messung der Modellnutzung und unterscheidet die Modellverarbeitungszeit von der Zeit, die für die Ausführung des Agenten benötigt wird. Diese Unterscheidungen helfen zu erklären, warum ähnliche Lösungsraten unterschiedliche Betriebserfahrungen hervorbringen können.
Das Board stellt außerdem Genauigkeit Kosten gegenüber und identifiziert eine Pareto-Front, also die Menge an Optionen, die kein Wettbewerber bei beiden dargestellten Kennzahlen übertrifft. So können Leser konkurrierende Vorteile prüfen, ohne anzunehmen, dass die höchste Genauigkeit immer vorzuziehen ist.
Diese Einordnung ist wichtig, wenn eine Organisation ein festes Arbeitsvolumen und begrenzte Ressourcen hat. Ein kleiner Genauigkeitsvorteil kann bei einer schwierigen Aufgabe mit minimalem Betreuungsaufwand wertvoll sein. Derselbe Vorteil kann weniger attraktiv sein, wenn er bei routinemäßigen Wartungsarbeiten erheblich mehr Ausführungszeit erfordert.
Auch ein Effizienzergebnis benötigt Interpretation. Geringere Ausgaben bedeuten nicht zwangsläufig, dass ein Agent effektiver schlussfolgert. Sie könnten weniger Versuche, einen früheren Abbruch, kürzere Ausgaben oder ein anderes Muster der Tool-Nutzung widerspiegeln. Das Ausführungsprotokoll hilft, produktive Zurückhaltung von vorzeitigem Scheitern zu unterscheiden.
Ebenso belegt eine längere Ausführung keine Verschwendung. Ein Agent könnte zusätzlichen Aufwand in die Prüfung eines Patches oder die Erholung von einem fehlgeschlagenen Ansatz investieren. Entscheidend ist, ob die Zusatzarbeit ein Ergebnis verbessert, das das Team tatsächlich wertschätzt.
Deshalb beantworten Berichte über den Ressourceneinsatz pro Versuch und pro erfolgreichem Ergebnis unterschiedliche Fragen. Ein günstiger fehlgeschlagener Versuch bleibt ein Fehlschlag. Ein aufwendigerer erfolgreicher Versuch kann dennoch die bessere Wahl sein, wenn menschliche Nacharbeit sonst den Workflow dominieren würde.
Dies sind Überlegungen zur Bewertung und keine für jeden Harness auf dem Board belegten Erklärungen. Ein Diagramm kann ein untersuchenswertes Muster sichtbar machen. Es kann für sich allein jedoch nicht die Anweisung oder das Tool-Verhalten identifizieren, das für dieses Muster verantwortlich ist.
Der Mechanismus ist im Grundsatz einfach. Ein Agent erhält Informationen, wählt eine Aktion, beobachtet das Ergebnis und entscheidet über den nächsten Schritt. Der Harness kontrolliert wichtige Teile dieser Schleife, darunter die verfügbaren Tools und die Art, wie deren Antworten das Modell erreichen.
Man denke an ein hypothetisches Repository mit einem fehlgeschlagenen Build aufgrund eines Umgebungsproblems. Ein Agent, der wiederholt Anwendungscode bearbeitet, kann Ressourcen verbrauchen, ohne die Ursache anzugehen. Eine andere Konfiguration könnte das Umgebungsproblem erkennen und ihre Untersuchung entsprechend umlenken.
Der Unterschied beträfe die Aufgabenausführung und nicht das reine Modellwissen. Um diese Erklärung zu belegen, müsste das beobachtete Verhalten mit dem Ergebnis abgeglichen werden. Ohne diese Prüfung geht die Aussage, ein bestimmter Harness sei „intelligenter“, über die Belege hinaus.
Die Niklaus Harness Leaderboard unterstützt daher einen spezifischeren Vergleich, als es ein einzelnes Gewinnerlabel nahelegt. Entwickler können fragen, welche Kombinationen eine akzeptable Genauigkeit erreichen und dabei Ressourcen so nutzen, dass ihre Arbeitslast dies zulässt. Die Antwort kann zwischen interaktiver Entwicklung und unbeaufsichtigtem Betrieb variieren.
Sie verändert auch die Lesart einer Kimi Code Benchmark-Schlagzeile. Eine modellspezifische Führung ist ein nützliches Signal für eine weitergehende Bewertung. Ohne Informationen zu fehlgeschlagenen Versuchen, Ausführungsdauer und dem Verhalten, das den Score erzeugt hat, bleibt sie unvollständig.
Aus demselben Grund sollten Vergleiche zwischen Claude Code und Codex den getesteten Kontext bewahren. Die Namen bieten Orientierung, doch die Konfiguration bestimmt, was das Ergebnis tatsächlich beschreibt.
Reproduzierbarer Erfolg ist ein anderes Ergebnis als gelegentlicher Erfolg
Ein Agent, der eine Aufgabe nur gelegentlich löst, stellt ein anderes Bereitstellungsversprechen dar als einer, der sie zuverlässig löst.
Niklaus hob anschließend die Zuverlässigkeit über wiederholte Versuche hinweg hervor. Laut seiner Aufschlüsselung zur Zuverlässigkeit löste mini-swe-agent im Durchschnitt 51,4 % der Aufgaben pro Versuch. Über drei Versuche hinweg löste es 68,6 % mindestens einmal, aber nur 33,0 % bei jedem Versuch.
Diese Messungen beschreiben unterschiedliche operative Fragen. Der Durchschnitt erfasst die Leistung über mehrere Versuche hinweg. Mindestens ein Erfolg erfasst, ob wiederholte Chancen letztlich eine Lösung hervorbringen. Erfolg bei jedem Versuch erfasst die Konsistenz innerhalb der gemessenen Versuche.
Der Unterschied wird wichtig, wenn jemand dem Agenten bei der Arbeit zusieht. Ein Entwickler kann einen fehlgeschlagenen Versuch prüfen, eine Anweisung ändern oder entscheiden, dass ein weiterer Durchlauf sinnvoll ist. Menschliche Aufsicht kann intermittierenden Erfolg nützlich machen, obwohl die dafür aufgewendete Zeit weiterhin Teil des Workflows bleibt.
Ein unbeaufsichtigter Prozess steht vor einer anderen Einschränkung. Er kann nicht voraussetzen, dass ein erfolgreicher alternativer Versuch existiert, sofern das umgebende System Alternativen nicht tatsächlich ausführt und ihre Qualität erkennt. Wiederholte Versuche benötigen ein Auswahlverfahren, ein Ausführungsbudget und einen Umgang mit ungelösten Fehlern.
Damit ist ein Wert für gelegentlichen Erfolg ein schlechter Ersatz für eine Konsistenzmessung. Er kann zeigen, dass eine Konfiguration unter bestimmten Bedingungen Zugang zu einer Lösung hat. Er belegt nicht, dass diese Konfiguration die Lösung bei Bedarf zuverlässig liefert.
Niklaus berichtet, dass fünf Harnesses im zitierten Vergleich zwischen 32,0 % und 33,3 % der Aufgaben bei jedem Versuch lösten. Er beschreibt diese Ergebnisse als zu knapp für eine Entscheidung. Das spricht dagegen, innerhalb der führenden Gruppe präzise Siegerbehauptungen aufzustellen.
Auch den Zuverlässigkeitszahlen müssen Grenzen beigefügt werden. Drei Versuche liefern Hinweise auf Wiederholbarkeit innerhalb dieses Experiments. Sie belegen keine Produktionsfehlerrate über wechselnde Repositories, Abhängigkeiten, Berechtigungen und Nutzeranweisungen hinweg.
Ebenso führt ein Fehler in einem Benchmark nicht automatisch zu einer schädlichen Produktionsaktion. Der Evaluator misst, ob die Aufgabe ihre Erfolgskriterien erfüllt. Operative Folgen hängen davon ab, worauf der Agent zugreifen kann und welche Freigabe- oder Prüfmechanismen seine Arbeit umgeben.
Für Engineering-Manager folgt daraus, Fähigkeit von verlässlicher Lieferung zu trennen. Eine Konfiguration kann ausreichend fähig sein, gelegentlich einen korrekten Patch zu erzeugen, und dennoch für einen unbeaufsichtigten Workflow ungeeignet bleiben. Diese Lücke erfordert zusätzliche Verifikation statt eines stärkeren Marketinglabels.
Ein hypothetisches Abhängigkeitsupdate verdeutlicht den Unterschied. Ein Agent könnte das Paket in einem Durchlauf erfolgreich aktualisieren und Tests bestehen, in einem anderen jedoch eine zugehörige Konfigurationsänderung übersehen. Der gelegentliche Erfolg sagt weniger über die Bereitschaft für unbeaufsichtigten Einsatz aus, als die Schlagzeilenprozentzahl vermuten lässt.
Ein Team, das diesen Workflow bewertet, würde auf reproduzierbaren Abschluss und einen klaren Umgang mit Fehlern achten. Es würde auch darauf achten, ob die resultierende Änderung für einen Reviewer nachvollziehbar ist. Diese Dimensionen bleiben davon getrennt, ob der Benchmark-Verifizierer den Endzustand akzeptiert.
Die Ansicht der Rangliste über wiederholte Versuche bringt diese Unterscheidung in den öffentlichen Vergleich ein. Sie ermutigt Leser zu fragen, was passiert, wenn der Agent erneut arbeiten muss, statt eine erfolgreiche Trajektorie als vollständige Produktbeschreibung zu behandeln.
Benchmark-Versionen und öffentliche Aufzeichnungen begrenzen die Siegerbehauptungen
Die veröffentlichten Ergebnisse sind überprüfbare Evidenz, bleiben jedoch durch Benchmark-Versionen, Konfigurationen und die Vollständigkeit der Verifikation begrenzt.
Terminal-Bench selbst liefert ein klares Beispiel dafür, warum Versionsbezeichnungen wichtig sind. Seine Revision 2.1 behob Probleme in 28 der 89 Aufgaben der vorherigen Ausgabe. Die Maintainer berichteten nach diesen Korrekturen über Veränderungen bei den Scores repräsentativer Agenten-Modelle.
Diese Geschichte macht die Benchmark-Version zu einem Teil der Behauptung. Ein Score aus Terminal-Bench 2.0 kann nicht einfach als austauschbar mit einem aus 2.1 behandelt werden. Die Aufgaben und Evaluierungsbedingungen haben sich geändert, selbst wenn die angezeigte Metrik denselben Namen trägt.
Dasselbe Prinzip gilt für den Harness. Ein Ergebnis gehört zur getesteten Softwareversion und ihren Einstellungen. Wenn ein Update Anweisungen, Tool-Ausführung oder Beendigungsverhalten verändert, beschreibt der frühere Score die frühere Implementierung.
Das schafft eine Herausforderung für schnelllebige öffentliche Diskussionen. Ein Diagramm kann weiterverbreitet werden, nachdem sich das Board geändert hat, während Kommentare es weiterhin als aktuell behandeln. Leser benötigen die ursprüngliche Konfiguration und das Messdatum, um festzustellen, was das Bild noch belegt.
Die öffentlichen Laufaufzeichnungen des Projekts bieten einen Weg, diese Details zu prüfen. Die Verfügbarkeit der Aufzeichnungen ist ein Transparenzvorteil. Ihre Veröffentlichung bedeutet nicht, dass jedes Ergebnis bereits unabhängig reproduziert oder vollständig manuell überprüft wurde.
Eine unabhängige Reproduktion würde erfordern, die angegebenen Konfigurationen auszuführen und zu prüfen, ob die relevanten Muster bestehen bleiben. Das Lesen der Aufzeichnungen kann ein Audit der berichteten Berechnungen oder einzelner Verhaltensweisen unterstützen. Diese Aktivitäten liefern unterschiedliche Arten von Evidenz.
Die Kausalfrage bleibt besonders anspruchsvoll. Ein Score-Unterschied kann unter kontrollierten Bedingungen eine Assoziation zwischen Konfiguration und Ergebnis identifizieren. Die Erklärung des Unterschieds erfordert die Untersuchung von Fehlern und Tests dazu, ob eine vorgeschlagene Änderung diese verändert.
Ein vermutetes Timeout-Problem sollte beispielsweise geprüft werden, indem das Timeout geändert wird und andere relevante Bedingungen erhalten bleiben. Ein vermutetes Informationsverlustproblem erfordert die Untersuchung, welche Informationen verloren gingen und ob ihr Erhalt die Ergebnisse verbessert. Keine der beiden Erklärungen folgt automatisch aus einem niedrigen Rang.
Benchmark-Vertrautheit bringt eine weitere Untersuchungsperspektive mit sich, ohne Fehlverhalten zu unterstellen. Ein auf öffentliche Aufgaben optimiertes System kann sich auf dieser Aufgabenverteilung verbessern, ohne sich andernorts gleichermaßen zu verbessern. Evidenz aus unbekannten Aufgaben würde helfen zu klären, wie breit sich der Gewinn übertragen lässt.
Die Aufgabenabdeckung stellt eine separate Einschränkung dar. Repository-Wartung umfasst organisatorische Konventionen, mehrdeutige Anfragen und Erwartungen menschlicher Reviewer, die ein fester Benchmark nicht vollständig erfassen kann. Ein Benchmark kann dennoch nützlich sein und diese Bereitstellungsfragen offenlassen.
Die praktische Reaktion besteht darin, die Evidenz dem Umfang der Entscheidung angemessen zu halten. Ein öffentliches Ergebnis kann eine Shortlist oder einen gezielten Test rechtfertigen. Die Entwicklungsabläufe eines Teams zu ersetzen erfordert zusätzliche Evidenz aus Arbeit, die den tatsächlichen Verantwortlichkeiten dieses Teams ähnelt.
Wenn Konfigurationen, Fehlerbeispiele und Review-Entscheidungen gemeinsam festgehalten werden, lassen sich diese Vergleiche leichter erneut prüfen. Eine durchsuchbare Wissensdatenbank kann helfen, diesen Evaluierungsverlauf neben den während der Tests genutzten technischen Dokumenten zu bewahren.
Die Verifikationslücke hebt den Wert des Experiments nicht auf. Sie definiert, was die Ergebnisse derzeit stützen und welche zusätzliche Arbeit sie stärken würde. Das ist eine nützlichere Lesart, als entweder jeden Rang wörtlich zu akzeptieren oder den Vergleich vollständig abzutun.
Die nächsten Tests sollten Updates, Reproduktion und unbeaufsichtigte Arbeit verfolgen
Die stärkste Folgeevidenz wird Versionsänderungen mit reproduzierbaren Verbesserungen bei Arbeit außerhalb des ursprünglichen Vergleichs verbinden.
Das erste zu beobachtende Signal ist aktualisierte Harness-Leistung mit klarer Versionshistorie. Wenn ein Entwickler die Ausführungssoftware verändert, kann ein vergleichbarer erneuter Durchlauf zeigen, ob sich Genauigkeit, Effizienz oder Konsistenz ändern. Die frühere Konfiguration zu bewahren, macht diesen Vergleich aussagekräftig.
Eine Verbesserung über wiederholte Messungen hinweg würde die Annahme stärken, dass Harness-Engineering die Ergebnisse wesentlich beeinflusst. Ein Ergebnis, das bei vergleichbaren Wiederholungen verschwindet, würde das Vertrauen in den behaupteten Gewinn schwächen. Beide Ergebnisse liefern mehr Information als ein aktualisiertes Siegerabzeichen.
Dies bietet auch Anbietern eine konstruktive Reaktionsmöglichkeit. Sie können ein Fehlermuster benennen, die relevante Implementierungsänderung erklären und Evidenz zum Ergebnis veröffentlichen. Leser können dann eine konkrete Engineering-Behauptung bewerten, statt Qualität aus dem Ruf eines Produkts abzuleiten.
Das zweite Signal ist unabhängige Reproduktion mit übereinstimmenden Kontrollen. Ein separater Evaluator sollte das Modell, die Anbieterbedingungen, Reasoning-Einstellungen, Aufgabenversion und Harness-Version dokumentieren. Unterschiede müssen sichtbar bleiben, statt in einem scheinbar identischen Score aufzugehen.
Wenn unabhängige Ergebnisse die grobe Reihenfolge oder modellspezifische Muster bewahren, steigt das Vertrauen in den Vergleich. Wenn Ergebnisse auseinanderlaufen, weist das auf Bedingungen hin, die genauer untersucht werden müssen. Anbieterverhalten, Ausführungseinstellungen und Messdetails werden dann zu Forschungsfragen statt zu bequemen Erklärungen.
Reproduktion erfordert nicht, dass jede Zahl exakt übereinstimmt. Entscheidend ist, ob die Schlussfolgerung einer angemessenen wiederholten Messung standhält. Nahe Ergebnisse sollten nahe bleiben, sofern zusätzliche Evidenz ihre Unterscheidung nicht stützt.
Das dritte Signal ist Leistung bei unbekannter Arbeit mit expliziten Kriterien für unbeaufsichtigten Erfolg. Das bedeutet zu prüfen, ob der Agent die angeforderte Aufgabe abschließt, das Ergebnis verifiziert und angemessen mit Fehlern umgeht. Menschliche Eingriffe sollten dokumentiert werden, weil sie verändern, was „autonomer Abschluss“ bedeutet.
Konsistente Verbesserungen bei dieser Arbeit würden die praktische Bedeutung der Erkenntnisse der Rangliste stärken. Gewinne, die auf vertraute Benchmark-Aufgaben beschränkt bleiben, würden ihre Relevanz einengen. Für die Bereitstellung ist diese Unterscheidung wichtiger als eine weitere kleine Bewegung in einem Gesamtdurchschnitt.
Für Teams, die jetzt Software auswählen, stützt die Evidenz einen Vergleich auf Ebene der tatsächlichen Kombination. Kimi Code, Hermes Agent, Pi, Claude Code, Codex und mini-swe-agent verdienen eine Bewertung in den Konfigurationen, die ein Team einsetzen will. Ihre Namen allein können das Ergebnis nicht entscheiden.
Die Niklaus-Harness-Rangliste liefert für diese Bewertung einen öffentlichen Ausgangspunkt – mit Startresultaten, wiederholten Versuchen und zugänglichen Aufzeichnungen. Ihr nachhaltiger Beitrag wird davon abhängen, ob diese Messungen helfen, Agentenverhalten zu erklären und zu verbessern.
Bevor Sie Ihren Coding-Workflow ändern, vergleichen Sie eine vorausgewählte Kombination mit dem Setup, dem Sie bereits vertrauen, anhand repräsentativer Wartungsarbeit. Halten Sie die exakte Konfiguration, Abschlussnachweise, Review-Aufwand und Fehler fest, die Eingriffe erfordern. Beziehen Sie Aufgaben ein, bei denen ein plausibler Patch ohne einen erfolgreichen Verifikationsschritt nicht ausreicht. Wiederholen Sie den Vergleich nach einem wesentlichen Harness-Update und bewahren Sie die früheren Ergebnisse, damit Veränderungen nachvollziehbar bleiben. Behandeln Sie das öffentliche Board als Evidenz für diese Entscheidung, während Ihr eigener Workflow das letzte Wort behält. Die entscheidende Frage ist konkret: Welche getestete Kombination liefert Arbeit, die Ihr Team mit der Aufsicht, die Sie tatsächlich leisten können, verifizieren, wiederholen und akzeptieren kann?
