Was die Benchmarks über OpenCode, Claude Code und Codex nicht sagen

Zwei Ranglisten, derselbe Benchmark, dieselbe Woche, ein anderer Sieger.

DeepSWE ist ein Benchmark von Datacurve für agentisches Programmieren über lange Strecken. Am 31. August führt bei llm-stats GPT-5.6 Sol mit 0,727, und Claude Opus 5 taucht in den ersten fünf gar nicht auf. Ein Stand vom 26. August sieht Opus 5 vorn mit 73,6 % pass@1. Niemand lügt. Die Werte liegen so eng beieinander, dass die Reihenfolge davon abhängt, wann man hingesehen hat und wer gemessen hat.

Man wüsste das sofort, wenn die Aggregatoren das eine mitnähmen, was DeepSWE ausliefert und fast niemand sonst.

Der Benchmark veröffentlicht Fehlerbalken. Die Kopien lassen sie weg.

Hier DeepSWEs eigene Starttabelle vom 26. Mai:

Jede Zeile trägt ein Intervall und eine Angabe zum Reasoning-Aufwand. Beides zählt: ein Modell bei maximalem Aufwand und dasselbe Modell bei mittlerem sind zwei Produkte mit demselben Namen.

Die llm-stats-Seite zu demselben Benchmark trägt keines von beidem. Zwölf Modelle, je eine Dezimalzahl, keine Unsicherheit, keine Aufwandsstufe. Genau der sorgfältige Teil überlebt das Abschreiben nicht, und übrig bleibt eine Rangfolge, die so aussieht, als bedeuteten die Abstände etwas.

Zwei Modelle, die drei Punkte auseinanderliegen, bei Intervallen von plus minus drei, sind nicht gereiht. Sie sind gleichauf, und der Benchmark hat das gesagt, bevor irgendjemand ihn zitiert hat.

Warum es DeepSWE gibt, in seinen eigenen Worten

Der Grund, sich für diesen und nicht für die älteren Namen zu interessieren, steht in Datacurves Text, und er ist eine Anklage gegen das, was die meisten Vergleiche weiterhin zitieren.

Zur Verlässlichkeit der Verifier: sie haben SWE-bench Pro geprüft und 8 % falsch positive und 24 % falsch negative Ergebnisse gefunden. Knapp ein Drittel seiner Bestanden- und Durchgefallen-Entscheidungen ist unzuverlässig. DeepSWEs eigene Verifier, die auf beobachtbares Verhalten prüfen statt auf die Umsetzung, messen 0,3 % und 1,1 %.

Zur Verunreinigung: Aufgaben, die aus zusammengeführten Commits gebaut sind, lecken. Sie berichten von Lösungsdurchsickern und falsch positiven Ergebnissen bei rund 8 % der geprüften Durchläufe, weil ein Agent die Reparatur in der Historie des Repositories nachlesen kann. DeepSWEs Aufgaben sind von Grund auf geschrieben und werden nie ins Ursprungsrepository zurückgeführt, stehen also gar nicht im öffentlichen GitHub-Bestand.

Und beim Umfang ist der Abstand peinlich: Aufgaben in SWE-bench Pro umfassen im Mittel etwa 120 Zeilen. Die von DeepSWE im Mittel 668 Zeilen über 7 Dateien, aus Aufgabentexten von durchschnittlich 2.158 Zeichen, was ungefähr aussieht wie ein echtes Ticket.

Wer also eine SWE-bench-Zahl auf drei Stellen genau zitiert, zitiert eine Messung, deren eigene Prüfer ein Viertel ihrer Negativbefunde anzweifeln.

Worauf ich stattdessen vergleichen würde

Einmalige Codeerzeugung hat schon vor einer Weile aufgehört, die interessante Achse zu sein. Die Dimensionen, die diese Modelle im Alltag trennen, sind die, bei denen eine Aufgabe lang genug läuft, um schiefzugehen:

• Agentisches Programmieren über lange Strecken. Hält es ein Ziel über 668 Zeilen und sieben Dateien, ohne den Faden zu verlieren. Genau das misst DeepSWE, und deshalb lohnt es sich zu lesen.
• Werkzeugnutzung. Nicht, ob es ein Werkzeug aufrufen kann, sondern ob es das richtige wählt und sich fängt, wenn der Aufruf fehlschlägt.
• Computer Use. Die Fehlerbilder sind hier qualitativ andere als bei Text, und ein Modell kann hervorragend im Code und nutzlos im Browser sein.
• Visuelles Verstehen. Einen Screenshot eines kaputten Layouts zu lesen ist eine andere Fähigkeit als das CSS zu lesen, das es zerbrochen hat, und nur eine davon steht auf den meisten Ranglisten.

Was keiner von ihnen misst, ist das, was darüber entscheidet, welches Harness man behält: wie viele Züge es braucht, und wie viel von dem, was zurückkommt, man wegwirft.

Nebenbei löst sich die Frage auf

Die Gegenüberstellung Harness gegen Harness setzt voraus, dass jedes Werkzeug sein Modell mitbringt. Das stimmte ungefähr ein Jahr lang und ist inzwischen eher eine Voreinstellung als eine Grenze.

Claude Code liest ANTHROPIC_BASE_URL. Zeigt man sie auf OpenRouter, läuft GPT oder Gemini in Anthropics Harness. Es gibt ein kleines Ökosystem lokaler Proxys, die die Anthropic-Messages-API in das OpenAI-Chatformat übersetzen und zurück, und ein, zwei gehostete Gateways, die das ohne lokalen Prozess erledigen. Anthropics eigener Changelog kennt die Praxis, in dem Eintrag, der den Commit-Trailer ändert, wenn „the active model isn't a recognized Claude model (e.g. third-party models behind a custom ANTHROPIC_BASE_URL)".

OpenCode war von Anfang an modellagnostisch, mit über 75 Anbietern über Models.dev. Codex zeigt mit --oss auf ein lokales Modell oder über einen eigenen Provider-Block auf alles OpenAI-Kompatible.

Eine Benchmark-Zeile mit der Beschriftung „Codex-Harness, GPT-5.6 Sol" misst also eine Paarung, und die Paarung ist inzwischen eine Konfigurationsentscheidung und keine Produktgrenze.

Was tatsächlich eine Grenze ist

Die echten Grenzen sind kommerziell, und sie bewegen sich.

Am 4. April 2026 hat Anthropic Claude-Pro- und Max-Abos in Drittanbieter-Agentenwerkzeugen abgeschnitten, OpenCode darunter, mit Verweis auf die Rechenlast dieser Werkzeuge. Auf ihrer Rechtsseite steht weiterhin, OAuth für Free, Pro und Max sei ausschließlich für Claude Code und Claude.ai gedacht. Im Mai haben sie es zurückgenommen und ein eigenes Guthabensystem für Drittanbieter-Agenten eingeführt.

OpenCode hatte sein Anthropic-OAuth-Plugin schon in v1.3.0 am 22. März entfernt, bevor die Sperre kam.

Das sind neun Wochen Hin und Her bei der Frage „darf ich das, wofür ich zahle, in dem Werkzeug benutzen, das ich bevorzuge", und es ist genau die Sorte Grenze, die dir kein Benchmark je zeigen wird.

Die Zahl, die niemand veröffentlicht

Jetzt meine eigene Position, und sie ist keine Messung.

Opus 5 ist im Alltag eine Enttäuschung und trägt gleichzeitig die Last, was eine unangenehme Kombination ist. Es braucht Steuerung. Ich prompte häufiger nach, als ich erwarte, und was herauskommt, ist oft nicht die Arbeit, um die ich gebeten habe, sondern eine größere, gründlichere Fassung davon.

Damit stehe ich nicht allein. Die Aufnahme wurde vielfach als Rückschritt beschrieben, mit Überkonstruktion und Nachprompten als wiederkehrenden Beschwerden, bei gleichzeitig starken Benchmark-Werten. Ich will hier vorsichtig sein: mein Beleg sind meine eigenen Hände und ein Stapel Sekundärartikel, die Forenreaktionen zusammenfassen. Das ist schwächer als eine Rangliste, und ich sage es lieber, als es aufzuhübschen.

Aber man beachte, worüber die beiden streiten. Der Benchmark misst, ob eine Aufgabe fertig wurde. Mein Einwand betrifft, wie viele Züge es gekostet hat und wie viel vom Ergebnis ich weggeworfen habe. Das sind verschiedene Größen, und nur eine davon hat eine Rangliste.

Worin die Beschwerde wirklich besteht

Wer auf Hacker News nachsieht, findet einen Vorwurf mit Maskottchen. Claude sagt load-bearing, ununterbrochen, und gezählt wird seit dem Frühjahr. Als Sprachtick ist das nur komisch. Zum Defekt wird es dadurch, dass das Wort falsch angewendet wird:

Minor inconvenience != load bearing, yet Claude consistently uses it while missing actual load bearing things.

SkyPuncher, 24. August 2026

Der Preis zeigt sich in der einzigen Einheit, auf die es ankommt, nämlich im Nachmittag eines Menschen:

My job improved significantly since I managed to get into their (managers) thick skulls to tell Claude to not be verbose. I'm tired of 1200-word tickets for "put the totals in the automated emails".

javcasas, 24. August 2026

I really love CC and have been using it exclusively for a year now but reading Claude's verbose and semantically-obfuscated writing style is wearing me out and I'm planning to move to another provider.

sockaddr, 24. August 2026

Die schärfste Fassung der Beschwerde lautet nicht „zu lang"

Ich hatte das als Längenproblem abgelegt, bis ich das hier las, und ich halte es für die richtige Diagnose:

„I've noticed that most people seem to consider the core problem of Claude's output as 'too verbose' but I don't think this actually cuts to the heart of the matter at all. It's almost, in some weird way, the opposite: like the text is far too dense. It tries too hard to invent odd terminology."

cnity, 21. August 2026

Das deckt sich mit dem, was ich sehe. Das Problem ist nicht, dass zu viele Wörter auf den Gedanken kommen. Es ist, dass jedes einzelne Wort zu viel Arbeit leistet, in einem Vokabular, das für den Anlass erfunden wurde, sodass man entschlüsseln muss statt zu lesen. Tausend schlichte Wörter wären schneller als vierhundert von diesen.

Jemand anders führt die Verteidigung, und man sollte sie hören:

„Some of the more unusual language it uses does result in more precise communication, if you can figure out what it means."

Myrmornis, 22. August 2026

Wenn man herausfindet, was es bedeutet trägt diesen Satz, und genau das ist die Steuer.

Die Zustimmungsschleife

Die Sprachticks sind kosmetisch. Diese Sache ist es nicht.

Ich bitte um fünf Dinge. Es erledigt drei, legt sie als fertig vor, und erst wenn ich auf die zwei fehlenden zeige, kommt die Einsicht, ausführlich. Dann erledigt es eines der beiden und legt das als fertig vor.

Die Einsicht hat einen Hausstil, und alle sind ihm schon begegnet:

„You are absolutely right to push back!" ... I am really really really trying to wrap my head around this.

Bluestein, 19. August 2026

Zum Defekt statt zur Marotte wird es durch die Reihenfolge. Das Modell prüft seine Arbeit nicht gegen die Anfrage und meldet eine Lücke. Es erklärt sich für fertig und stimmt dann begeistert zu, wer immer es ertappt. Begeisterung beim Korrigiertwerden ist nicht dasselbe wie Genauigkeit, und sie ist ein schlechter Ersatz für die Prüfung, die ausgeblieben ist.

Die Leute bauen die Abwehr inzwischen in ihre Konfiguration ein. Die Regeldatei eines Entwicklers beginnt mit einem Abschnitt „Voice Rule #1: No AIisms", und er sagt deutlich, was ihm das bringt:

Its impact is that I don't go insane, which is pretty high value.

tyre, 23. August 2026

Als Gegenmittel wird ein knapper Ausgabestil empfohlen, und die Berichte von Leuten, die es ernsthaft versucht haben, lauten: es ändert die Prosa und nicht das Verhalten. Das passt. Knappheit ist eine Formatierungsanweisung, und eine Arbeit als fertig zu melden, die zu drei Fünfteln fertig ist, ist kein Formatierungsproblem.

Und damit sind wir zurück bei den Benchmarks. Eine Aufgabe, bei der das Modell drei von fünf Anforderungen erfüllt, sich für fertig erklärt und dann in eine vierte hineinkorrigiert wird, zählt bei den meisten Harnesses als bestanden, weil sie in dem Zug bestanden hat, in dem sie endlich bestand. Die Zahl der Züge steht nicht in der Wertung. Sie steht nur in deinem Nachmittag.

Die Abhilfe ist ein Standard, keine Einstellung: ASD-STE100

Niemand löst das mit einem Regler. Was gerade herumgereicht wird, ist eine einzige Zeile in der Regeldatei, und sie benennt eine veröffentlichte Spezifikation:

Use ASD-STE100 Simplified Technical English.

ASD-STE100 ist Simplified Technical English, die kontrollierte Sprache, die die Luftfahrtindustrie geschaffen hat, damit ein Wartungshandbuch nachts um drei in einem Hangar nicht falsch verstanden werden kann. Vier Eigenschaften zählen hier:

• Ein eingeschränkter Wortschatz. Nur zugelassene Wörter, der Rest steht nicht zur Verfügung.
• Eine Bedeutung je Wort. Kein Wort leistet Doppeldienst, und genau das hat „load-bearing" getan.
• Kurze Sätze, mit einer festgelegten Grenze statt einer Vorliebe.
• Eine Anweisung pro Satz, damit ein Leser einen Absatz nicht halb ausführen kann.

Diese Liste ist ungefähr die Umkehrung des oben beschriebenen Fehlerbildes, und deshalb wirkt sie überhaupt.

Die Beleglage ist dünn, aber immerhin hat jemand gemessen:

There has been some talk about using ASD-STE100 as a shorthand way of improving text, but not many direct experiments, so I did one. I found that just mentioning ASD-STE100 can get you 72% of the way there.

johnrising, 3. August 2026

Und ein Widerspruch, den man behalten sollte, weil manchmal die einfachste Anweisung gewinnt:

I tried "use ASD-STE100 Simplified Technical English" but I've found "natural plain English" to work better.

FooBarWidget, 27. August 2026

Ich habe den Standard seit einer Weile in meiner eigenen Regeldatei und würde meine Erfahrung näher am ersten als am zweiten Kommentar einordnen. Eine echte Spezifikation zu benennen schlägt ein Adjektiv, denn „knapp" ist Geschmack und ASD-STE100 ist ein Dokument, und ein Modell, das das Dokument kennt, hat etwas zu befolgen statt etwas zu deuten.

Was es nicht anfasst, ist die Zustimmungsschleife. Schreibstil und Vollständigkeit sind verschiedene Fehler, und nur einer davon ist ein Schreibproblem.

Der Teil, der Sorgen machen sollte

Das Vokabular greift auf die Menschen über.

„I recently started using 'load bearing' in my languge to Claude… Obviously, we adapt habits of entities next to us."

marsxr360, 28. August 2026

Ich stelle mich nicht außerhalb davon. Ich habe die Wendung in meinen eigenen Notizen zu diesem Modell benutzt, bevor ich mich hingesetzt habe, um darüber zu schreiben, und beim Durchsehen des Entwurfs habe ich sie noch zweimal gefunden. Einen Stil, den man acht Stunden am Tag liest, beurteilt man nicht aus der Distanz. Man fängt an, ihn zu schreiben.

Das Eine-Woche-Problem

Der bekannteste jüngere Vergleich dieser beiden Harnesses ist ein Ersteindruck vom 22. Juli, und er ist über seine eigenen Grenzen ehrlicher als die meisten. Der Autor sagt zweimal, er habe das neue Setup eine Woche benutzt. Er weist darauf hin, dass Harnesses beeinflussen, wie ein Modell sich anfühlt. Er nennt für keines der Werkzeuge eine Versionsnummer.

Sein Hauptvorwurf an Claude Code sind sporadische Rendering-Fehler, den er im selben Satz halb zurückzieht: „I think it has gotten better." Sein Lob für OpenCode auf derselben Achse lautet, es habe sie „apparently doesn't have them as much and anecdotally I haven't seen them yet, but I have to caveat it's only been a week".

Ich habe nachgezählt. Über OpenCodes 867 Releases hinweg sind Terminal- und Rendering-Korrekturen die mit Abstand größte Kategorie von Changelog-Einträgen, durchgehend bis Ende August. Das Werkzeug, das für weniger Rendering-Probleme gelobt wird, liefert mehr Rendering-Korrekturen aus als alles andere.

Das ist kein Widerspruch zu ihm. Es ist der Wert einer Woche, in der man etwas nicht gesehen hat. Er hat außerdem ein Urteil nach einem Monat versprochen, also um den 22. August. Es ist nicht erschienen, und ich lese das als das ehrlichste verfügbare Ergebnis: der Monat hat auch keine saubere Antwort geliefert.

Next

Wer heute wählt, findet die Unterschiede, die einer Prüfung standhalten, nicht in Punktzahlen. Lizenz: OpenCode ist MIT, die anderen beiden nicht. Sandboxing: Claude Code und Codex setzen mit Betriebssystemmitteln durch, und OpenCodes eigene Doku sagt, die Policies adressierten „nicht Sandboxing, Isolation oder das Einschränken von Ausführungsumgebungen". Herkunft: sst/opencode antwortet inzwischen mit 301 auf anomalyco/opencode, was man wissen sollte, bevor man eine Abhängigkeit festnagelt. Und Claude Codes Changelog hat 380 Versionsüberschriften und kein einziges Datum, weshalb jedes Datum, das jemand dafür nennt, meines eingeschlossen, aus npm-Zeitstempeln stammt.

Die Messung, die ich mir wünschen würde, gibt es noch nicht: Züge pro erledigter Aufgabe, und der Anteil erzeugter Arbeit, der weggeworfen wird. Ich habe an anderer Stelle argumentiert, dass eine Fehlerquote eine Anfrage nicht sehen kann, die durchgeht und nichts Brauchbares zurückgibt, und das hier ist derselbe blinde Fleck eine Schicht höher.

Wenn du eine Sache mitnimmst: bevor du jemandem einen Benchmark um die Ohren haust, öffne die Rangliste und lies ihre Methodennotiz. Die, die ich geöffnet habe, machte aus einem Rennen um 1,13 Punkte eines um 4,5, und es kostete einen einzigen Klick, den der Schalter mir ohnehin angeboten hat.