ARC-AGI-3: „GPT-5.6 Sol schlägt Opus 5“ – nur ist das kein Vergleich, sondern ein Messproblem

Im Mai habe ich hier geschrieben, dass die offiziellen ARC-AGI-3-Scores nicht messen, was ein gutes Agentensystem aus einem Frontier-Modell holen kann, sondern was passiert, wenn man ein Modell fast nackt in eine fremde Umgebung wirft. Genau das ist jetzt vorgeführt worden – nur anders, als ich erwartet hatte. Und die Konsequenz ist unangenehmer als ein Platzwechsel auf einem Leaderboard.

Die Nachricht selbst ist schnell erzählt. Nachdem Anthropics Claude Opus 5 den Bestwert auf ARC-AGI-3 vervierfacht hatte, zeigt OpenAI, dass GPT-5.6 Sol mit zwei zusätzlichen API-Einstellungen auf 38,3 % kommt und damit über den 30,2 % von Opus 5 liegt. Die beiden Einstellungen heißen „Retained Reasoning“ – der interne Denkprozess bleibt über Aktionen hinweg erhalten – und „Compaction“, also intelligente Zusammenfassung des Kontexts statt hartem Abschneiden.

Der Haken steckt im Setup: Gemessen wurde nicht in der offiziellen Testumgebung, sondern über OpenAIs eigene Responses-API. In der offiziellen Umgebung erreicht dasselbe Modell 7,8 %, weil dort nach jeder Aktion das interne Denken verworfen wird.

Der einzige belastbare Vergleich lautet 30,2 zu 7,8

Wer die Schlagzeile ernst nimmt, vergleicht einen optimierten Lauf mit einem nicht optimierten. Sortiert man die Zahlen nach Vergleichbarkeit, sieht das Bild anders aus:

• Offizielle Umgebung, Opus 5: 30,2 %
• Offizielle Umgebung, GPT-5.6 Sol: 7,8 %
• Eigene API mit Retained Reasoning und Compaction, GPT-5.6 Sol: 38,3 %

Die einzigen beiden Werte, die unter identischen Bedingungen entstanden sind, sind die ersten beiden – und dort liegt Opus 5 um etwa den Faktor vier vorn. Der dritte Wert hat kein Gegenstück, weil niemand veröffentlicht hat, wo Opus 5 mit einer äquivalenten Behandlung landen würde. Solange dieser Lauf fehlt, ist „GPT-5.6 Sol schlägt Opus 5“ keine Aussage über Modelle, sondern über Messbedingungen.

Dazu kommt ein zweiter Vorbehalt, den man in den Sekundärberichten leicht überliest: OpenAIs Grafik ist mit „ARC-AGI-3 Public Set“ überschrieben, während offizielle Leaderboard-Werte üblicherweise für das semi-private Set berichtet werden. Ob 38,3 % und 30,2 % überhaupt dieselbe Aufgabenmenge betreffen, geht aus den öffentlichen Quellen nicht eindeutig hervor. Es handelt sich außerdem um eine Selbstmessung des Anbieters auf öffentlich verfügbaren Umgebungen – strukturell die schwächste Evidenzform, die es in diesem Feld gibt.

Das ist kein Vorwurf an OpenAI. Die Zahl ist interessant und der Punkt dahinter ist berechtigt. Aber die Zahl trägt die Schlagzeile nicht, die aus ihr gemacht wurde.

Der Hebel war nicht das Harness, das ich erwartet hatte

Im Mai-Artikel habe ich als Hebel ein clientseitiges Gerüst beschrieben: Frame-Differencing, State-Tracking, Hypothesenmanagement, Explorationsplanung, kausale Tests. Also Ingenieursarbeit außerhalb des Modells.

Was jetzt tatsächlich den Unterschied gemacht hat, ist etwas anderes und aus meiner Sicht deutlich aufschlussreicher: zwei generische Funktionen der Modell-API, die den Denkzustand über Schritte hinweg erhalten. Kein ARC-spezifischer Trick, keine handgebauten Wahrnehmungswerkzeuge, keine Spiellogik im Prompt.

Damit isoliert dieser Fall eine sehr konkrete Eigenschaft der offiziellen Messung. Wenn nach jeder Aktion das interne Reasoning verworfen wird, dann misst der Benchmark unter anderem, ob ein Modell in der Lage ist, seinen eigenen Gedankengang bei jedem Schritt aus dem sichtbaren Kontext neu zu rekonstruieren. Das ist eine reale Fähigkeit, aber es ist nicht die Fähigkeit, die ARC-AGI-3 messen will. Es ist ein Artefakt der Testumgebung.

Und die Kosten dieses Artefakts sind erheblich. OpenAIs Grafik zeigt zwei Skalierungskurven über den Output-Tokens pro Spiel. Die Kurve mit Retained Reasoning und Compaction erreicht ihre knapp 38 % bei rund einer halben Million Output-Tokens. Die offizielle Umgebung kommt in derselben Grafik auf etwa 13 % – und braucht dafür ungefähr drei Millionen Tokens, also grob das Sechsfache. Mehr Score bei einem Bruchteil der Tokens ist keine Fußnote, sondern der eigentliche Befund.

Einheitlichkeit ist nicht dasselbe wie Fairness

ARC Prize kommentiert die Ergebnisse damit, dass die offiziellen Scores einen einheitlichen Ansatz ohne anbieterspezifische Einstellungen nutzen, um faire Vergleiche zu ermöglichen, und dass ARC-AGI-3 die reine Modellleistung bewerten soll.

Ich verstehe die Logik – und ich habe sie im Mai selbst verteidigt. Aber hier trennen sich zwei Dinge, die gern verwechselt werden. Ein einheitliches Setup erhöht die Reliabilität einer Messung: gleiche Bedingungen, reproduzierbare Werte, wenig Interpretationsspielraum. Über die Validität sagt das nichts. Und genau die erodiert gerade.

Denn die offizielle Policy setzt eine Grenze voraus, die in der Praxis nicht mehr existiert: dass die API-Kante ein sauberer Schnitt zwischen Modell und Gerüst ist. Was unterhalb der API passiert, gilt als Modell, was oberhalb passiert, als Ingenieursleistung. Diese Annahme war tragfähig, solange APIs zustandslose Textvervollständigung angeboten haben. Sobald Anbieter Kontextmanagement, Zustandserhalt und Kompression als Serverfunktion anbieten, wandert genau das, was mein Mai-Artikel als „Harness“ beschrieben hat, unter die API-Kante. Die Grenze verschiebt sich – und der Benchmark kann sie nicht mehr per Definition festhalten.

Der Streitpunkt, den The Decoder benennt, ist genau das: ARC Prize nutzt für OpenAI-Modelle offenbar eine ältere Completions-API, die Funktionen der Claude-API noch nicht hatte. Ein einheitliches Setup, das auf den kleinsten gemeinsamen Nenner mehrerer APIs zielt, bestraft damit systematisch den Anbieter, der bei Zustandsführung am weitesten ist – oder eben den, dessen Endpunkt zufällig weniger davon abbildet. Einheitlich ist so ein Setup. Fair ist es nicht automatisch.

Chollets Kriterium ist richtig – und trotzdem instabil

ARC-Prize-Mitgründer François Chollet hat nachgelegt und dabei eine brauchbare Trennlinie gezogen: Umgebungen und Einstellungen, die speziell für den Benchmark gebaut wurden oder Wissen über dessen Format enthalten, sind nicht zulässig. Allgemeine API-Einstellungen, die nicht für ARC-AGI-3 entwickelt wurden und allen Nutzern offenstehen, sind in Ordnung. Er verweist zudem auf früheren Austausch mit OpenAI zur Frage, wie deren Modelle am besten zu testen sind, gerade beim Thema Compaction, und benennt das Vergleichbarkeitsproblem, wenn jeder Anbieter eigene Einstellungen nutzt – akzeptabel, solange Einstellungen und Kosten dokumentiert werden.

Das ist die inhaltlich richtige Unterscheidung, und sie deckt sich mit dem, was ich im Mai als Kern gesehen habe: Nicht die Menge an Hilfe entscheidet, sondern ihre Aufgabenspezifität. Ein generisches Gerüst, das auch in anderen Domänen sinnvoll wäre, ist etwas anderes als ein ARC-Solver.

Nur bleibt das Kriterium instabil, weil „allgemein und für alle verfügbar“ eine bewegliche Menge ist. Sie unterscheidet sich pro Anbieter, sie ändert sich mit jedem API-Release, und sie fällt genau in den Bereich, in dem Anbieter sich derzeit differenzieren. Ein Leaderboard, das reine Modellfähigkeit ausweisen will, aber Anbieterunterschiede in der API-Schicht durchlässt, weist am Ende beides aus – nur ohne getrennte Spalten. Chollets Zusatzbedingung, Einstellungen und Kosten offenzulegen, ist deshalb nicht Kosmetik, sondern die einzige Stelle, an der das Konstrukt noch zusammenhält.

Wer diese Diskussion aus dem GEO- und SEO-Umfeld kennt, wird das Muster wiedererkennen: Ein Messverfahren wird nicht dadurch valide, dass es streng standardisiert ist. Es wird valide, wenn das, was es misst, mit dem übereinstimmt, was man wissen will.

Was das für die Praxis bedeutet

Für die Benchmark-Debatte ist der Fall ein Definitionsproblem. Für alle, die tatsächlich Agenten bauen, ist er eine ziemlich klare Ansage.

Die entscheidende Variable ist nicht der clevere Prompt. Sie ist die Frage, was zwischen zwei Schritten überlebt. Wird der Denkzustand mitgeführt oder bei jedem Schritt weggeworfen? Wird Kontext zusammengefasst oder vorne abgeschnitten? Diese beiden Design-Entscheidungen sind in diesem Fall der Unterschied zwischen 7,8 % und 38,3 %.

Und sie sind gleichzeitig ein Kostenhebel. Sechsmal weniger Output-Tokens für einen höheren Score bedeutet, dass Kontextmanagement nicht in der Qualitätsspalte steht, sondern in der Marge. In produktiven Multi-Step-Pipelines ist das der Punkt, an dem sich Prompt Caching, Kompressionsstrategien und Zustandsführung rechnen – nicht als Feinschliff, sondern als Architekturentscheidung.

Was ich daraus nicht ableite: dass die Modelle das Problem gelöst hätten. 38,3 % auf einem Set, das Menschen weitgehend beherrschen, ist kein Triumph. Und die Frage aus meinem Mai-Artikel ist immer noch unbeantwortet, weil sie niemand gemessen hat: Wie weit kommt ein vorab eingefrorenes, nicht ARC-spezifisches Agenten-Harness auf ungesehenen Umgebungen? Der Vergleich Opus 4.6 auf TR87 – 0,0 % ohne Harness, 97,1 % mit dem Duke-Harness, und gleichzeitig 0,0 % in beiden Varianten auf BP35 – bleibt die beste Illustration dafür, warum diese Unterscheidung nicht akademisch ist.

Was ich zurücknehme, was ich bestätigt sehe

Bestätigt sehe ich die Grundaussage: Die offiziellen Scores sind eine Untergrenze, kein Limit. Wer sie als Beweis für die Chancenlosigkeit LLM-basierter Agenten liest, liest sie falsch.

Präzisieren muss ich die Vermutung, wo der Hebel liegt. Ich habe ihn oberhalb der API erwartet, im selbstgebauten Gerüst. Er liegt – zumindest in diesem Fall – unterhalb, in der Zustandsführung des Anbieters. Das ist für die Benchmark-Frage die unangenehmere Variante, weil sie sich nicht durch eine strengere Testing Policy wegdefinieren lässt.

Und eine Sorge aus dem Mai-Artikel hat sich verschoben. Ich habe befürchtet, dass Harness-Ergebnisse als Modellfortschritt gefeiert werden. Das Risiko besteht weiter, aber es hat eine zweite Richtung bekommen: Ein Benchmark, der sich gegen anbieterspezifische Einstellungen abschottet, misst mit jedem Release ein wenig weniger von dem, was diese Modelle in der Praxis leisten. Beide Fehler sind real, und sie zeigen in entgegengesetzte Richtungen.

Fazit

Die Schlagzeile lautet, GPT-5.6 Sol habe Opus 5 geschlagen. Belegt ist etwas anderes: dass die offizielle ARC-AGI-3-Umgebung mit ihrem Verwerfen des Reasonings eine Eigenschaft mitmisst, die sie nicht messen wollte, und dass zwei generische API-Einstellungen den Score um einen Faktor bewegen, den man sonst nur von aufgabenspezifischen Harnesses kennt.

Für ARC Prize folgt daraus keine Kapitulation, sondern eine Hausaufgabe: getrennte Spalten statt eines einzigen Wertes. Modell in einheitlicher Umgebung, Modell mit dokumentierten allgemeinen Anbietereinstellungen, System mit generischem Harness. Drei Zahlen, drei Aussagen, keine Vermischung. Chollets Hinweis auf Dokumentation von Einstellungen und Kosten zeigt in genau diese Richtung.

AFAIK: Interessant ist an diesem Fall nicht, wer vorne liegt. Interessant ist, dass die Grenze zwischen „das Modell kann es“ und „das System kann es“ gerade dorthin wandert, wo Benchmarks sie nicht mehr kontrollieren können. Wer Agenten baut, sollte diese Grenze ohnehin nicht interessieren. Wer Fortschritt messen will, muss sie neu ziehen.