Was ist passiert?
Together AI veröffentlichte eine direkte Bewertung von GLM-5.3 und GPT-5.6 Sol im Software-Engineering-Benchmark DeepSWE. Sol löste beim ersten Versuch mehr Aufgaben; GLM-5.3 setzte sich durch, sobald mehrere Versuche zulässig waren, und zwar zu etwa der Hälfte der Kosten pro Rollout. Eine Kaskade, die zuerst GLM-5.3 ausführt und Fehler an Sol eskaliert, erzielte die höchste Punktzahl von allen.
Together AI, ein Unternehmen, das Inferenz- und GPU-Kapazität für offene Modelle verkauft, veröffentlichte am 21. August 2026 einen Blogbeitrag, in dem GLM-5.3 mit GPT-5.6 Sol auf DeepSWE verglichen wurde, einem Benchmark für Software-Engineering-Aufgaben, die mehrere Sprachen und Aufgabentypen umfassen. Die Autoren, die als Zain Hasan und Shobhit Dixit aufgeführt sind, geben an, dass sie alle 113 Aufgaben viermal pro Modell mit beiden Systemen bei maximaler Leistung ausgeführt haben, für insgesamt 904 Rollouts und 452 pro Seite, und sich dabei auf die veröffentlichten Pro-Test-Aufzeichnungen eines DeepSWE v1.1-Exports gestützt, anstatt den Kabelstrang selbst End-to-End auszuführen.
Bei der Schlagzeilenkennzahl lag Sol vorne: 72,7 % bestanden bei 1 gegenüber 69,0 % bei GLM-5.3, ein Abstand von 3,7 Punkten, wie der Beitrag selbst sagt, „liegt innerhalb einiger Standardabweichungen“, wenn man die gemeldeten Fehlerbalken von ±2,2 und ±2,7 Punkten berücksichtigt. Bei Wiederholungsversuchen kehrt sich die Reihenfolge um. Bei zwei Versuchen sind die beiden gleichauf (81,1 % für GLM-5.3, 81,0 % für Sol); Bei vier führt GLM-5.3 mit 87,6 % bis 85,8 %. Die Bewertung von Fehlern als Ausfälle verändert beide Zahlen kaum (68,8 % und 72,3 %), da der Lauf nur einen Infrastrukturfehler für GLM-5.3 und zwei für Sol protokollierte.
Das Kosten- und Geschwindigkeitsbild teilt sich in die andere Richtung. Together AI meldet 3,99 US-Dollar pro GLM-5.3-Rollout gegenüber 8,37 US-Dollar für Sol – 2,1-mal günstiger, oder 17 gelöste Aufgaben pro 100 US-Dollar gegenüber neun – mit Gesamtdurchläufen von 1.806 US-Dollar und 3.783 US-Dollar. Sol war der schnellere und knappere Arbeiter: durchschnittlich 19 Minuten und 61 Schritte pro Rollout und 60.000 Ausgabe-Tokens, im Vergleich zu GLM-5.3 mit 35 Minuten, 124 Schritten und 80.000 Ausgabe-Tokens. Sol war auch konstanter, löste in allen vier Versuchen 61 Aufgaben gegenüber 48 von GLM-5.3 und erzielte eine Zuverlässigkeit von 84,5 % gegenüber 78,8 %.
In der Fehleranalyse des Beitrags weichen die beiden am sinnvollsten voneinander ab. Sol hat bei 20 % der Ausfälle die bestehende Testsuite eines Repositorys kaputt gemacht; Bei GLM-5.3 war dies bei 11 % der Fall und führte häufiger zu einem Beinaheunfall mit intakter Grundlinie (61 % gegenüber 54 %). Nach Domänen teilt das Board jeweils vier Siege auf, wobei Sol stärker bei der exakten Vertrags- und Systemarbeit und GLM-5.3 stärker bei Abfrage- und Konfigurationssprachen, Laufzeitinterna und zustandsbehafteter Reaktivität ist; Der eindeutige Schwachpunkt von GLM-5.3 ist die Protokollkonformität mit 44 %, fünfzehn Punkte hinter Sol. Sprachlich liegt GLM-5.3 bei JavaScript (90 bis 75) und Rust (70 bis 60) vorn und Sol bei Python, Go und TypeScript.
Da die Übereinstimmung pro Aufgabe zwischen den beiden nur 0,43 beträgt, deckt ihre Vereinigung 106 der 113 Aufgaben ab. Daraus ergibt sich die zentrale Empfehlung von Together AI: Zuerst GLM-5.3 ausführen und erst dann an Sol eskalieren, wenn eine Testsuite die Antwort ablehnt. Berichten zufolge löst diese Kaskade 85,9 % der Aufgaben für jeweils 6,61 US-Dollar – mehr als Sol allein und unter dem Preis einer einzelnen Sol-Einführung – und übertrifft einen hypothetisch perfekten One-Shot-Router mit 83,8 %. Der Methodenhinweis weist auf echte Grenzen hin: Trajektoriendateien pro Runde für den GLM-5.3-Stapel befanden sich nicht im öffentlichen CDN, daher erfolgt die Analyse auf Indexebene; Aufgabenbereiche wurden durch ein Sprachmodell klassifiziert; und die Kaskadenfigur geht von einem zuverlässigen Prüfer und Unabhängigkeit zwischen Versuchen aus.
Lesen Sie die Primärquelle: together.ai ↗
Warum es wichtig ist
Das Ergebnis gibt einen konkreten Preis für die verbleibende Lücke zwischen einem Open-Weight-Coding-Modell und einem Closed-Frontier-Modell an und zeigt, dass das Ranking stark davon abhängt, welche Metrik ein Team optimiert. Es quantifiziert auch einen praktischen Sicherheitsunterschied: wie oft jedes Modell bereits bestandene Tests bricht.
Für Teams, die Modelle für Agenten-Codierungsarbeiten auswählen, ist dies eine der spezifischeren öffentlichen Abrechnungen darüber, was die Prämie eines Grenzmodells bedeutet. Es wird nicht behauptet, dass das offene Modell besser sei, sondern dass der Unterschied bei der Genauigkeit beim ersten Versuch unter vier Punkten liegt und innerhalb des gemeldeten Rauschens liegt, während der Preisunterschied einen Faktor von zwei beträgt. Ausgedrückt als Arbeit pro Dollar – 17 gelöste Aufgaben pro 100 Dollar gegenüber neun – stellt der Vergleich die Modellauswahl für einen Großteil der Routineaufgaben als Budgetfrage und nicht als Fähigkeitsfrage dar.
Das Ergebnis zeigt auch, wie stark die Antwort von der Metrik abhängt. Ein Team, das den ersten Ausgang akzeptieren muss, mit menschlicher Warteschleife, sollte Sols höheren Pass@1, höhere Zuverlässigkeit und etwa die Hälfte der Gesamtzeit als entscheidend ansehen. Ein Team, das Batch-Jobs hinter einer Testsuite ausführt, sollte Pass@4 und Coverage von GLM-5.3 in die gleiche Richtung lesen. Dies sind keine konkurrierenden Interpretationen einer Zahl; Es handelt sich um unterschiedliche Zahlen, und in dem Beitrag wird ausdrücklich darauf hingewiesen, dass sich Best-of-K-Vorteile nur dann in einen Wert umwandeln, wenn etwas einen guten Patch automatisch von einem schlechten unterscheiden kann.
Die Fehleranatomie ist für jeden, der modellgeschriebene Unterschiede ausliefert, wichtiger als die Schlagzeile. Ein Modell, das zuvor bestandene Tests bei 20 % seiner Fehlschläge durchbricht, stellt eine andere Überprüfungslast dar als eines, bei dem dies bei 11 % der Fall ist, unabhängig davon, welches Modell besser abschneidet. Der praktische Rat von Together AI – führen Sie einen vollständigen Regressionslauf um die Ausgabe von Sol durch, bevor Sie ihn akzeptieren – ist die Art von Betriebsdetails, die in Benchmark-Bestenlisten normalerweise weggelassen werden, und er kann von jedem Team überprüft werden, das seine eigene Suite betreibt.
Mehrere Vorbehalte schränken die Verbreitung der Ergebnisse ein. Hierbei handelt es sich um einen einzelnen Benchmark von 113 Aufgaben, die von einem Anbieter gemessen wurden, dessen Geschäftsvorteile bei offenen Modellen konkurrenzfähig erscheinen; Es wurde nicht unabhängig reproduziert und der Beitrag besagt, dass seine eigenen Zahlen von denen anderer öffentlicher Scorecards desselben Paares abweichen könnten. Die Kosten hängen von den Preisen ab, die sich ohne Vorankündigung ändern können. Der Beitrag nennt GLM-5.3 „den Open-Weight-Herausforderer“, nennt aber weder seinen Entwickler noch seine Lizenz oder wo die Gewichte erhältlich sind; AI Understanding hat zuvor über Zhipu AIs Open-Sourcing-Lösung GLM-5.2 berichtet, und es wird hier nicht nachgewiesen, dass GLM-5.3 zu denselben Bedingungen verfügbar ist. Weder OpenAI noch der GLM-Entwickler werden zitiert, und in der Quelle erscheint keine Antwort von beiden.
Was Sie als nächstes sehen sollten
Ob unabhängige Gruppen die Zahlen reproduzieren, ob die gemeldete Preislücke Preisänderungen übersteht, ob GLM-5.3-Gewichte tatsächlich allgemein verfügbar sind und ob verifizierergesteuerte Kaskaden zu einem Standardbereitstellungsmuster und nicht zu einem Benchmark-Artefakt werden.
Das erste, worauf man achten sollte, ist die Replikation. Together AI arbeitete mit veröffentlichten Aufzeichnungen pro Versuch und gab an, dass die Flugbahndateien pro Runde für seinen GLM-5.3-Stapel im öffentlichen CDN fehlten, als es die Analyse durchführte, wodurch die Arbeit auf Indexebene blieb. Wenn diese Artefakte veröffentlicht werden, können andere Forscher die Fehleranatomie und die Beinahe-Fehler-Klassifizierungen überprüfen, die auf Definitionen basieren, die im Beitrag bereitgestellt werden (ein Beinahe-Fehler bedeutet, dass mindestens 80 % der neuen Tests mit intakter Basislinie bestanden werden) und nicht auf Benchmark-Standardmaßen.
Die zweite Frage ist, ob das Kaskadenergebnis den Kontakt mit echten Repositories übersteht. Der Wert von 85,9 % geht davon aus, dass ein Prüfer gut genug ist, um zu entscheiden, wann eine Eskalation erfolgen soll, und dass der zweite Versuch unabhängig vom ersten ist. Projekte mit dünnen oder langsamen Testsuiten verfügen nicht über diesen Verifizierer, und eine Testsuite, die einen falschen Patch durchläuft, verwandelt die Kaskade in eine reine Billigmodell-Pipeline. Verifier-Gated-Routing ist in diesem Jahr zu einer sichtbaren Produktkategorie geworden, und diese Analyse liefert eine überprüfbare Aussage darüber, wie viel es tatsächlich wiederherstellen kann.
Der dritte Faktor ist die Dauerhaftigkeit des Preisunterschieds. Sowohl das 2,1-fache Kostenverhältnis als auch die Lösungszahlen pro 100 US-Dollar sind Funktionen der aktuellen Inferenzpreise und der Ausführung beider Modelle mit maximalem Aufwand; Geringere Aufwandseinstellungen, quantisierte Portionen oder eine Preisänderung auf beiden Seiten könnten die Tabelle ohne Änderung der Modellqualität neu anordnen. Das Gleiche gilt für den Geschwindigkeitsunterschied, der die Anzahl der Schritte widerspiegelt, die jedes Modell ausführt, und nicht eine feste Eigenschaft der zugrunde liegenden Systeme.
Achten Sie abschließend auf die spezifischen Schwächen jeder Seite. Die 44 % der Protokollkonformität von GLM-5.3 sind der einzige Bereich, in dem der Beitrag einen entscheidenden Sol-Vorteil meldet, und es handelt sich um die Art von Lücke, die ein Point-Release schließen oder vertiefen kann. Ob nachfolgende Versionen beider Modelle diese Aufteilungen pro Domäne und pro Sprache verschieben – und ob DeepSWE selbst bei breiterer Verwendung unversehrt bleibt – wird darüber entscheiden, wie lange aus diesem Lauf abgeleitete Routing-Regeln nützlich bleiben.
