OpenAIs GPT-5.1-Codex-Max und der Compaction-Ansatz für lang laufende Agenten

Was Compaction tatsächlich verändert

Die zentrale Aussage des System Cards ist eng gefasst und technisch: GPT-5.1-Codex-Max ist OpenAIs erstes Modell, das "nativ darauf trainiert ist, über mehrere Context Windows hinweg zu arbeiten – durch einen Prozess namens Compaction – und dabei über Millionen von Tokens hinweg innerhalb einer einzigen Aufgabe kohärent zu bleiben."

Das ist eine andere Wette als das schlichte Vergrößern eines Context Windows. Compaction bedeutet, dass das Modell lernt, seinen eigenen Arbeitszustand zusammenzufassen und weiterzutragen, sobald ein Window erschöpft ist und es ins nächste übergeht – anstatt sich auf ein externes Gerüst zu verlassen, das den Kontext zusammenflickt.

Für alle, die lang laufende Coding-Agenten bauen, ist genau das der Punkt, den man im Blick haben sollte. Der typische Fehlerfall bei mehrstufigen Agenten liegt meist nicht im reinen Reasoning – es geht darum, den Faden über eine Aufgabe hinweg zu verlieren, die sich über Tausende von Tool-Calls erstreckt. Dieses Verhalten dem Modell selbst anzutrainieren, statt es mit Retrieval und manueller Zusammenfassung nachträglich anzuflicken, ist eine Aussage darüber, wo OpenAI diese Verantwortung ansiedelt sieht.

Trainiert auf die eigentliche Arbeit, nicht nur auf den Benchmark

Das Dokument macht ausdrücklich klar, dass das Modell auf "realen Software-Engineering-Aufgaben wie PR-Erstellung, Code-Reviews, Frontend-Coding und Q&A" trainiert wurde – aufbauend auf einem aktualisierten Basis-Reasoning-Modell, das über Software Engineering, Mathematik, Forschung, Medizin und Computerbedienung hinweg trainiert wurde.

Diese Ausrichtung – PR-Erstellung und Code-Review als zentrale Trainingsziele – zeigt, wofür das Modell gedacht ist. Es wird nicht als Autocomplete-Engine positioniert, sondern als etwas, das am gesamten Workflow rund um eine Änderung teilnehmen soll: sie vorschlagen, sie überprüfen, Fragen dazu beantworten.

Die Schutzmaßnahmen liegen auch auf Produktebene

OpenAI unterteilt seine Sicherheitsarbeit in zwei Kategorien, und die zweite ist die, die Teams in der praktischen Anwendung genau lesen sollten. Neben dem Training des Modells gegen schädliche Aufgaben und Prompt-Injections nennt das Dokument "produktseitige Schutzmaßnahmen wie Agent-Sandboxing und konfigurierbaren Netzwerkzugriff."

Für einen Agenten, der Code ausführt, ist der Netzwerkzugriff der eigentliche Risikofaktor. Ihn konfigurierbar zu machen, ist ein Eingeständnis, dass ein gegen Prompt-Injection trainiertes Modell allein nicht ausreicht, um zu begrenzen, was der Agent erreichen kann. Diese Arbeitsteilung – Widerstandsfähigkeit auf Modellebene plus Eindämmung auf Produktebene – ist die praktische Haltung, die das Dokument einnimmt.

Wo es sich im Preparedness Framework einordnet

Das Dokument ordnet das Modell präzise auf OpenAIs Fähigkeitsskala ein. Es ist "im Bereich Cybersecurity sehr leistungsfähig, erreicht aber nicht die hohe Fähigkeitsstufe bei Cybersecurity" und erreicht diese auch nicht bei KI-Selbstverbesserung. Im Bereich Biologie wird es als hoch leistungsfähig eingestuft und mit demselben Schutzmaßnahmen-Paket ausgeliefert wie GPT-5.

Wir erwarten, dass sich der aktuelle Trend rasant steigender Fähigkeiten fortsetzt und Modelle in naher Zukunft die Schwelle zur hohen Cybersecurity-Fähigkeit überschreiten werden.Montana Labs

Dieser Satz ist die vorausschauendste Aussage im gesamten Dokument. OpenAI sagt damit, dass ein Coding-Modell, das knapp unter der Cybersecurity-Schwelle liegt, ein Übergangszustand ist – kein stabiler.

Die Implikation: Agenten-Eindämmung ist jetzt das eigentliche Engineering-Problem

Betrachtet man Compaction-Fähigkeit und Netzwerkzugriffskontrollen zusammen, führen beide zur selben Schlussfolgerung. Ein Modell, das eine Aufgabe kohärent über Millionen von Tokens hinweg steuern kann, kann auch viele autonome Schritte ausführen, bevor ein Mensch das Ergebnis sieht – wodurch Sandboxing und Netzwerkkonfiguration zu den eigentlichen Stellschrauben werden, die sein Verhalten begrenzen.

Für Teams, die GPT-5.1-Codex-Max einsetzen, geht es weniger darum, gute Prompts zu schreiben, sondern vielmehr darum, zu entscheiden, worauf das Modell während eines langen Laufs zugreifen darf. Das System Card behandelt das als OpenAIs Verantwortung auf Produktebene; in der Praxis landet die Entscheidung bei denjenigen, die den Agenten in ihre eigenen Systeme einbinden.