Mein lang laufendes Codex-Ziel: Vier Tage und noch immer in Arbeit
Am 9. Oktober 2026 zeigte mein lang laufendes Codex-Ziel 4 Tage, 14 Stunden, 8 Minuten und 22 Sekunden an. Ich machte einen Screenshot, während Codex noch an einem SEO-Produkt arbeitete, das ich bisher nicht veröffentlicht habe. Das Ziel blieb offen, und es waren noch weitere Aufgaben zu erledigen.
Ich hatte Codex gebeten, den gesamten Plan für das noch nicht veröffentlichte SEO-Produkt abzuschließen, das ich entwickle. Bis dahin hatte ich es außerdem gebeten, mehr Agents zu verwenden, den Reasoning-Aufwand zu reduzieren, für Updates zu pausieren, nach einem Neustart fortzufahren und weniger Zeit mit wiederholten Tests zu verbringen.
Dies ist mein Bericht über ein lang laufendes Codex-Ziel: die Arbeit, die es hervorgebracht hat, die Arbeit, die es verlangsamt hat, und die Entscheidungen, die ich noch treffen musste. Es handelt sich um einen unfertigen Build, nicht um einen Benchmark oder eine Launch-Ankündigung.
Der obige Timer gehört zum Ziel. Er belegt keine vier Tage ununterbrochener Modellberechnung. Meine Sitzung umfasst ausdrückliche Pausen und Fortsetzungen, ein App-Update, einen Computerneustart, Tool-Ausführung und Wartezeiten.
Was ich Codex bauen ließ
Die Unterhaltung begann am 3. Oktober mit einer kleineren Frage: Haben Nutzer eigene Zugangsdaten, können sie sich mit Google anmelden und persönliche MCP-Schlüssel generieren?
Dann erweiterte ich die Anforderungen. Jeder Nutzer sollte seine eigenen Projekte sehen. Nutzer sollten Personen in einen Workspace einladen können. Ich wollte Einstellungen für persönliche Präferenzen und die Crawler-Konkurrenz. Die Plattform sollte schließlich kommerziell betrieben werden, mit einem kostenlosen Startangebot.
Ich stellte einen deutlich größeren SEO-Produktkatalog bereit, um den Build zu steuern. Der daraus entstandene Plan umfasste 15 Produktbereiche, 42 App-Referenzen und 19 öffentliche kostenlose Tools sowie eine Funktion zur Bewertung des Website-Traffics. Enthalten waren technisches SEO, Keyword-Recherche, Rankings, Backlinks, AI-Sichtbarkeit, Content, Analytics, Local SEO und spätere Enterprise-Funktionen.
Außerdem wollte ich, dass das Produkt Artikel über die Content-Engine hinter meiner eigenen Website bestellt.
Die Anweisung, den gesamten Plan abzuschließen, bezog sich daher auf eine umfangreiche Produkt-Roadmap. Ich habe diesen Umfang mitgestaltet. Ein Vier-Tage-Timer für eine kleine Fehlerbehebung würde eine andere Geschichte erzählen.
Welches Modell und welche Einstellungen ich verwendet habe
Das Hauptsitzungsprotokoll weist das Modell als GPT-6.1 Sol mit der Kennung gpt-6.1-sol aus. Die aufgezeichneten Durchläufe umfassen ultra, medium und eine kleine Anzahl von high-Reasoning-Einstellungen. Das identifiziert die Hauptsitzung; es belegt nicht, welches Modell hinter jedem Reviewer oder externen Tool stand.
Am 5. Oktober stellte ich den Aufwand ausdrücklich auf medium, um Tokens zu sparen. Anschließend deaktivierte ich aus demselben Grund turbo. Das waren meine Absichten, keine gemessenen Einsparungen: Ich habe keinen geprüften Kostenvergleich für die beiden Konfigurationen.
Ich bat außerdem um mehr parallele Agents. Die Sitzung nutzte delegierte Arbeit und Claude-Peer-Reviews für Teile der Implementierung. Dadurch konnten separate Aufgaben vorankommen, aber es entstand auch zusätzlicher Aufwand, um ihre Ergebnisse zusammenzuführen und das kombinierte Resultat zu überprüfen.
Mein früherer GPT-6.1-Sol-Vergleich→ behandelt veröffentlichte Modelldaten. Dieser Build ist eine andere Art von Beleg: ein reales Projekt mit sich veränderndem Umfang und wechselnden Einstellungen statt eines kontrollierten Vergleichs zwischen Modellen.
Wie lange kann ein Codex-Ziel weiterarbeiten?
In diesem Fall zeigte die Benutzeroberfläche für dasselbe laufende Ziel mehr als vier Tage an. Das ist die Beobachtung, die ich belegen kann. Es handelt sich nicht um eine Garantie für eine maximale Laufzeit, und ich kann die aktive Inferenzzeit anhand des Screenshots nicht berechnen.
OpenAI beschreibt Goals in Codex als Ziele, die über mehrere Durchläufe hinweg bestehen bleiben. Codex kann weiter auf ein Ergebnis hinarbeiten, während der Nutzer es pausieren oder fortsetzen kann. Abschluss, Unterbrechungen, Budgets und Blocker beeinflussen, ob die Arbeit weitergeht.
Meine Erfahrung passt zu diesem persistenten Workflow. Ich konnte nach Pausen zum selben Ziel zurückkehren und die nächsten Aufgaben steuern. Es war nützlich, das Ziel verfügbar zu halten. Dadurch wurde das Ziel jedoch nicht kleiner, und es wurde auch nicht sichergestellt, dass jeder neue Durchlauf das Produkt näher an den Launch brachte.
Was war bis zum 9. Oktober fertiggestellt?
Das Lieferprotokoll vom 9. Oktober verzeichnete 30 teilweise abgeschlossene Anforderungen, 39 nicht bewertete Anforderungen und null vollständig akzeptierte Anforderungen in einer Tracking-Liste mit 69 Punkten.
Diese Zahl braucht Kontext. Die Liste misst die breite Produktabnahme. Null vollständig akzeptierte Anforderungen bedeutet nicht, dass kein funktionierender Code vorhanden war. 30 teilweise abgeschlossene Anforderungen bedeuten ebenfalls nicht, dass das Produkt zu 43 Prozent fertig war.
Das Protokoll verzeichnet einen einmaligen lokalen Smoke-Test für eine unterstützte Account-Basis: den ersten Account erstellen, sich mit einem Passwort anmelden, die Session und den privaten Owner-Workspace lesen, sich anschließend abmelden und die alte Session ablehnen. Das ist ein konkreter Nutzerablauf mit einem begrenzten Testergebnis. Es ist kein Beweis dafür, dass die neueste vollständige Anwendung für Kunden bereit ist.
Weitere Fortschritte umfassten die lokale Integration der Passwort-Reset-Quelle, Entwürfe für Backlink-Reviews, Arbeiten an gespeicherten Search-Console-Berichten, den Transport eines GA4-Berichts mit Kunden-Token und Arbeiten an Artikel-zu-LinkedIn-Entwürfen. Bei mehreren dieser Teile war die Aktivierung noch deaktiviert, die Integration unvollständig oder die Verifizierung auf später verschoben.
Die datierten Checkpoints meldeten ausdrücklich keinen Commit, Push oder Deployment. Google-Login und die vollständige Kundenbereitschaft blieben unverifiziert. Ich hatte eine wachsende lokale Implementierung mit nützlichen Belegen, aber noch keine veröffentlichte Plattform.
Was hat mein lang laufendes Codex-Ziel verlangsamt?
Ich erweiterte das Ziel zu einer Produkt-Roadmap
Google-Login hinzuzufügen klingt nach einer einzelnen Funktion. Private Kunden hinzuzufügen verändert, wer auf Projekte, Berichte, Hintergrundjobs und Integrationen zugreifen darf. Ich wollte, dass diese Grenze in der gesamten Anwendung eingehalten wird.
Dann fügte ich Keyword-Recherche, Backlinks, Content-Generierung und einen deutlich größeren Katalog hinzu. Ein Teil der verstrichenen Zeit entfiel auf notwendige Arbeiten an einem umfangreichen Ziel. Mein ursprüngliches Ziel machte es leicht, immer wieder den nächsten unfertigen Bereich zu öffnen.
Der Verifizierungsprozess wurde zu repetitiv
Ich bat um quellenbasierte Entscheidungen, begrenzte Änderungen, Reviews und eindeutige Belege. Diese Anweisungen halfen dabei, vage Behauptungen zu vermeiden, etwas sei fertig.
Die Sitzung sammelte jedoch wiederholte Quellenprüfungen, die Vorbereitung von Reviews und Arbeiten an Test-Fixtures an. Meine Einschätzung ist, dass sich das Gleichgewicht zu stark in Richtung der Absicherung einzelner Teile verschob, bevor der nächste nutzbare Ablauf abgeschlossen war.
Am 9. Oktober sagte ich Codex, es solle nicht mehr so viel Zeit für Tests aufwenden, auf den Abschluss hinarbeiten und einen größeren Test auf später verschieben. Dadurch entfiel nicht die Notwendigkeit, die Account-Isolation zu überprüfen. Es änderte die Reihenfolge: gezielte Prüfungen während der Implementierung, gefolgt von einer umfassenderen Validierung des zusammengesetzten Ablaufs.
Einige Fehler gehörten zum Testaufbau
Ein Versuch mit der Passwort-Reset-Datenbank schlug fehl, weil bei einem synthetischen Account-Datensatz ein erforderliches Feld für den Anzeigenamen fehlte. Die Reparatur dieser Fixture war notwendig, um den Test auszuführen, aber sie war keine neue Produktfunktion.
Ein späterer lang laufender Datenbankversuch endete, als der Arbeitsplatz neu gestartet wurde. Das Lieferprotokoll behauptete nicht, dass dieser Versuch erfolgreich war. Eine anschließende Diagnose ergab wiederholte Berechnungen früherer Verifizierungsverträge und gepufferte Fortschrittsausgaben, wodurch der laufende Prozess schwerer einzuschätzen war.
Diese Details sind wichtig, weil Warten mehrdeutig ist. Ein laufender Prozess kann arbeiten, dieselbe Voraussetzung erneut berechnen oder Ausgaben erzeugen, die ich noch nicht sehen kann. Der Timer allein kann mir nicht sagen, welcher Fall vorliegt.
Mehr Agents erhöhten den Koordinationsaufwand
Parallele Arbeit half bei voneinander trennbaren Aufgaben. Die Hauptsitzung musste weiterhin die Ergebnisse prüfen, Abhängigkeiten auflösen und Änderungen in eine Anwendung integrieren. Ich kann keine Beschleunigung durch die zusätzlichen Agents zuschreiben, weil ich dasselbe Projekt nicht einmal mit und einmal ohne sie ausgeführt habe.
Die praktische Frage wurde, ob ein weiterer Agent einen unabhängigen Teil abschließen konnte oder ob er der Hauptsitzung lediglich eine weitere Übergabe bescherte.
Was ich weiterhin als Mensch tue
Ich bestimme die Produktrichtung und entscheide, welche Funktionen als Nächstes wichtig sind. Ich prüfe, ob der gemeldete Fortschritt funktionierendes Verhalten, lokalen Quellcode oder einen unverifizierten Vorschlag beschreibt. Ich pausiere die Arbeit, wenn ich Codex aktualisieren oder den Computer neu starten muss, und bitte es anschließend, vom gespeicherten Zustand aus fortzufahren.
Ich hinterfrage außerdem das Tempo. Während dieses Builds habe ich:
Der Plan und das Lieferprotokoll geben mir etwas, das ich über Chat-Nachrichten hinaus prüfen kann. Sie erfordern jedoch ebenfalls Disziplin: Ein datierter Checkpoint ist nur dann nützlich, wenn er festhält, was sich geändert hat und was weiterhin unbewiesen ist.
Die Erfahrung setzt den Zielkonflikt fort, den ich in Ich dachte, AI würde mir mehr freie Zeit verschaffen→ beschrieben habe. Ich kann versuchen, einen größeren Build umzusetzen, verbringe aber weiterhin Zeit damit zu entscheiden, was gebaut werden sollte, und das Ergebnis zu überprüfen.
Die bisherigen Vor- und Nachteile
In meiner Erfahrung mit diesem Build ist der größte Vorteil die Kontinuität. Ich kann ein umfangreiches Ziel offenhalten und nach Unterbrechungen fortsetzen. Codex hat lokale Implementierungen erstellt, Fehler untersucht und detaillierte Aufzeichnungen geführt, die mir bei der Überprüfung der Arbeit helfen.
Es kann außerdem mehrere Arten von Arbeit innerhalb desselben Projekts bewältigen: Datenbankänderungen, API-Verhalten, Frontend-Abläufe, Integrations-Transporte und Dokumentation. Dadurch wird ein umfangreicher Build möglich, den ich steuern kann.
Der Nachteil ist, dass Aktivität wie Fortschritt aussehen kann. Viele erfolgreiche Prüfungen können neben einem unfertigen Produkt bestehen. Hoher Reasoning-Aufwand und mehr Agents bringen Budget- und Koordinationsentscheidungen mit sich, ohne eine schnellere Lieferung zu garantieren.
Lange Läufe erschweren außerdem die Disziplin beim Umfang. Eine teilweise abgeschlossene Roadmap bietet dem Agent viele vertretbare nächste Schritte. Ich muss entscheiden, welcher davon das nächste nützliche Ergebnis liefert.
Ich würde ein persistentes Ziel wieder verwenden, aber jeder Implementierungsphase ein kleineres Abnahmekriterium geben. Zum Beispiel: einen Account erstellen, sich anmelden, den privaten Workspace sehen und den Zugriff eines zweiten Accounts ablehnen. Die größere Roadmap als Kontext beibehalten, diesen Ablauf abschließen und dann weitermachen.
Was ich als Nächstes messen werde
Das SEO-Produkt befindet sich weiterhin in der Entwicklung und war am 9. Oktober noch nicht veröffentlicht. Die nächste nützliche Messung ist ein vollständiger Nutzerablauf gegen die aktuell zusammengesetzte Anwendung, mit einer ausdrücklich aufgeführten Liste der verbleibenden Blocker.
Danach möchte ich Belege für Google-Login, kundenbezogene Integrationen, persönliche MCP-Schlüssel und einen sicheren Release. Codex arbeitet weiterhin Aufgaben ab; dieser Artikel dokumentiert den Stand vom 9. Oktober. Ich werde den Build anhand dieser Ergebnisse beurteilen und nicht danach, wie lange das Ziel offen bleibt.
Quellen und Grenzen dieses Berichts
Der Timer stammt aus meinem obigen Screenshot. Die Modellkennung, Änderungen an den Einstellungen und meine Eingriffe stammen aus dem Verlauf der Hauptsitzung. Umfang und Fortschrittszahlen stammen aus dem Projektplan und seinem datierten Lieferprotokoll. Diese Projektaufzeichnungen sind private Arbeitsdokumente; ich habe die Protokolle oder Kundendaten nicht veröffentlicht.
OpenAIs Using Goals in Codex erklärt den Workflow mit persistenten Zielen. Es unterstützt die Beschreibung von Goals, nicht die Lieferangaben zu meinem Projekt.
Die Zahl von 69 Punkten ist eine breite Momentaufnahme der Abnahme und kein Maß für die verbleibenden Stunden. Der Screenshot beweist keine ununterbrochene Inferenz, die Änderungen an den Einstellungen beweisen keine Kosteneinsparungen, und lokale Prüfungen belegen keine Produktionsreife. Dieser Build ist weiterhin in Arbeit.
*Dieser Artikel wurde mit Unterstützung von AI anhand meines Screenshots, des Sitzungsverlaufs und der Lieferaufzeichnungen des Projekts verfasst. Er beschreibt einen einzelnen laufenden Build. Er stellt keine allgemeine Codex-Laufzeitgrenze, kein Modellranking, keine geprüften Kosten und keine Produktionsreife fest.*