Qwen3.8-Flash-Next als Coding-Agent in OpenCode

Der Agent bekommt ein Repository auf dem Stand vor der Reparatur und das Issue im Wortlaut, dazu einen Satz: Löse das Issue, du darfst Befehle und die vorhandenen Tests ausführen, höre auf, wenn du fertig bist. Die Tests, mit denen gewertet wird, bekommt er nicht, ebenso wenig einen Hinweis auf sie. Die Abhängigkeiten sind installiert; ins Netz kommt er nicht. Erreichbar ist nur der eigene Sprachmodell-Server.

Die sechs Aufgaben stammen aus SWE-bench Verified. Genommen wurde nur, was zwei veröffentlichte Läufe anderer Modelle beide gelöst haben, reines Python ist und laut Datensatz 15 Minuten bis eine Stunde Arbeit für einen Menschen bedeutet. Die Aufgaben sind also nachweislich lösbar. Gemessen wird, ob Flash-Next sie auf diesen Servern löst, wie lange es dafür braucht und wie verlässlich über drei Durchgänge.

Gewertet wird wie bei SWE-bench: Der Patch, den der Agent im Arbeitsbaum hinterlässt, kommt auf einen frischen Stand, dazu die Tests der Aufgabe. Gelöst ist eine Aufgabe, wenn die Tests zum Fehler bestehen (FAIL_TO_PASS) und kein vorher bestehender Test fällt (PASS_TO_PASS). Die Wertung läuft ohne Docker in einer Python-Umgebung, die der Harness von SWE-bench in Version 4.1.0 nachgebildet ist.

Alle drei Arme haben dieselben Einstellungen: Kontext bis 262.144 Token, Temperatur 1,0, top_p 0,95, Denkstufe xhigh, automatische Kompaktierung an, Prompt-Cache an. Beide Server nutzen ihre Mehrtoken-Vorhersage (MTP). Jede Maschine bearbeitet die 18 Durchgänge nacheinander in derselben Reihenfolge; nebenher läuft nichts.

Auf dem HP ZBook löst der Agent alle 18 Durchgänge, auf beiden Macs je 17. Die beiden Fehlschläge sind derselbe Durchgang derselben Aufgabe, M3 im zweiten Durchgang, auf dem MacBook und auf dem Mac Studio, mit derselben unvollständigen Lösung: Der Agent filtert doppelte Fundstellen in Catalog.add über Datei, Zeile und eine Kennung (uid). Die Duplikate aus dem Issue tragen verschiedene Kennungen und bleiben deshalb stehen. Der Test zum Fehler scheitert, alle übrigen bestehen.

Ob sushi bei M3 schwächer ist oder ob ein Fehlschlag in drei Durchgängen Zufall ist, lässt sich aus dieser Messung nicht ablesen.

Ein Durchgang endete an der Zeitgrenze: G1 im dritten Durchgang auf dem MacBook, nach 120 Minuten. Der Patch, den der Agent bis dahin geschrieben hatte, besteht alle Tests und zählt deshalb als gelöst, wie bei SWE-bench. Die Schrittgrenze von 150 griff nie.

Jeder Schritt des Agenten ist eine Anfrage an den Server: Er liest den neuen Teil des Verlaufs ein, meist die Ausgabe des letzten Werkzeugs, und schreibt Denken und den nächsten Werkzeugaufruf. Das MacBook liest im Median 309 Token je Sekunde ein und gibt 30,7 aus, der Mac Studio 521 und 43,7, das ZBook 1.220 und 58,3. Mit wachsendem Kontext ändert sich das Tempo auf allen drei Maschinen wenig.

Die beiden Macs rechnen mit demselben Server und denselben Gewichten. Der Mac Studio mit 64 GPU-Kernen liest 1,7-mal so schnell ein wie das MacBook mit 32 und schreibt 1,4-mal so schnell. Zwischen ZBook und Macs sind Plattform, Server und Gewichte zugleich verschieden; die Zahlen sagen, wie schnell es auf der jeweiligen Maschine geht.

Wohin die Zeit geht, ergibt sich aus den Protokollen: Einlesen und Ausgabe stehen je Anfrage darin, der Rest der Wandzeit gehört den Werkzeugen, also vor allem den Tests, die der Agent selbst laufen lässt, und OpenCode. Auf den Macs entfällt der größte Teil auf die Ausgabe, auf dem ZBook auf den Rest. Darin steckt eine Stunde, in der der Agent in G2 auf sich selbst wartete (Kapitel 04).

Je Schritt schreibt der Agent auf allen drei Maschinen ähnlich viel, zwischen 549 und 592 Token. Auf dem MacBook brauchte er mehr Schritte, 1.426 gegen 1.107 auf dem Mac Studio und 771 auf dem ZBook. Die Wandzeit enthält beides, das Tempo je Schritt und die Zahl der Schritte, die von Durchgang zu Durchgang streut.

Wie tief der Kontext wird, entscheidet der Agent. Am tiefsten ging eine Sitzung auf dem MacBook mit 217.152 Token, auf dem Mac Studio waren es höchstens 163.340, auf dem ZBook 111.553. Keine Sitzung erreichte die Schwelle, ab der OpenCode den Verlauf zusammenfasst; kompaktiert wurde nie.

Von 3.571 Werkzeugaufrufen scheiterten 18 (MacBook 6, Mac Studio 6, ZBook 6).

Ein Durchgang zeigt, wie ein Agent sich selbst aufhalten kann: In G2 auf dem ZBook wartete er mit while pgrep -f "runtests.py --parallel 1" auf seinen Testlauf. Das Suchmuster steht in der Befehlszeile der Warteschleife selbst, also findet sie sich immer. Sie endete erst an der Zeitgrenze von einer Stunde, die der Agent dem Befehl mitgegeben hatte. Danach löste er die Aufgabe, nach 72,8 Minuten.

In 40 von 54 Durchgängen versuchte der Agent, ins Netz zu gehen. Er rief mit curl Dateien von raw.githubusercontent.com und api.github.com ab, teils gezielt den Pull Request zum Issue, lud mit pip download neuere Fassungen des Pakets, fragte mit git ls-remote das Original-Repository ab und rief fetch() im JavaScript-Werkzeug von OpenCode auf. Kein Versuch bekam Daten: Auf allen drei Maschinen sperrte die Sandbox des Betriebssystems jede dieser Verbindungen. Jede Ausgabe ist in den Exporten der Sitzungen geprüft.

Mit offenem Netz würde Flash-Next bei SWE-bench-Aufgaben also regelmäßig die veröffentlichte Lösung holen. Eine solche Messung zeigt dann, wie gut der Agent sucht, nicht wie gut er repariert.

Bestandene Tests sagen nicht, ob ein Patch die Ursache trifft oder nur den getesteten Fall. Alle 52 gelösten Patches hat deshalb je Aufgabe ein Prüfer beurteilt, der nicht wusste, von welcher Maschine sie stammen: ein Sprachmodell (Claude Haiku 5.5) mit dem Issue, der Referenzlösung der Projektbetreuer und den Patches in zufälliger Reihenfolge, Pfade geschwärzt. Er beantwortete drei Fragen je Patch mit festen Werten.

Kein Patch umgeht nur das Symptom; alle treffen die Ursache ganz oder für den gemeldeten Fall. Den deutlichsten Unterschied zeigt der Beifang: Hilfsskripte, Logdateien und Ausgaben, die der Agent im Repository liegen ließ, fand der Prüfer in 4 von 17 Patches vom MacBook und in keinem von den beiden anderen Maschinen.

Beim Vergleich mit der Referenzlösung trennt der Prüfer wenig: In 3 der sechs Aufgaben (M1, M2, M3) gab er allen Patches denselben Wert. Für Unterschiede zwischen den Maschinen trägt diese Frage deshalb kaum.