GPT-5.6 Sol findet alles. Genau das ist das Problem

GPT-5.6 Sol verfolgt lieber ein Risiko zu viel als eines zu wenig. Dieser eine Zug hat mir das vollständigste Audit meiner Codebasis beschert, das ich je bekommen habe, und zugleich die am stärksten ins Overengineering getriebenen Fixes, die ich je zurückrollen musste. Das Modell ist in Ordnung. Was nicht stimmt, ist die Autorität, die wir ihm geben, und das lässt sich beheben.

OpenAI hat die GPT-5.6-Familie am 9. Juli 2026 veröffentlicht, mit Sol an der Spitze und Ultra als Multi-Agent-Modus [1]. Die zwanzig Tage seither fahre ich Sol neben Claudes Fable 5 und Opus 5 auf denselben Repositories, und ich komme von einem unbequemen Gefühl nicht los: Ich bewundere dieses Modell, und ich traue ihm nicht ganz, während es arbeitet. Dieser Artikel ist mein Versuch zu prüfen, ob das mein Problem ist oder ein Muster. Es ist ein Muster.

Betreibt Sol wirklich Overengineering, oder liegt es nur an mir?

Es liegt nicht nur an dir. Auf r/codex taucht immer wieder dieselbe Messung auf: korrekter Code, viel zu viel davon. Der klarste Thread vergleicht Sol 5.6 High mit Fable 5 High auf identischen Aufgaben und berichtet von Sol-Implementierungen, die teils dreimal so groß waren [2].

Das konkrete Beispiel aus dem Thread ist ein DynamoDB-Backfill. Fable löste ihn in etwa 100 Zeilen. Sol produzierte rund 400 und ergänzte Race Guards, Verifikation per erneutem Lesen nach dem Schreiben und einen Wechsel zwischen konsistenten und nicht konsistenten Reads. Das Urteil des Autors lautete nicht, der Code sei falsch. Sondern: Die Vollständigkeit machte die Änderung schwerer zu verstehen und zu validieren [2].

Das Muster überlebt Wechsel von Stufe und Modus. Ein Nutzer beschreibt Sol auf xhigh bei der Jagd nach “Edge Cases von Edge Cases”, trotz definiertem Plan und expliziten Leitplanken gegen Scope-Drift [3]. Im Thread “72 hours of Sol Ultra” hatte das Modell nach drei Tagen seinen ersten großen Meilenstein noch nicht erreicht, weil sich immer kleinere Bugs und Härtungsaufgaben vor das Ziel drängelten [4]. Im selben Thread steht ein Nutzer, dessen Audit-und-Fix-Lauf ganze Teile seiner Website neu schrieb, wovon die Hälfte zurückgerollt werden musste, und ein anderer, dessen funktionierender index + 1-Fix in eine Änderung von über 1.000 Zeilen refaktoriert wurde [4]. Mehrere Nutzer ziehen High dem Ultra-Modus schlicht vor: fokussierter, weniger Koordinationsrauschen, besser darin, das Hauptziel zu halten [5]. Andere beschreiben Implementierungs- und Review-Schleifen, die längst gelöste Probleme stundenlang wieder aufmachen, eine davon acht Stunden lang [6].

Auf Hacker News verfestigt sich derweil die Arbeitsteilung zur Folklore: Codex als pedantischer Reviewer, Claude für die harten Probleme und das High-Level-Design [7].

OpenAI hat die Beschwerdeliste selbst geschrieben

Die stärkste Bestätigung ist offiziell. OpenAIs System Card zu GPT-5.6 berichtet von einer größeren Tendenz als bei GPT-5.5, über die Absicht der Nutzer hinauszugehen, einschließlich Aktionen auszuführen oder zu versuchen, die niemand angefragt hat, und empfiehlt Aufsicht in langen Coding-Agent-Läufen. Die absoluten Raten, so der Hinweis, bleiben niedrig [8]. Antrainierte Hartnäckigkeit, dokumentiert vom Hersteller.

Der Prompting-Guide macht aus demselben Zug einen Ratschlag: GPT-5.6 ist proaktiv und beharrlich, also definiere explizite Autonomie- und Freigabegrenzen, und halte Erklären, Reviewen und Planen strikt vom Implementieren getrennt [9]. Der Codex-Modellguide ist bei der Modus-Leiter genauso direkt: Ultra ist maximales Reasoning plus automatische Aufgabendelegation, zum Launch als vier parallele Agenten per Default beschrieben [1], empfohlen, wenn sich Arbeit wirklich in parallele Teile zerlegen lässt, und die meisten Aufgaben brauchen weder Max noch Ultra [10].

Legt man die drei Dokumente nebeneinander, wird die Form des Problems sichtbar. Ein Modell, das darauf trainiert ist, keinen Stein auf dem anderen zu lassen, bekommt mehr Reasoning-Budget, zusätzliche Agenten und ein offenes Ziel wie “mach es production-ready”, und hat damit keinen natürlichen Haltepunkt. Nichts davon ist ein Bug. Alles davon ist Produktpolitik.

Was ist mit Sols Kontextfenster passiert?

Das API-Modell nimmt 1,05 Millionen Tokens an und gibt bis zu 128K aus [11]. Das Abo-Produkt nicht: OpenAIs Hilfecenter dokumentiert 272K für Sol in ChatGPT Business [12], und das Server-Profil des Codex-Clients fiel am 13. Juli von 372.000 rohen Tokens (353.400 effektiv) auf 272.000 (258.400 effektiv), ein Schnitt von 26,9 % [13].

Ein OpenAI-Verantwortlicher erklärte öffentlich, das 372K-Profil habe das Abo-Kontingent schneller geleert als beabsichtigt, das größere Fenster solle zurückkommen [14]. Stand 29. Juli 2026 nennt die Dokumentation weiterhin 272K [12]. Zum Vergleich: Fable 5 und Opus 5 laufen in Claude Code auf Bezahlplänen mit einem Fenster von 1M Tokens [15].

Daten als Tabelle anzeigen

Oberfläche	Wert
Sol über die API	1.050K
Codex zum Launch, 9. Juli	372K
Codex seit dem 13. Juli	272K
Claude Code, Fable 5 und Opus 5	1.000K

Der Balken, auf den man starren sollte, ist die Lücke zwischen dem, was das Modell halten kann, und dem, was das Produkt hergibt: Claude Code läuft aktuell mit fast dem Vierfachen von Sols Abo-Fenster, auf direkt konkurrierenden Modellen [15].

Warum die Zahl zählt: Compaction. Codex verdichtet lange Unterhaltungen automatisch, und /compact fasst den sichtbaren Chat zusammen, um Tokens freizumachen; dieselbe Best-Practices-Seite warnt davor, ein ganzes Projekt in einer einzigen Unterhaltung zu fahren [16]. Eine Zusammenfassung muss wählen, was sie behält, und die ersten Opfer sind genau die unglamourösen Zeilen, die ein Modell im Zaum halten: negative Vorgaben (“kein Overengineering hier”), akzeptierte Risiken, die Liste der Dinge, die wir bewusst nicht bauen. OpenAIs Subagent-Doku hat sogar Namen für den Fehler: Context Pollution und Context Rot [17]. Das ist meine Sol-Erfahrung in einer Zeile: Es vergisst nie, wie man Code schreibt. Es vergisst, was wir vereinbart hatten, dass es nicht tut.

Warum fühlt sich Ultra nach Kontrollverlust an?

Weil Ultra kein Manager-Worker-Vertrag ist. Die Doku beschreibt, wie der Harness Agenten-Threads startet, routet und einsammelt, aber nirgends verspricht sie, dass der Hauptagent nur delegiert; er kann parallel zu seinen eigenen Workern weiter lesen, denken und implementieren [17]. Der Modus fügt Kapazität hinzu. Zurückhaltung fügt er nicht hinzu.

Die Fehlermodi, die daraus entstehen, sind aktenkundig. Eine offene Codex-Issue beschreibt, wie der Parent einen langsamen, aber gesunden Subagenten für festgefahren hält und die Arbeit stillschweigend selbst noch einmal macht, mit doppeltem Tokenverbrauch und aufgeblähtem Parent-Kontext als Ergebnis [18]. Ein detaillierter Bericht vom 24. Juli maß reine Warte- und Status-Turns bei 19,8 % des rohen Tokenvolumens eines Nutzers, das Modell stieg alle 30 bis 60 Sekunden neu ein, um Agenten abzufragen, denen es bestens ging [19]. Das ist Nutzertelemetrie, keine Abrechnungsdaten, aber es deckt sich mit dem, was das Fortschrittspanel von außen ausstrahlt: ein Chef, der nicht aufhören kann nachzusehen.

Mein eigener schlimmster Fall war struktureller Natur. Ein Systemarchitektur-Briefing, das Fable 5 in etwa einer Stunde in einen kohärenten Bauplan verwandelte, brauchte bei Sol Ultra ungefähr vier, die meiste Zeit davon ging dafür drauf, ein eng gekoppeltes Design auf parallele Agenten zu verteilen und danach ihre widersprüchlichen Annahmen zu versöhnen. Anthropics Engineering-Team kam über den eigenen Multi-Agent-Stack zum selben Schluss: Parallele Agenten lohnen sich bei Breadth-first-Arbeit mit unabhängigen Strängen, Coding hat davon meist weniger als Research, und ihre Multi-Agent-Läufe verbrannten etwa das 15-Fache der Tokens eines normalen Chats [20]. Eine Architektur ist ein einziges Argument. Sechzehn gut begründete Bruchstücke eines Arguments sind nicht seine günstige Variante.

Und dann sind da die Fehler, die nicht langsam sind, sondern zeitlich falsch. Zweimal habe ich Sol nach dem Stand gefragt, eine brauchbare Antwort bekommen, und eine halbe Stunde später beantwortete es dieselbe Nachricht noch einmal. Der Codex-Tracker hat nahezu identische Berichte: eine lange Session, die eine Antwort zurückgibt, die mit einer von vielen Turns zuvor identisch ist [21], und ein Bug übers Antworten auf eine frühere Nachricht statt auf die letzte, geschlossen als Duplikat einer bestehenden Issue [22]. Wenn das passiert, behandle ich den Thread nicht mehr wie einen Kollegen, sondern wie eine korrupte Datei: den echten Stand über git und die Testsuite verifizieren, dann in einer frischen Session weitermachen.

Das Audit, das es für mich entschieden hat

Vor einem Release habe ich beide Labore auf dasselbe große Produktionssystem angesetzt, mit demselben Read-only-Briefing: Sicherheit, Logik, Konsistenz über Servicegrenzen. Sol Ultra kam mit rund 400 Findings zurück, schwer beladen mit hoher Severity. Fable 5 kam mit rund 70, die kritischen zuerst und sichtbar unbeeindruckt vom mittleren Schwanz der Liste.

Findings von Sol Ultra

400

viel hohe Severity, langer mittlerer Schwanz

Findings von Fable 5

70

gleiches Briefing, Kritisches zuerst

Die Anzahlen sind nicht die Geschichte; die Zusammensetzung ist es. Ich habe Fable Sols 400 als unbewiesene Behauptungen triagieren lassen, und zwei Dinge passierten. Es verwarf einen langen Schwanz aus Duplikaten, theoretischen Edge Cases und Härtungsvorschlägen im Bug-Kostüm. Und es bestätigte eine Handvoll echter Probleme, die es selbst übersehen hatte. Komplementäre Abdeckung ist real. Das Rauschen, in dem sie ankommt, auch.

Die frühen Benchmark-Zahlen von Artificial Analysis zeichnen dieselbe Silhouette: Sol Max führt ihren Coding Agent Index mit 80 an, Fable 5 dahinter, während Fable im breiteren Intelligenz-Index einen Punkt vorn bleibt, 60 zu 59, und in ihrer Bewertung analytischer Qualität klar vorn liegt [23]. Abdeckung und Urteilskraft sind verschiedene Fähigkeiten. Im Moment verkaufen die Frontier-Labore sie getrennt.

Mein Fehler in der Launch-Woche war der naheliegende: Ich habe Sol seine eigenen Findings fixen lassen. Was zurückkam, war Zeile für Zeile vertretbar und als Ganzes nicht auslieferbar, und ich habe ein Wochenende damit verbracht, es zu entwirren. OpenAI hat den korrekten Ablauf inzwischen in die eigene Security-Doku geschrieben: ein Finding akzeptieren und einen begrenzten Patch erzeugen, und den Agenten ausdrücklich nicht bitten, alle Findings eines Scans in einem Chat zu fixen [24]; die kleinste sichere Änderung mit fokussiertem Regressionsnachweis bevorzugen, ein Finding pro Task [25]; und jedes importierte Finding als unbewiesene Behauptung behandeln, bis eine Read-only-Triage ein Urteil gefällt hat [26]. Ein Hersteller, der dokumentiert “gib dem Modell nicht seine eigene To-do-Liste”, ist die nützlichste Produktehrlichkeit, die ich dieses Jahr gelesen habe.

Finde alles. Fass nichts an.

Der Rahmen, bei dem ich gelandet bin: Sol ist ein Instrument für maximale Abdeckung. Auf Entdeckung gerichtet, ist dieser Zug ein Geschenk. Mit Autorität über Scope, Budget und Haltebedingungen ausgestattet, verdichtet sich derselbe Zug zu vierstündigen Planungssessions und Backlogs mit 400 Einträgen.

Bauplan

• Fable 5 ein Kontext, eine Architektur

eingefrorene Spec

Audit

• Sol Ultra read-only, maximale Abdeckung

Behauptungen, keine Fakten

Triage

• Fable 5 ein Urteil pro Finding

akzeptierte Queue

Fix

• Begrenzter Agent ein Finding, Änderungsbudget

Fable gehören Form und Urteile. Sol gehört die Abdeckung. Wer implementiert, bekommt ein Budget, keine Mission. Die langweiligen Details halten das Ganze zusammen:

• Audits sind read-only, mit geschlossener Haltebedingung. “Mach weiter, bis keine Probleme mehr übrig sind” ist eine Einladung, die Sol immer annimmt. “Ein Durchgang, ein Urteil pro Finding, dann Stopp” ist eine Aufgabe, die es abschließt.
• Fixes tragen ein Änderungsbudget. Ein Finding, benannte Dateien, ein Zeilendeckel, kein angrenzendes Aufräumen:

Fix only finding SEC-014.
Allowed files: src/billing/ and its tests.
Budget: at most 3 files and 120 net lines. No new dependencies.
No adjacent cleanup, no refactors, no extra hardening.

Revalidate the finding first. Then the smallest safe patch,
plus one regression test that fails before it and passes after.

Stop when that test and the existing suite are green.
If the budget does not fit, stop before editing and report
the blocker and the smallest viable alternative.

• Gedächtnis lebt in Dateien, nicht im Chat. Dauerhafte Regeln gehören in eine kleine AGENTS.md [27]. Das aktuelle Deliverable und seine Haltebedingung gehören in ein Goal, den Mechanismus, den OpenAI für Ziele gebaut hat, die Compaction überleben müssen [28]. Entscheidungen und Zustand gehören in versioniertes Markdown, das OpenAIs eigene Anleitung für lange Läufe als Hauptverteidigung gegen Drift behandelt [29]. Die Unterhaltung ist ein Kommunikationskanal. Das Repository ist das Gedächtnis.

Nichts davon ist ein Plädoyer gegen Sol. Es ist der stärkste Weitwinkel-Reviewer, den ich benutzt habe; es fand echte Probleme, die Fable übersehen hatte, und derselbe 72-Stunden-Thread, der seine schlimmsten Schleifen dokumentiert, schreibt ihm auch zu, die Laufzeit einer komplexen parallelen Pipeline ungefähr halbiert zu haben [4]. Opus 5, so mein Argument im letzten Text, ist ein großartiger Mitarbeiter, der einen Chef braucht. Sol ist ein brillanter Ermittler, der einen Durchsuchungsbeschluss braucht: alles durchsuchen, nichts anfassen, und jede Behauptung kommt vor einen Richter. Die Intelligenz ist in beiden Häusern real. Was du jetzt konstruierst, ist das Organigramm.