GPT-6.1 Sol bei COBOL: 86,6 % gegenüber 5,4 %, und nur einer der beiden Tests kann erneut ausgeführt werden

Am 19. Oktober 2026 veröffentlichte OpenAI zwei Programmier-Evaluierungen für ressourcenarme Sprachen, und die Schlagzeilenzahl gehört zu GPT-6.1 Sol: 86,6 % der COBOL-Migrationsaufgaben wurden bei geringem Reasoning-Aufwand bestanden, gegenüber 5,4 % für GPT-5.6 Sol bei derselben Einstellung; bei erhöhtem Aufwand steigt der Wert auf 97,9 %. Die zweite Evaluierung, MultiLangBench, ist die Geschichte eines anderen Modells – GPT-6 Astra erzielte bei maximalem Aufwand über zwanzig Sprachen hinweg durchschnittlich 87,4 % –, aber sie ist die nützlichere Hälfte der Veröffentlichung, weil OpenAI sein Harness unter Apache-2.0 auf GitHub veröffentlicht hat und Sie es heute Nachmittag selbst ausführen können. Die COBOL-Migrations-Evaluierung, die mit den 86,6 %, ist eine andere Sache: Ihre Tests sind verborgen, ihr Bestehenskriterium ist die Byte-für-Byte-Übereinstimmung der Ausgabe mit Fällen, die niemand außerhalb von OpenAI gesehen hat, und kein Dritter hat sie reproduziert. Diese Asymmetrie ist die ganze Geschichte, und es lohnt sich, sie klar zu benennen, bevor eine der beiden Zahlen in einem Migrations-Business-Case zitiert wird. Die dokumentierten KI-Ausfälle und Agenten-Vorfälle hinter Veröffentlichungen wie dieser werden in dem OrcaRouter AI Incident Archive gesammelt, wo jeder Eintrag seine eigenen Quellen, Schweregrad, Konfidenzstufe und Kennzeichnung als umstritten enthält.

Ein Datum, das man richtig einordnen sollte. GPT-6.1 Sol selbst stammt vom 29. September 2026 — das ist kein Launch, und nichts hier ändert die Gewichte, den Preis oder die Preisliste des Modells. Was am 19. Oktober geschah, ist, dass OpenAI Belege dafür veröffentlichte, wozu das Modell in einer Kategorie fähig ist, die es zuvor nicht dokumentiert hatte, und einen Benchmark bereitstellte, den jeder erneut laufen lassen kann. Das ist das Ereignis, um das es in diesem Beitrag geht.

Was tatsächlich veröffentlicht wurde und wofür jede Hälfte gedacht ist

Die beiden Evaluierungen beantworten unterschiedliche Fragen, und die eigene Einordnung von OpenAI trennt sie. MultiLangBench fragt, ob ein Modell bauen kann, und zwar etwas in einer Sprache, auf die niemand trainiert: SQLite 3.40.1 von Grund auf in einer von zwanzig Programmiersprachen implementieren und dann eine Datenbank-Konformitätssuite bestehen. Die COBOL-Migrationsevaluierung fragt, ob ein Modell etwas migrieren kann: COBOL-Programme nach C++, Java, Kotlin, Python oder Rust übersetzen und dabei beobachtbares Verhalten exakt erhalten.

Der erste ist ein Test der Mindestleistungsfähigkeit. Der zweite ist der, der Unternehmen tatsächlich interessiert, denn COBOL ist keine Benchmark-Kuriosität — IBMs seit Langem bestehende Schätzungen gehen davon aus, dass COBOL hinter mehr als 40 % der Online-Banking-Systeme und rund 95 % der Geldautomaten-Transaktionen steckt, und der Code wird von einer Belegschaft gepflegt, die nicht ersetzt wird.

• MultiLangBench, maximaler Aufwand — GPT-6 Astra 87,4 %, GPT-6 Luna 40,3 %, GPT-5.6 Sol 26,8 %. Astra erreichte in 19 von 20 Sprachen über 83 %; COBOL war mit 72,1 % sein schwächster Wert gegenüber 10,9 % bei GPT-5.6 Sol, was zeigt, dass die schwierigste Sprache im Set noch immer die mit dem ältesten Tooling ist.

• COBOL-Migration, geringer Aufwand — GPT-6.1 Sol 86,6 %, GPT-5.6 Sol 5,4 %, bei geschätzten 61 % der API-Kosten des älteren Modells für den Evaluierungslauf, oder 39 % weniger.

• COBOL-Migration, höherer Aufwand — GPT-6.1 Sol 97,9 %, was O​penAI als nahe an der Sättigung beschreibt.

• Details je Sprache, die O​penAI tatsächlich veröffentlicht hat — Fortran 83,5 % für Astra gegenüber 21,4 % für GPT-5.6 Sol; Visual Basic 89,4 % gegenüber 27,5 %; OCaml 85,8 % gegenüber 25,6 %; GPT-6 Luna bei 17,1 % auf COBOL, 31,4 % auf Fortran, 34,1 % auf OCaml und 41,6 % auf Visual Basic.

• Kosten pro Stichprobe auf MultiLangBench — geschätzte 0,77 US-Dollar für GPT-6 Luna gegenüber 3,48 US-Dollar für GPT-5.6 Sol, rund 78 % niedriger – und genau diese Zahl macht das schwächste Modell im Feld für eine Build-Generierungs-Pipeline interessant.

Die Evaluation, die du erneut ausführen kannst: Was MultiLangBench tatsächlich verlangt

Das Repository ist github.com/openai/MultiLangBench, Apache-2.0, und das Lesen des Harness ist informativer als das Lesen der Bestenliste. Die Aufgabe ist so spezifisch, dass ein Modell sie nicht vortäuschen kann: Erzeuge ein ausführbares Programm, das einen Datenbankpfad als Befehlszeilenargument entgegennimmt, eine SQL-Abfrage aus stdin einliest und sich wie SQLite 3.40.1 verhält. Die Tests stammen aus SQLites eigener TCL-Suite – insgesamt etwa 51.000 Tests, von denen ungefähr 24.000 in die Tripel umgewandelt wurden, die das Harness verwendet: eine Ausgangsdatenbank, eine Benutzerabfrage und eine Validierungsabfrage. Die Testnamen sind SHA-256-Hashes dieser Komponenten, sodass die Suite nicht anhand der Namen auswendig gelernt werden kann.

Die Regeln sind der Ort, an dem die Schwierigkeit liegt, und jede einzelne versperrt eine Abkürzung:

• Kein Internet und nirgendwo in der Umgebung SQLite. Die Testumgebung gibt vor, zuerst jede Spur von SQLite zu entfernen. Ein Modell kann die echte Engine nicht per Shell aufrufen und auch keine Implementierung abrufen.

• Die Validierung erfolgt gegen echtes SQLite 3.40.1. Ihre Implementierung verändert die Datenbank; das Harness extrahiert sie und prüft sie mit dem echten Original. Ungefähres Verhalten schlägt fehl.

• Sechzig Sekunden pro Test, und eine Antwort in der falschen Sprache zählt null. Das Mischen von Sprachen schlägt fehl, und die Prüfumgebung weist darauf hin, dass ein anderes Modell eingesetzt werden kann, um zu prüfen, in welcher Sprache du tatsächlich geschrieben hast. Diese letzte Regel existiert, weil der offensichtliche Betrug – es in Python zu schreiben und zu verpacken – das Erste ist, was ein leistungsfähiges Modell versucht.

• Der schnelle Lauf umfasst 272 Tests, nicht 24.000. Die README empfiehlt, nur die Tests auszuführen, deren Namen mit 00, 01 oder 02 beginnen, wenn Sie eine vergleichbare Zahl wünschen. Das ist das Detail, das Sie beachten sollten, bevor Sie Ihr eigenes Ergebnis mit dem von OpenAI vergleichen: Ein Lauf über die vollständige Suite und ein schneller Lauf sind nicht dieselbe Messung, und die README sagt das auch.

Das ist ein echter, nachprüfbarer Benchmark. Er verrät Ihnen außerdem etwas, das die Presseberichterstattung nicht tat: Der 87,4-%-Wert aus der Schlagzeile wurde auf einer Testsuite gemessen, mit der Sie Ihr eigenes Modell prüfen können – selten genug, um den Download wert zu sein.

Die Evaluierung, die man nicht erneut ausführen kann – und warum das nicht automatisch ein Skandal ist.

Die COBOL-Migrationsbewertung wurde von OpenAI entworfen, von OpenAI durchgeführt und von OpenAI bewertet, und ihre Testfälle sind nicht veröffentlicht. Die Bestehensgrenze ist präzise angegeben — eine Migration zählt nur, wenn jeder versteckte Test eine byte-für-Byte identische beobachtbare Ausgabe erzeugt — und genau diese Präzision macht das Ergebnis von außen nicht überprüfbar: Die 86,6 % sind OpenAIs Messung anhand von OpenAIs eigenen versteckten Fällen. Nur eine der beiden Bewertungen in der Veröffentlichung ist etwas, das ein Leser reproduzieren kann.

Das Zurückhalten von Migrationstests ist nicht unvertretbar. Das Korpus stammt vermutlich aus echten Legacy-Programmen, und seine Veröffentlichung kann Kundencode preisgeben oder zukünftigen Modellen einen Trainingsdatensatz liefern. Byte-für-Byte-Parität ist zudem ein wirklich konservatives Kriterium, strenger als die meisten Anbieter-Evaluierungen: Es belohnt keine Übersetzung, die bloß annähernd richtig ist.

Aber das Kriterium ist auch der Punkt, an dem die praktischen Schwierigkeiten beginnen, und die Vorbehalte von OpenAI selbst deuten genau darauf hin. Migrationsergebnisse müssen vor dem Produktivbetrieb weiterhin von Fachleuten geprüft und gegen Geschäftsregeln und Systemabhängigkeiten getestet werden. Und Byte-Parität ist genau dort schwierig, wo COBOL schwierig ist: Die Sprache schneidet Festkommaarithmetik ab und rundet sie auf eine Weise, wie es die meisten Zielsprachen nicht tun, sodass eine Übersetzung korrekt aussehen, eine Suite bestehen kann, die „nah genug“ prüft, und trotzdem einen Saldo um einen Cent verschieben kann. Eine versteckte Suite, die exakte Gleichheit verlangt, fängt das ab; Ihr eigener Prüfprozess muss das ebenfalls abfangen, denn die Bewertung des Modells ist keine Aussage über Ihre Programme.

Die Kostenangabe verlangt dieselbe Sorgfalt. Die Einsparung von 39 % ist eine Schätzung für den Evaluierungsdurchlauf – Tokens, die in das Benchmark hinein- und aus ihm herausgehen –, nicht die Kosten für die Ablösung eines Produktionssystems, die von Discovery, Expertenprüfung, Integrationstests und den Jahren nicht dokumentierten Verhaltens geprägt sind, die keine Evaluierung erfasst.

Was sollten 86,6 % und 97,9 % an einer Entscheidung ändern?

Die ehrliche Lesart ist enger als die Schlagzeilen und nützlicher als diese. Ein Basiswert von 5,4 % ist kein Modell, das halb funktioniert; es ist ein Modell, das fast nie eine verhaltenserhaltende Übersetzung erzeugt, sodass die ältere Generation für diese Arbeit nie in Frage kam. GPT-6.1 Sol liegt mit 86,6 % in dem Bereich, in dem sich die Wirtschaftlichkeit umkehrt: Ein Werkzeug, das den Großteil einer Übersetzung entwirft und die Prüfung einem Reviewer überlässt, ist ein anderes Produkt als eines, das nichts Brauchbares liefert.

Die 97,9 % bei höherem Aufwand sind die Zahl, bei der Skepsis angebracht ist – nicht weil sie falsch wäre, sondern weil sie gesättigt ist. Sobald ein Benchmark nahe seiner Obergrenze liegt, unterscheidet er nicht mehr zwischen Modellen, sondern misst nur noch die Testsuite, und OpenAI sagt das selbst. Für die Planung sollten Sie 86,6 % bei geringem Aufwand als den günstigen Betriebspunkt betrachten und 97,9 % als die Obergrenze dessen, was die Evaluierung Ihnen zeigen kann – nicht als Genauigkeitsversprechen für Ihre Codebasis.

Es gibt außerdem eine Gegenprüfung, die sich lohnt, und sie spricht gegen den Hype. Im Build-Test blieb COBOL mit 72,1 % die schwächste Sprache von GPT-6 Astra, obwohl Astra mit durchschnittlich 87,4 % insgesamt das stärkere Modell ist. Die Sprache ist in beide Richtungen anspruchsvoll. Ein Modell, das COBOL in einer verdeckten Evaluierung gut migriert, ist deshalb noch nicht gut in COBOL; es ist gut in dem Muster, das die Evaluierung beprobt.

Das andere, was diese Woche passiert ist: die Behauptung zum Reasoning-Trace.

Ein am 21. Oktober weithin geteilter Beitrag behauptete, die Reasoning-Traces von GPT-6.1 Sol seien „völlig lesbar, nichts, worüber man sich Sorgen machen müsste“. Nichts in OpenAIs Veröffentlichung vom 19. Oktober und nichts auf der eigenen Dokumentationsseite des Modells spricht dafür, dass sich dadurch etwas an dem ändert, was die API zurückgibt. Der Reasoning-Leitfaden von OpenAI stellt ausdrücklich klar, dass rohe Reasoning-Tokens nicht offengelegt werden — Reasoning-Elemente bleiben undurchsichtig — und dass das, was man anfordern kann, eine Zusammenfassung des Reasonings über den summary-Parameter ist, wobei verschlüsselte Reasoning-Inhalte über mehrere Turns hinweg erneut abgespielt werden. GPT-6.1 Sol unterstützt die all_turns-Form dieses Replays. Ein Zusammenfassungs-Kanal ist keine lesbare Trace, und daraus, dass man beides als dasselbe behandelt, entsteht eine Sicherheitsbehauptung per Screenshot.

Was messbar ist, liegt daneben – und ist für jeden, der einen Agenten auditiert, interessanter. Sonars Evaluation von GPT-6.1 Sol vom 9. Oktober, die GPT-6 Sol bei mittlerem Aufwand über 4.444 Java-Aufgaben hinweg als Vergleich heranzog, ergab, dass die Reasoning-Tokens um 51,4 % fielen – von 2,64 Mio. auf 1,28 Mio. –, während der Anteil des Reasonings an der Ausgabe von 41,8 % auf 19,5 % sank, die Ausgabe stieg und die funktionale Erfolgsquote von 83,09 % auf 85,29 % verbesserte. Derselbe Lauf ergab eine um 32,4 % gesunkene Schwachstellendichte, aber die Zahl der Zuverlässigkeitsbefunde kritischer Schwere stieg von 21 auf 46, wobei Nebenläufigkeitsfehler mit 196 Befunden die größte Kategorie waren. Das ist ein Trade-off, auf den ein Reviewer reagieren kann. „Traces sind lesbar“ ist es nicht, denn die Traces sind nicht das, was zurückgegeben wird.

Für ein Migrationsprojekt ist das in einer konkreten Hinsicht wichtig: Ihr Audit-Trail ist der Diff und die Testausgabe, nicht die Erzählung des Modells. Planen Sie die Review-Kapazität entsprechend — Sonars Befund, dass 39,4 % mehr generierter Code 12.982 Gesamtbefunde gegenüber 9.859 erzeugte, zeigt die Form der Kosten, die sich hinter einem Benchmark-Score verbergen.

Beide Arme selbst zu leiten

Das praktische Problem bei einem solchen Vergleich ist, dass der Baseline-Arm und der neue Arm normalerweise zwei Verträge, zwei Keys und zwei Abrechnungsbeziehungen sind – genug Reibung, dass niemand die Baseline laufen lässt. Beide Modelle liegen in unserem Katalog hinter einem einzigen Key: openai/gpt-6.1-sol und openai/gpt-5.6-sol, zu OpenAIs Listenpreisen mit 0 % Aufschlag, also dieselben $2.00 für Input und $10.00 für Output pro Million Token, die Sie beim Anbieter zahlen würden, mit gecachtem Input zu $0.10 und Cache-Writes zu $2.50, und die Stufe über 272K wird zu $4.00, $0.20, $5.00 und $15.00 durchgereicht. Eine Tarifänderung des Anbieters ist hier ab dem Tag der Veröffentlichung live und nicht erst zur nächsten Vertragsprüfung.

Diese Durchreichung ist der Grund, warum ein Benchmark am selben Tag günstig läuft: Richte die {{1}}MultiLangBench{{/1}}-Quick-Suite auf beide Modelle aus, zahle bei jedem den Listenpreis, und du hast eine Zahl zu deiner eigenen Toolchain statt zu der von {{2}}O​penAI{{/2}}. Automatisches Failover ist die andere Hälfte des Arguments — wenn das neuere Modell mitten im Lauf nachlässt oder eine Route ins Rate-Limit läuft, schlägt die Anfrage nicht mit ihm fehl, und genau das ermöglicht es dir, ein unerprobtes Modell vor eine Migrationspipeline zu setzen, bevor du eigene Belege hast.

Der MultiLangBench-Harness ist öffentlich, die COBOL-Migrationsfälle sind es nicht, also ist der einzige ehrliche Test der 86,6 % der, den Sie selbst bauen: Stichproben von ein paar hundert Ihrer eigenen COBOL-Programme ziehen, sie übersetzen und die Ausgabe Byte für Byte gegen das ursprüngliche Verhalten abgleichen. Das ist eine Woche Arbeit und sie ist mehr wert als die Anbietertabelle.

Was als Nächstes ansehen

Drei Dinge würden dieses Bild verändern, und keines davon ist bisher eingetreten. Wenn O​penAI die COBOL-Migrationsfälle veröffentlichte oder ein unabhängiges Labor sie erneut ausführte, würde aus einer Anbieterzahl eine Messung. Wenn eine dritte Partei die MultiLangBench-Tabelle pro Sprache reproduzierte, wüssten wir, ob COBOLs 72,1 % eine Eigenschaft der Sprache oder der Suite ist. Und der unabhängige Benchmark-Rekord des Modells – Artificial Analysis führt GPT-6.1 Sol derzeit mit einem Intelligence Index von 52, auf Platz zwölf von 214 Modellen, bei 55,2 Ausgabe-Tokens pro Sekunde und 0,72 $ pro Index-Aufgabe – ist die Prüfung, die überhaupt nicht von O​penAIs eigenen Evals abhängt.

Bis dahin ist die nützliche Zusammenfassung kurz. GPT-6.1 Sol ist ein Modell vom 29. September, dessen Legacy-Code-Fähigkeit am 19. Oktober dokumentiert wurde – in einer Eval, die Sie ausführen können, und einer, die Sie nicht ausführen können. Die ausführbare besagt, dass die neue Generation bei ressourcenarmen Sprachen in einer anderen Klasse spielt. Die nicht ausführbare besagt, dass sich eine COBOL-Migration inzwischen für einen Pilotversuch lohnt. Nur Ihre eigene Codebasis kann aus beidem eine Entscheidung machen.