OpenAI testet Dauermodus für Codex
In Codex steckt ein Modus namens Persistent. Er bricht nicht nach Minuten ab, legt sich selbst Folgeaufgaben an und meldet sich unaufgefordert.
Im Programmierwerkzeug Codex von OpenAI steckt ein bisher unangekündigter Betriebsmodus. WIRED fand am 27. August 2026 im öffentlich zugänglichen Code eine Einstellung mit der Bezeichnung Persistent, die den Agenten weiterarbeiten lässt, bis ihn jemand ausdrücklich stoppt. OpenAI bestätigte gegenüber WIRED, dass die Funktion getestet wird, nannte aber keinen Starttermin und erklärte, es gebe keine unmittelbaren Pläne für eine Veröffentlichung.
Der Fund ist deshalb bemerkenswert, weil er eine Grenze verschiebt, die bisher technisch gesetzt war. Agenten laufen heute in einem Zeitfenster: Sie bekommen einen Auftrag, arbeiten ihn ab und beenden sich, auch wenn die Aufgabe unfertig ist.
Was im Code steht
Der Modus erscheint im Menü für die Reasoning-Anstrengung, also dort, wo Nutzer bislang zwischen schnellen und gründlichen Durchläufen wählen. Verfügbar ist er nach dem Fund bisher nur in der Kommandozeilenfassung von Codex. Laut der von WIRED eingesehenen Implementierung darf der Agent in diesem Modus Rechenleistung, Token und Zeit länger beanspruchen als in den bestehenden Stufen, die nach Minuten oder Stunden abbrechen.
Dazu kommen zwei Funktionen, die eher die Arbeitsweise als die Laufzeit betreffen. Die erste weist den Agenten an, sich nach Abschluss eines Auftrags selbst Folgeaufgaben anzulegen und diese über einzelne Sitzungen hinweg abzuarbeiten. Die zweite ist ein Werkzeug, mit dem er den Nutzer von sich aus anschreiben kann, verbunden mit der Anweisung, davon sparsam Gebrauch zu machen.
Eine Schranke ist im Code ebenfalls angelegt: Änderungen außerhalb des Nutzersystems erfordern nach der Anleitung eine Freigabe. Der Agent darf also lange laufen und sich selbst beschäftigen, soll aber nicht ohne Zustimmung nach außen wirken.
Persistent mode is a new level of reasoning effort that will make Codex continue working until put to sleep. The agent will also proactively create follow up tasks for itself.
So beschreibt Max Zeff, der die Funktion für WIRED gefunden hat, den Kern der Sache. Die Formulierung „until put to sleep" stammt dabei aus dem Code selbst.
Warum das nicht nur eine längere Laufzeit ist
Ein Agent, der nach zwanzig Minuten abbricht, ist gut kalkulierbar. Der Auftrag hat ein Ende, die Kosten haben eine Obergrenze, und wenn etwas schiefläuft, ist der Schaden auf dieses Fenster begrenzt. Fällt die Zeitgrenze weg und legt sich der Agent zusätzlich eigene Aufgaben an, ändern sich alle drei Punkte gleichzeitig.
Die Kostenseite ist die konkreteste. Eine Auswertung des OpenRouter-Analysten Peter Walker, über die THE DECODER am 23. August berichtete, zeigt, wie schnell sich Agentenbetrieb summiert: Der Token-Verbrauch von Agenten stieg dort seit Februar 2026 von 0,51 auf 7,3 Billionen Token, etwa das Vierzehnfache. Der Verbrauch durch Menschen wuchs im selben Zeitraum nur um das 2,8-Fache. Wer Agenten dauerhaft laufen lässt, zahlt nicht mehr pro Nutzer, sondern pro Maschinenlaufzeit.
Die zweite Seite betrifft das Verhalten über lange Zeiträume. Beim Erscheinen von GPT-5.6 Sol zeigte sich in Tests, dass Aufforderungen zur Beharrlichkeit den Agenten zu kontraproduktiven Handlungen bewegen konnten, in einzelnen Fällen bis zum Löschen von Daten. Ein Modus, der genau diese Beharrlichkeit zum Normalfall macht, braucht entsprechend belastbare Schranken.
Einzuordnen ist der Fund in eine Richtung, die OpenAI seit Monaten verfolgt. Sam Altman hat mehrfach beschrieben, ChatGPT solle sich zu einem persönlichen Assistenten entwickeln, der Aufgaben eigenständig übernimmt. Ein Agent, der zwischen zwei Gesprächen weiterarbeitet, ist dafür die technische Voraussetzung.
Was das für Ihr Unternehmen heißt
- Klären Sie, wer einen Agenten schlafen schicken darf. Wenn das Ende eines Laufs nicht mehr automatisch kommt, wird das Beenden zur Rolle. Diese Rolle sollte benannt sein, bevor der erste Dauerlauf startet.
- Stellen Sie die Kostenrechnung von Auftrag auf Zeit um. Budgets, die pro Anfrage kalkuliert sind, greifen bei laufenden Agenten nicht mehr. Sinnvoll sind Limits pro Projekt und Zeitraum sowie eine Auswertung, die den Verbrauch je Agent sichtbar macht.
- Prüfen Sie, was der Agent ohne Rückfrage anfassen darf. Die Freigabepflicht für Änderungen außerhalb des eigenen Systems ist die entscheidende Grenze. In der eigenen Umgebung gehört festgelegt, wo sie verläuft: Repository, Ticketsystem, Produktivdaten.
- Regeln Sie unaufgeforderte Meldungen, bevor sie kommen. Ein Agent, der sich von selbst meldet, erzeugt Aufmerksamkeit, die jemand verarbeiten muss. Legen Sie fest, über welchen Kanal solche Nachrichten laufen und wer sie liest.
- Setzen Sie Folgeaufgaben eine Grenze. Selbst angelegte Anschlussarbeiten sind der Punkt, an dem Aufwand unbemerkt wächst. Eine Obergrenze für die Zahl der Folgeaufgaben und ein Protokoll darüber, was der Agent sich selbst aufgetragen hat, halten das nachvollziehbar.
Einordnung für die Praxis
Für den Alltag ändert sich zunächst nichts: Der Modus ist nicht veröffentlicht, OpenAI nennt keinen Termin, und der Fund stammt aus dem Code, nicht aus einer Ankündigung. Wer heute Codex einsetzt, arbeitet weiter mit begrenzten Läufen.
Interessant ist der Vorgang trotzdem, weil er zeigt, woran gearbeitet wird. Die bisherigen Zeitgrenzen bei Agenten sind vor allem eine Schutzfunktion, und wenn sie fällt, muss der Schutz aus der Organisation kommen statt aus dem Werkzeug. Die Fragen dazu lassen sich vorab beantworten, unabhängig davon, ob der Modus in dieser Form erscheint: Wer beendet, wer zahlt, wer liest mit, und wo endet die Zuständigkeit des Agenten.
Wenn Sie wissen möchten, wie sich Agenten in Ihren Abläufen mit sauberen Grenzen, Budgets und Freigaben einsetzen lassen, sehen wir uns das gern gemeinsam an.
