Codex /goal nutzen: Fortsetzung, Steuerung, Abschlusskriterien und Tokenbudgets

Wenn Sie Codex immer wieder „weiter“ schreiben, können Sie mit /goal die Abschlusskriterien festhalten. Das eignet sich etwa dafür, einen Fehler zu reproduzieren, zu beheben und anhand der Testergebnisse den nächsten Schritt zu wählen. Es ist mehr als eine Anweisung, lange zu arbeiten: Die Bedingungen für den Abschluss bleiben im selben Chat erhalten.

Dieser Leitfaden erklärt, wann die Funktion sinnvoll ist, wie sich Desktop und CLI bedienen lassen und was bei einem Stopp zu prüfen ist. Außerdem zeigt er, weshalb das Tokenbudget eines Ziels weder mit dem verbleibenden Plankontingent noch mit einer Obergrenze für die Rechnung gleichzusetzen ist.

Spezifikationen geprüft am 7. Oktober 2026. Die Erklärung beruht auf offiziellen OpenAI-Dokumenten. Für diesen Artikel haben wir Goal mode nicht ausgeführt und weder Laufzeit noch Verbrauch oder Auswirkungen auf die Ergebnisse gemessen.

1. Was /goal leistet: normale Aufträge, /plan und dot

/goal legt ein fortlaufendes Ziel in einem Codex-Chat fest. Wenn unterwegs ein Test fehlschlägt, kann Codex den nächsten Schritt anhand der ursprünglichen Abschlusskriterien wählen. OpenAI nennt Fehlersuche, Leistungsverbesserungen, Migrationen und Recherche als Beispiele, bei denen die Untersuchungsergebnisse den nächsten Schritt bestimmen.

Die offizielle Erklärung beschreibt ein Ziel als im aktuellen Chat gespeicherten Zustand. Es ist weder ein globales Gedächtnis, das automatisch in anderen Chats gilt, noch eine Regel für das gesamte Repository. Der nötige Code, die Tests und die Dokumente müssen weiterhin aus diesem Chat zugänglich sein. Quelle: OpenAI Cookbook: Using Goals in Codex.

Allein das Erstellen eines Plans startet keine automatische Fortsetzung durch Goal mode. Auch garantiert /goal keine unabhängige Prüfung durch ein anderes Modell. Zum Unterschied gegenüber dot siehe dot nutzen: Preise und Delegation an Codex. Zur Bereitstellung von Informationen siehe Context Engineering.

2. Auf Desktop, in CLI und IDE starten

Obwohl alle /goal verwenden, unterscheiden sich die Bedienelemente nach dem Start je nach Oberfläche. Der offizielle Leitfaden für länger dauernde Arbeit beschreibt den Start auf Desktop, in der CLI und in der IDE-Erweiterung. Im Web-Abschnitt geht es darum, ChatGPT Work Ergebnis, Vorgaben und Bewertungskriterien mitzuteilen; daraus folgt nicht, dass die Weboberfläche denselben Befehl und dieselben Bedienelemente bietet.

Für die CLI nennt das OpenAI Cookbook Codex ab Version 0.128.0 als unterstützt. Die aktuelle Konfigurationsreferenz beschreibt features.goals als stabile, standardmäßig aktivierte Funktion. Gehen Sie nicht davon aus, dass frühere Anweisungen zum Aktivieren einer experimentellen Funktion weiterhin in Ihre Konfiguration gehören. Wenn die Funktion fehlt, prüfen Sie Oberfläche, Version und die aktuellen offiziellen Hinweise.

Quellen: Länger dauernde Arbeit, Desktop-Slash-Befehle und Konfigurationsreferenz. Die Anweisungen dieses Artikels erklären die Funktion der Bedienelemente; sie sind keine in jeder App-Version überprüfte Liste von Schaltflächenbeschriftungen.

3. Abschlusskriterien: unklare Ziele prüfbar machen

„Mach es hochwertig“ oder „arbeite weiter, bis es fertig ist“ erschwert die Entscheidung, wann die Arbeit abgeschlossen ist. Abschlusskriterien sollten überprüfbare Ergebnisse beschreiben. Geben Sie Bildschirmbreiten, Verhalten nach dem Speichern, Testergebnisse oder zu vergleichende Dokumente an.

In der CLI muss der Zieltext nicht leer sein und darf höchstens 4.000 Zeichen umfassen. Statt eine lange Spezifikation vollständig hineinzupacken, verweisen Sie auf eine Spezifikationsdatei und behalten Ergebnis, wesentliche Vorgaben und Prüfkriterien im Zieltext. Eine bereitgestellte Datei übernimmt nicht automatisch den Verlauf eines anderen Chats. Quelle: Codex-CLI-Slash-Befehle.

Wenn die Spezifikation noch offen ist, können Sie zunächst bitten: „Implementiere noch nichts. Kläre die Anforderungen und entwirf ein /goal.“ Nach der Klärung mit /plan lesen Sie das vorgeschlagene Ziel selbst, prüfen Vorgaben und Umfang und starten dann.

4. Beispielaufträge für Fehler, Oberflächen und Recherche

Die folgenden Aufträge wurden für diesen Artikel formuliert. Sie sind keine von uns erfolgreich ausgeführten Beispiele. Prüfen Sie zunächst, ob Tests und ein Browser verfügbar sind, und verlangen Sie, dass nicht verfügbare Prüfungen als nicht durchgeführt gemeldet werden.

Fehlerbehebung: reproduziertes Problem und Regressionstests unterscheiden

/goal Repariere „Löschen rückgängig machen“ in dieser Aufgaben-App so, dass der zuletzt gelöschte Eintrag an seiner ursprünglichen Position und mit seinem ursprünglichen Erledigungsstatus wiederhergestellt werden kann.
Erhalte das bestehende Verhalten beim Hinzufügen, Umschalten des Erledigungsstatus, Löschen und Speichern.
Reproduziere zuerst das Problem. Prüfe nach der Korrektur Position und Erledigungsstatus des wiederhergestellten Eintrags, den Schutz vor doppelter Wiederherstellung, aufeinanderfolgende Löschungen und die dauerhafte Speicherung nach der Wiederherstellung.
Ändere nur zugehörige Dateien und Tests. Füge keine Abhängigkeiten hinzu, veröffentliche nichts extern, führe keinen Push durch und kaufe nichts.
Falls eine Prüfung nicht möglich ist, melde den Grund und die erforderliche Umgebung. Nenne im Abschlussbericht geänderte Dateien, ausgeführte Befehle und ihre Ergebnisse sowie nicht durchgeführte Prüfungen.

Nur „Die Tests müssen bestehen“ kann dazu führen, dass eine Änderung, die Funktionen entfernt, das Ziel scheinbar erfüllt. Wenn Sie auch das zu erhaltende Verhalten und den erlaubten Änderungsumfang nennen, entsteht eine Grundlage für die Wahl der Korrektur.

Oberfläche verbessern: Anzeige und Bedienung festlegen

/goal Passe diesen Bildschirm für Breiten von 390px und 1280px so an, dass nichts horizontal übersteht und die Schaltflächen zum Erledigen und Löschen auch bei langen Aufgabennamen bedienbar bleiben.
Ändere weder die vorhandene Datenstruktur noch das Speicherformat.
Prüfe beide Breiten in einem verfügbaren echten Browser. Teste Hinzufügen, Umschalten des Erledigungsstatus, Löschen, dauerhafte Speicherung nach dem Neuladen und Tastaturbedienung.
Wenn Browsertests nicht möglich sind, werte eine Bild- oder Codeprüfung nicht als bestandene tatsächliche Bedienungsprüfung. Melde diese Prüfungen als nicht durchgeführt.
Veröffentliche nichts, führe keinen Push durch, kaufe nichts und ändere keine Geräteeinstellungen.

Die Breiten sind Prüfbedingungen dieses Auftrags und keine vom Produkt garantierten Bildschirmbreiten. Unterscheiden Sie zudem Ergebnisse tatsächlicher Browserbedienung von Ergebnissen einer reinen Code- oder Bildprüfung.

Recherche: Nachweise bewahren statt Unbekanntes auszufüllen

/goal Vergleiche anhand öffentlich zugänglicher offizieller Dokumente die Bedingungen der beiden angegebenen Dienste für Datenspeicherung, Nutzung zum Training und Löschung.
Ordne jeder Aussage eine Quell-URL und die Bedingungen im geprüften Text zu und erstelle eine Vergleichstabelle mit Erläuterung.
Nenne für Punkte, zu denen du trotz Suche keine Erklärung findest, die durchsuchten Dokumente und die fehlenden Informationen. Fülle die Tabelle nicht mit Vermutungen.
Melde dich nicht an, ändere keine Einstellungen, verbinde keine Apps, lade nichts hoch und kaufe nichts.
Lege am Ende bestätigte Spezifikationen, Interpretationen und recherchierte, aber nicht belegbare Punkte getrennt vor.

„Unbegrenzt weitermachen, bis jede Antwort gefunden ist“ nimmt einer Recherche den Endpunkt. Auch wenn Informationen nicht öffentlich sind, können Sie einen Bericht über die geprüften Quellen und die offenen Fragen als Ergebnis definieren.

5. Ein Ziel pausieren, fortsetzen, bearbeiten und entfernen

Auf Desktop verwenden Sie die Ziel-Fortschrittszeile über dem Eingabefeld. Die CLI-Dokumentation nennt folgende Befehle. Lesen Sie diese CLI-Tabelle nicht als Liste von Desktop-Schaltflächenaktionen.

Während der Arbeit können Sie im selben Chat Informationen oder Vorgaben ergänzen. Teilen Sie geänderte Entscheidungen ausdrücklich mit, etwa „noch nicht veröffentlichen“ oder „die Änderungen an dieser Funktion abbrechen“. Prüfen Sie nach einer Zieländerung, ob die bisherigen Testergebnisse allein das Erreichen der neuen Abschlusskriterien belegen.

Quellen zur Bedienung: CLI-Zielbefehle und Desktop-Zielsteuerung.

6. Tokenbudget, Nutzungskontingent und Preise

Unterscheiden Sie bei fortlaufender Arbeit, wann die Arbeit am Ziel gestoppt werden soll und wie viel Plankontingent sie verbraucht. Selbst bei verbleibendem Zielbudget können Nutzungslimits des Kontos oder Probleme in der Ausführungsumgebung die Fortsetzung verhindern.

Kostet /goal zusätzlich?

In den geprüften offiziellen Preisunterlagen fanden wir keine gesonderte Gebühr pro Start von /goal. Allerdings verbraucht wiederholte Modellverarbeitung das normale Codex-Nutzungskontingent. Goal mode macht die Abfolge aus Testen, Korrigieren und Prüfen nicht kostenlos und unbegrenzt.

OpenAI erklärt, dass Work und Codex ein gemeinsames Kontingent nutzen und der Verbrauch unter anderem von Modell und Aufgabe abhängt. Eine Fortsetzung mit zusätzlichen Credits nach Verbrauch des Plankontingents ist außerdem von einer gesonderten Abrechnung per API-Schlüssel zu unterscheiden. Quelle: Preise und Nutzungslimits von Work und Codex. Zur Planwahl und zu Rücksetzungen siehe ChatGPT Pro: Preise und Nutzungskontingente im Vergleich.

Was belegen die Budgetzahlen?

Die offizielle App-Server-Dokumentation für Entwickler nennt beim Ziel tokenBudget, das Verbrauchsfeld tokensUsed und das Zeitmessungsfeld timeUsedSeconds. Das belegt einen Mechanismus zur Erfassung von Budget und Fortschritt im internen Zielzustand. Es ist keine Anweisung, diese RPC-Feldnamen als CLI-Flags für Nutzer einzugeben.

Dieselbe Dokumentation erklärt, dass beim Ersetzen eines Ziels durch ein neues die Verbrauchsmessungen des Ziels zurückgesetzt werden. Das besagt nicht, dass das verbleibende Plankontingent wiederhergestellt wird. Auch ein Zeitmessungsfeld belegt keine garantierte Möglichkeit, nach zwei Stunden zu stoppen. Quelle: Zielverwaltung im App Server.

7. Was bei einem Arbeitsstopp zu prüfen ist

Ein aktives Ziel überwindet nicht automatisch jede Unterbrechung. Prüfen Sie zunächst das aktuelle Ziel und das letzte Ergebnis, anschließend in dieser Reihenfolge.

Laut Cookbook wird automatisch fortgesetzt, wenn der Chat untätig ist, das Ziel aktiv und innerhalb des Budgets ist und keine andere Verarbeitung oder Nutzereingabe ansteht. Reine Planung löst keine Fortsetzung aus; Unterbrechungen pausieren das Ziel. Ruft ein Fortsetzungsschritt kein Werkzeug auf, wird die nächste automatische Fortsetzung unterdrückt, um unproduktive Wiederholung zu vermeiden.

Wird das Budget erreicht, sieht der offizielle Entwurf vor, die eigentliche Arbeit zu stoppen und Fortschritt, Hindernisse und nächste Schritte zu melden. Das Budget auszuschöpfen und das Ziel zu erreichen sind zwei verschiedene Dinge. Prüfen Sie vor der Fortsetzung verbleibende Arbeit und erwartete Kosten.

Der Start von /goal erweitert weder Berechtigungen noch verbundene Ressourcen. Laut offizieller Dokumentation gelten die bestehende Sandbox und Freigaberichtlinie. Lokale Arbeit wird auch nicht automatisch in die Cloud verschoben. Wenn ein Verbindungsverlust absehbar ist, soll die Arbeit pausiert und erst bei verfügbarer Umgebung fortgesetzt werden. Quelle: Berechtigungen und Fortsetzungsbedingungen bei länger dauernder Arbeit.

Bei einem modellseitigen Fehler wie „Selected model is at capacity“ gehen Sie entsprechend dieser Meldung vor. Codex: den Fehler „at capacity“ untersuchen und behandeln erklärt ihn getrennt von Nutzungslimits.

8. Nachweise im Abschlussbericht prüfen

Die Antwort „fertig“ belegt nicht, dass das gewünschte Ergebnis überprüft wurde. Suchen Sie nach Nachweisen, die zum ursprünglichen Ziel passen. Selbst bei bestandenen Tests dürfen nicht durchgeführte Bedienungsprüfungen nicht als bestanden gelten.

Fehlen Nachweise, geben Sie im selben Chat einen konkreten Folgeauftrag: „Prüfe die dauerhafte Speicherung nach dem Neuladen“ oder „Zeige den Quelltext und die Bedingungen dieser Aussage“. Ergänzen Sie Abschlusskriterien, aktualisieren Sie auch das Ziel. Wenn ein anderer Agent die Arbeit prüfen soll, fordern Sie das ausdrücklich gesondert an. Unterscheiden Sie eine Prüfung allein anhand des Agentenberichts von tatsächlich erneut ausgeführten Kontrollen.

Auch bei gewöhnlicher Codex-Entwicklung können Sie Anforderungen, Umsetzung und Prüfung beauftragen. Der Nutzen von Goal mode liegt darin, Abschlusskriterien über mehrere Schritte zu behalten und anhand ihrer die nächsten Schritte zu wählen. Unterschiede zwischen Produkten und Ausführungsarten beschreibt der Vergleich von Claude Code und Codex.

9. Vor dem Start

Wenn eine Änderung oder Erklärung genügt, eignet sich ein normaler Auftrag. Erwägen Sie /goal für wiederholte Arbeit an denselben Abschlusskriterien, bei der Untersuchungsergebnisse den nächsten Schritt bestimmen. Entscheiden Sie anhand überprüfbarer Ergebnisse und nicht anhand der Laufzeit.

10. Häufige Fragen

Muss ich nicht mehr jedes Mal „weiter“ schreiben?

Ist das Ziel aktiv und sind die Bedingungen für die automatische Fortsetzung erfüllt, kann die Arbeit nach einem Schritt weitergehen. Freigaben, Budgetgrenzen oder Hindernisse können sie dennoch stoppen. Menschliche Entscheidungen werden dadurch nicht überflüssig.

Ist /goal nur für die Cloud? Läuft es nach dem Schließen meines PCs weiter?

Es ist nicht auf die Cloud beschränkt. Es ist für Desktop, Codex CLI und die IDE-Erweiterung dokumentiert. Welche Umgebung für die Fortsetzung nötig ist, hängt vom Ausführungsort ab. Ein festgelegtes Ziel allein belegt nicht, dass die Arbeit auf einem ausgeschalteten lokalen PC weiterläuft.

Garantiert ein Tokenbudget eine Obergrenze für Gebühren?

Eine strenge Rechnungsobergrenze lässt sich nicht garantieren. Zielbudget, Plankontingent, zusätzliche Credits und API-Abrechnung sind getrennte Größen. In den geprüften offiziellen Unterlagen fanden wir keine Erklärung des genauen Zusammenhangs zwischen Zielzählern und Rechnungsbetrag.

Ist es dasselbe wie dot?

/goal verwaltet Ziel und Fortsetzung innerhalb desselben Codex-Chats. dot umfasst auch fortlaufende Unterstützung, Delegation an andere Aufgaben und Koordination. Für eine kleine Entwicklungsaufgabe kann ein direkter Auftrag an Codex genügen. Wählen Sie nach Ihrem Zweck und danach, wer den Fortschritt koordinieren soll.