GPT-5.6 Sol betreibt Overengineering. Ich nutze es trotzdem

GPT-5.6 Sol betreibt bei meinen Coding-Aufgaben Overengineering. Trotzdem ist es das beste Modell, das ich für die Suche nach Risiken eingesetzt habe. Bei einem Release-Audit lieferte es rund 400 mögliche Probleme, Fable 5 nur 70. Die meisten fielen bei der Triage durch, einige waren jedoch echt. Heute arbeitet Sol bei mir read-only, während ein anderes Modell über Patches entscheidet.

Betreibt GPT-5.6 Sol Overengineering? Das Muster wiederholt sich

Ja, GPT-5.6 Sol hat meine Aufgaben wiederholt unnötig aufgebläht, und mehrere Berichte auf r/codex beschreiben dasselbe Verhalten. Im klarsten direkten Vergleich bearbeiteten Sol 5.6 High und Fable 5 High dieselbe Aufgabe. Einige Implementierungen von Sol waren dreimal so groß [2].

Ein Beispiel betraf einen DynamoDB-Backfill, den Fable in ungefähr 100 Zeilen erledigte. Sols Variante brauchte rund 400 Zeilen und ergänzte Schutz vor Race Conditions, eine erneute Prüfung nach dem Schreiben sowie Logik für den Wechsel zwischen konsistenten und nicht konsistenten Lesevorgängen. Keine dieser Ergänzungen machte den Code falsch, doch zusammen erschwerten sie das Verständnis und die Prüfung einer einfachen Änderung [2].

Ein anderer Effort oder Modus beseitigt das Verhalten nicht. Ein Nutzer gab Sol auf xhigh einen klaren Plan mit ausdrücklichen Scope-Grenzen und sah trotzdem zu, wie es „Edge Cases von Edge Cases“ verfolgte [3]. Ein anderer hatte am dritten Tag eines Sol-Ultra-Laufs noch nicht den ersten großen Meilenstein erreicht, weil kleine Bugs und zusätzliche Absicherungen das Hauptziel immer wieder verdrängten [4].

Derselbe Thread zeigt, wie schnell diese Hartnäckigkeit eine Änderung vergrößert. Ein Audit mit automatischen Fixes schrieb ganze Bereiche einer Website um, sodass der Nutzer die Hälfte zurücksetzen musste. Ein anderer Auftrag machte aus einem funktionierenden index + 1-Fix mehr als 1.000 geänderte Zeilen [4]. Mehrere Nutzer ziehen deshalb High vor, weil es näher am Hauptziel bleibt und weniger Koordination verursacht [5]. Andere berichten von Review-Schleifen, die bereits gelöste Probleme erneut öffnen, darunter eine Schleife mit acht Stunden Laufzeit [6].

In der Diskussion über GPT-5.6 auf Hacker News zeigt sich eine ähnliche Arbeitsteilung. Dort beschreiben Nutzer Codex als strengen Reviewer und Claude als bessere Wahl für schwierige Probleme und High-Level-Design [7]. Die Berichte aus der Community zeigen, dass das Verhalten wiederkehren kann. OpenAIs eigene Dokumente helfen zu erklären, warum.

OpenAI sagt selbst, dass Sol über die Absicht des Nutzers hinausgehen kann

OpenAIs System Card zu GPT-5.6 sagt, dass Sol häufiger über die Absicht des Nutzers hinausgeht als GPT-5.5 und dabei auch versuchen kann, nicht verlangte Aktionen auszuführen. OpenAI bezeichnet die absoluten Werte zwar als niedrig, empfiehlt bei langen Coding-Agent-Läufen aber trotzdem Aufsicht [8].

Der Prompting-Guide macht daraus eine praktische Regel: Setze klare Grenzen für Autonomie und Freigaben. Außerdem sollst du Erklärung, Review und Planung von der Implementierung trennen [9]. Der Codex-Modellguide ergänzt, dass Ultra maximales Reasoning mit automatischer Delegation verbindet. Zum Start beschrieb OpenAI vier parallele Agenten als Standardeinstellung [1], empfiehlt Ultra aber nur für Aufgaben mit tatsächlich unabhängigen Teilen. Die meisten Aufgaben brauchen laut OpenAI weder Max noch Ultra [10].

Diese Dokumente machen meine Erfahrung verständlicher. Sol soll ein Ziel hartnäckig verfolgen, während ein höherer Effort und zusätzliche Agenten diesem Verhalten mehr Spielraum geben. Ein Prompt wie „mach das produktionsreif“ nennt zwar eine Richtung, aber keinen Haltepunkt. Den muss ich selbst festlegen. Als OpenAI GPT-6 Astra veröffentlichte, habe ich geprüft, ob das neuere Modell den Umfang in Codex besser einhält als Sol.

Was ist mit Sols Kontextfenster passiert? Codex fiel auf 272K

Über die API akzeptiert GPT-5.6 Sol weiterhin 1,05 Millionen Input-Tokens und kann bis zu 128K Output-Tokens erzeugen [11]. Das Abo-Produkt ist anders: OpenAIs Hilfecenter nennt für Sol in ChatGPT Business ein Kontextfenster von 272K [12]. Die API-Spezifikation beschreibt nicht, wie viel Kontext im Abo verfügbar ist.

Dieses Limit änderte sich vier Tage nach dem Start. Ein GitHub-Issue in openai/codex dokumentiert, wie das Serverprofil am 13. Juli von 372.000 rohen Tokens (353.400 effektiv) auf 272.000 (258.400 effektiv) fiel, eine Verringerung um 26,9 % [13]. Ein OpenAI-Mitarbeiter schrieb später auf X, das größere Profil habe das Abo-Kontingent zu schnell verbraucht und werde zurückkehren [14]. Am 29. Juli 2026 zeigte OpenAIs Dokumentation weiterhin 272K [12]. Später änderten sich die Abo-Limits erneut, und ich beschreibe, warum Codex Plus die Arbeit stoppen kann, obwohl noch Wochenkontingent übrig ist.

Claudes Hilfecenter dokumentiert dagegen für Fable 5 und Opus 5 in Claude Code auf Bezahlplänen ein Kontextfenster von 1M Tokens [15]. Dieser Unterschied ist bei langen Läufen wichtig, weil frühere Scope-Entscheidungen in einem kleineren Arbeitskontext eher durch die Compaction gehen.

Daten als Tabelle anzeigen

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

Die Grafik macht den Produktunterschied konkret: Claude Code gibt den konkurrierenden Claude-Modellen derzeit fast viermal so viel Kontext wie Sol im Abo [15].

Codex verwaltet einen vollen Kontext, indem es ältere Teile der Unterhaltung zusammenfasst. Die automatische Compaction und der Befehl /compact verdichten den sichtbaren Chat; OpenAIs Best-Practices-Seite rät zugleich davon ab, ein ganzes Projekt in einer Unterhaltung zu halten [16].

Genau dort wird das kleinere Fenster für meinen Ablauf zum Problem. Nach der Compaction fehlen in meinen Sol-Sitzungen oft die Vorgaben, die den Scope begrenzen: akzeptierte Risiken, bewusst verworfene Funktionen oder ein schlichtes „kein Overengineering“. OpenAIs Subagent-Dokumentation bezeichnet verwandte Probleme als Context Pollution und Context Rot [17]. Nicht der Code wird unsicher. Verloren geht die Vereinbarung darüber, was Sol in Ruhe lassen soll.

Warum ist Sol Ultra schwer zu steuern? Koordination wird selbst zur Arbeit

Sol Ultra fügt Agenten hinzu, ohne den Hauptagenten auf die Delegation zu beschränken. OpenAIs Dokumentation erklärt, dass die Software Agenten-Threads erstellen, verteilen und einsammeln kann, während der Hauptagent weiter liest, nachdenkt und implementiert [17]. So entsteht mehr Kapazität, aber keine entsprechende Grenze dafür, wer welche Aufgabe übernimmt.

Zwei Berichte im openai/codex-Repository auf GitHub zeigen die möglichen Kosten. Im ersten hielt der Hauptagent einen langsamen, aber funktionierenden Subagenten für festgefahren und wiederholte dessen Arbeit ohne Hinweis an den Nutzer. Das verbrauchte weitere Tokens und füllte den Hauptkontext mit doppeltem Material [18].

Im zweiten Bericht entfielen 19,8 % des rohen Tokenvolumens eines Nutzers auf Warte- und Status-Turns. Das Modell setzte alle 30 bis 60 Sekunden neu ein, um Agenten zu prüfen, die normal weiterarbeiteten [19]. Die Zahl stammt aus Nutzertelemetrie und nicht aus Abrechnungsdaten. Der praktische Punkt bleibt: Die Koordination der Arbeiter kann selbst zu einer erheblichen Aufgabe werden.

Mein frustrierendster Fall war ein Briefing für eine Systemarchitektur. Fable 5 erstellte in ungefähr einer Stunde einen einheitlichen Entwurf. Sol Ultra brauchte rund vier Stunden, weil es ein eng verbundenes Problem unter parallelen Agenten aufteilte und anschließend deren widersprüchliche Annahmen auflösen musste.

Anthropics Engineering-Team fand im eigenen Multi-Agent-System dieselbe Grenze: Parallele Arbeit lohnt sich, wenn eine breite Aufgabe unabhängige Stränge enthält. Beim Programmieren gibt es meist weniger solcher unabhängigen Teilaufgaben als bei Recherche. Anthropic berichtet außerdem, dass seine Multi-Agent-Läufe ungefähr 15-mal so viele Tokens wie ein normaler Chat verbrauchten [20]. Bei Architektur kann zu viel Parallelität mehr Koordinationsarbeit schaffen, als sie einspart. Später berichtete OpenAI von einem noch seltsameren Koordinationsproblem, als seine internen Agenten den gemeinsamen Artifactory-Speicher zum Messageboard machten.

Ultra kann außerdem von einem veralteten Punkt der Unterhaltung aus antworten. Zweimal bat ich Sol um ein Statusupdate, erhielt eine brauchbare Antwort und sah eine halbe Stunde später, wie es dieselbe Nachricht erneut beantwortete. Auf GitHub gibt es sehr ähnliche Codex-Berichte: Eine Session lieferte eine Antwort aus vielen Turns zuvor zurück [21], während ein anderes Issue beschreibt, wie Codex auf eine frühere statt auf die neueste Nachricht antwortete [22].

Danach vertraue ich der Unterhaltung nicht mehr als Aufzeichnung des aktuellen Stands. Ich prüfe das Repository mit git und der Testsuite und verschiebe die Aufgabe in eine neue Session.

Mein Release-Audit: Sol fand mehr, Fable urteilte besser

Sol Ultra lieferte in meinem Release-Audit rund 400 mögliche Probleme, Fable 5 dagegen etwa 70. Die meisten zusätzlichen Findings von Sol fielen bei der Triage durch, einige deckten jedoch echte Probleme auf, die Fable übersehen hatte. Sol war bei der breiten Suche klar besser; Fable entschied besser, was davon wichtig war.

Vor dem Release gab ich beiden Modellen dasselbe große Produktionssystem und dasselbe Read-only-Briefing zu Sicherheit, Logik und Konsistenz über Servicegrenzen hinweg. Sols Liste enthielt viele Findings mit hoher Severity, während Fable die kritischen Probleme zuerst nannte und sich für die zahlreichen Möglichkeiten mit mittlerer Severity kaum interessierte.

Findings von Sol Ultra

400

viele Ergebnisse mit hoher und mittlerer Severity

Findings von Fable 5

70

gleiches Briefing, kritische Probleme zuerst

Die Grafik vergleicht die Menge der Ergebnisse, nicht die Zahl bestätigter Bugs. Ich ließ Fable alle 400 Sol-Findings als unbewiesene Behauptungen behandeln und einzeln prüfen. Dabei lehnte es viele Duplikate, theoretische Edge Cases und Härtungsvorschläge ab, die Sol als Bugs präsentiert hatte, bestätigte aber auch mehrere echte Probleme, die das eigene Audit übersehen hatte. Sols breitere Suche war nützlich, allerdings erst nachdem eine getrennte Prüfung das Rauschen entfernt hatte.

Artificial Analysis weist in zwei Benchmarks auf denselben Unterschied hin. Sol Max führt den Coding Agent Index mit 80 Punkten an, Fable 5 liegt dahinter; im breiteren Intelligenz-Index führt dagegen Fable mit 60 zu 59 und hat bei der analytischen Qualität einen deutlicheren Vorsprung [23]. Diese Bewertungen bilden mein Audit nicht nach, stützen aber die engere Aussage, dass das Finden von Kandidaten und ihre Beurteilung verschiedene Fähigkeiten sind.

In der Launch-Woche ignorierte ich diesen Unterschied und ließ Sol jeden Punkt der eigenen Liste beheben. Viele einzelne Änderungen wirkten vernünftig, doch das Gesamtergebnis konnte ich nicht sicher ausliefern. Am Ende verbrachte ich ein Wochenende damit, die zusätzliche Arbeit wieder zu entfernen.

OpenAIs Sicherheitsdokumentation empfiehlt inzwischen fast genau den Ablauf, den ich hätte nutzen sollen. Sie rät dazu, ein Finding zu akzeptieren und einen begrenzten Patch zu erzeugen, statt alle Scan-Ergebnisse in einem Chat beheben zu lassen [24]. Außerdem empfiehlt sie die kleinste sichere Änderung mit einem gezielten Regressionsnachweis und eine separate Aufgabe pro Finding [25]. Vor allem bleiben importierte Findings unbewiesen, bis eine Read-only-Triage für jedes ein Urteil abgegeben hat [26]. Diese Trennung macht aus Sols langer Liste eine brauchbare Grundlage für den Review statt einer unkontrollierten To-do-Liste.

So nutze ich GPT-5.6 Sol: breit prüfen, eng begrenzt patchen

Ich überlasse Sol die breite Suche, gebe ihm aber keine Erlaubnis, den Code zu ändern. Ein anderes Modell entscheidet, welche Findings echt sind; danach behebt ein eng begrenzter Agent jeweils ein akzeptiertes Problem. So bleibt Sols größte Stärke erhalten, ohne dass das Modell Scope, Budget oder das Ende der Arbeit bestimmt.

Architektur

• Fable 5 erstellt einen einheitlichen Entwurf

feste Vorgaben

Audit

• Sol Ultra breite Suche mit Lesezugriff

Behauptungen, keine Fakten

Triage

• Fable 5 ein Urteil pro Finding

freigegebene Liste

Fix

• Begrenzter Agent ein Finding, Änderungsbudget

Die Aufteilung ist einfach: Fable übernimmt Architektur und endgültige Entscheidungen, Sol sucht nach möglichen Problemen, und der implementierende Agent erhält eine begrenzte Aufgabe statt eines allgemeinen Auftrags. Drei praktische Regeln halten diese Rollen aufrecht:

• Audits bleiben read-only und bekommen ein eindeutiges Ende. „Mach weiter, bis keine Probleme mehr übrig sind“ lässt Sol unbegrenzt suchen; „ein Durchgang, ein Urteil pro Finding, dann Stopp“ beschreibt dagegen eine Aufgabe, die es abschließen kann.
• Jeder Fix erhält ein Änderungsbudget. Nenne das Finding und die erlaubten Dateien, setze ein Zeilenlimit und verbiete Aufräumarbeiten ohne Bezug zur Aufgabe:

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.

• Dauerhafte Entscheidungen gehören ins Repository. Stabile Regeln gehören in eine kurze AGENTS.md [27]. Das aktuelle Ziel und seine Stoppbedingung stehen in einem Goal, das OpenAI dafür entwickelt hat, Ziele über die Compaction hinweg zu bewahren [28]. Entscheidungen und der aktuelle Stand stehen in versioniertem Markdown, wie OpenAIs Anleitung für lange Aufgaben empfiehlt [29]. Der Chat bleibt für Diskussionen nützlich, sollte aber nicht der einzige Ort sein, der den Auftrag festhält.

Dieser Ablauf macht Sol nicht zu einem bloßen Warnhinweis. Sol bleibt der stärkste Reviewer, den ich für groß angelegte Audits eingesetzt habe, und hat echte Probleme gefunden, die Fable übersehen hatte. Selbst der „72 hours“-Thread mit seinen schweren Schleifen schreibt Sol zu, die Laufzeit einer komplexen parallelen Pipeline fast halbiert zu haben [4]. Wichtig ist, diese Fähigkeit dort einzusetzen, wo sie hilft.

In meinem vorherigen Artikel über Opus 5 argumentierte ich, dass auch ein leistungsfähiges Modell klare Führung braucht. Meine Regel für Sol ist strenger: alles durchsuchen, nichts ändern und jede Behauptung einem getrennten Prüfer vorlegen. So behalte ich die breitere Suche, ohne Sol die Erlaubnis zu geben, die Aufgabe zu vergrößern.