Claude Code und Codex über Nacht: /goal einrichten

Informationen zur Arbeit mit Ailoot findest du in der Dokumentation.

Was ist /goal und warum wurde es 2026 eingeführt?#

So sah unser aller Alltag vor April 2026 aus: Ich gebe Claude die Aufgabe „Migriere das Projekt von Pydantic v1 zu v2“. Es fängt an, hält nach 30 Sekunden an, ich sehe mir an, was es getan hat, schreibe „weiter“, es macht den nächsten Schritt, hält an, und ich schreibe wieder „weiter“. Bei einer großen Migration bedeutet das 200–300 manuelle „Weiter“-Eingaben. Damit beaufsichtige ich den Agenten praktisch, statt parallel anderen Code zu schreiben.

OpenAIs Analyse lautete, dass das Problem nicht die „Dummheit“ des Modells war, sondern die Architektur der Schleife. Das Modell wusste nicht, wann es aufhören sollte, und trat deshalb bei jedem Durchlauf auf die Bremse. Gibt man ihm ein „Fertig“-Kriterium, entscheidet es selbst.

So entstand /goal – ein Mechanismus im Harness, nicht im Modell.

Diese Bemerkung fiel auf der Konferenz Code with Claude in London am 19.–20. Mai 2026. Sie beschreibt, was im Monat nach dem Start von /goal in beiden Tools tatsächlich geschah.

Wie richtest du den Goal-Modus in Claude Code ein?#

Ein minimales Beispiel aus der offiziellen Dokumentation von Anthropic:

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

Dieser Befehl startet den Agenten mit einem Ziel im Hintergrund. Claude findet die PRs, gleicht sie mit CHANGELOG.md ab, ergänzt fehlende Zeilen und hält an, sobald das Kriterium erfüllt ist.

Im interaktiven Modus gib einfach /goal gefolgt von der Bedingung ein:

/goal all pytest tests pass and mypy strict reports zero errors

Was Claude als Nächstes tut:

• Nach jedem Durchlauf erhält ein separates, schnelles Modell (standardmäßig Haiku) die aktuelle Bedingung und den Gesprächsverlauf
• Dieses Modell antwortet mit „Ja“ oder „Nein“ und einer kurzen Begründung
• Lautet die Antwort „Nein“, startet Claude automatisch einen weiteren Durchlauf, ohne dir die Kontrolle zurückzugeben
• Lautet die Antwort „Ja“, wird das Ziel gelöscht und die Kontrolle an dich zurückgegeben

Harte Grenzen, von denen du erst erfährst, wenn du auf sie stößt:

• /goal funktioniert nur in Arbeitsverzeichnissen, für die der Vertrauensdialog bestätigt wurde. Auf einem neuen Rechner schlägt der Befehl fehl, wenn Claude sich dieses Verzeichnis noch nicht gemerkt hat
• In Unternehmen mit disableAllHooks oder allowManagedHooksOnly ist der Befehl nicht verfügbar
• Die Bedingung darf bis zu 4.000 Zeichen lang sein
• Pro Sitzung kann nur ein Ziel aktiv sein. Ein neues /goal setzt das alte zurück
• Mit --resume bleibt die Bedingung erhalten, aber die Zähler für Durchläufe, Zeit und Tokens werden zurückgesetzt

Steuerungsbefehle:

• /goal ohne Argument – aktuellen Status anzeigen
• /goal clear (oder stop, off, reset, none, cancel) – Ziel löschen

Anthropic zufolge sind die Kosten der Auswertung „im Vergleich zu den Kosten des Hauptdurchlaufs normalerweise vernachlässigbar“. Haiku wertet das Kriterium und den Gesprächsverlauf aus und ruft keine Tools auf. Die Prüfung ist daher günstig; teuer sind die Durchläufe des Hauptmodells.

Wie richtest du /goal in Codex CLI ein?#

Der Befehl sieht genauso aus wie in Claude:

codex
> /goal all vitest tests pass and there are no eslint errors

Codex bietet mehr Steuerungsmöglichkeiten für Ziele:

Der wichtigste Unterschied zu Claude: Codex prüft selbst, ob es „fertig“ ist, statt ein separates Modell dafür einzusetzen. Nach jedem Durchlauf fügt Codex automatisch die Vorlage continuation.md aus dem Repository openai/codex in den Kontext ein. Wörtlich übersetzt:

„Arbeite weiter auf das aktive Thread-Ziel hin. Wiederhole keine bereits erledigten Arbeiten. Wähle die nächste konkrete Handlung, die dem Ziel näherkommt. Markiere das Ziel erst dann als erreicht, wenn eine Prüfung zeigt, dass es tatsächlich erfüllt wurde und keine erforderlichen Arbeiten mehr ausstehen.“

Wenn sich die Tokens ihrem Limit nähern, wird eine zweite Vorlage eingefügt – budget_limit.md:

„Das Ziel hat sein Token-Limit erreicht. Beginne keine umfangreichen neuen Arbeiten. Schließe diesen Durchlauf so bald wie möglich ab: Fasse nützliche Fortschritte zusammen, benenne ausstehende Arbeiten und Hindernisse und gib dem Nutzer einen klaren nächsten Schritt.“

Die Logik ist dieselbe: „Behaupte nicht, etwas getan zu haben, das du nicht getan hast.“ Die Fortsetzung verlangt, nur dann weiterzumachen, wenn das Ziel tatsächlich noch nicht erreicht ist. budget_limit verlangt den Stopp, aber eine ehrliche Beschreibung dessen, was noch aussteht.

Anders als bei Claude ist das Ziel in Codex an den Thread statt an die Sitzung gebunden. Du kannst das Terminal schließen und am Morgen wieder öffnen. /goal resume setzt dasselbe Ziel mit denselben Fakten im Speicher fort. Das ist nützlich für Durchläufe, die man nach dem eigenen Zeitplan in Abschnitte aufteilt.

Worin unterscheiden sich /goal in Claude Code und /goal in Codex?#

Dieser Unterschied wird in Vergleichen am häufigsten übersehen. Sehen wir ihn uns genauer an.

Der konzeptionelle Unterschied ist, dass Claude die Schleife als Qualitätsvertrag (externer Prüfer) behandelt, während Codex sie als Ausführungsmechanismus behandelt (der Agent verwaltet sich selbst).

Praktisch bedeutet das: Wenn das „Fertig“-Kriterium unparteiisch beurteilt werden soll, wähle Claude. Wenn der Agent bei der Auswertung Dateien und Logs prüfen können soll, wähle Codex.

Mehr über die Tools erfährst du im Leitfaden zu Codex und Claude Code.

Echtes Beispiel: Migration von Pydantic v1 zu v2 in 31 Stunden#

Die Aufgabe lautete: „Migriere von Pydantic v1 zu v2; alle pytest-Tests müssen bestehen und mypy strict muss null Fehler melden.“

Was geschah:

• Sitzung 1 (8 Stunden) – Codex analysierte die Imports, schrieb BaseModel-Deklarationen um und richtete mypy ein
• Sitzung 2 (10 Stunden) – Validatoren wurden umgeschrieben und etwa 200 Tests schlugen fehl
• Sitzung 3 (7 Stunden) – die Tests wurden repariert und zirkuläre Abhängigkeiten entdeckt
• Sitzung 4 (6 Stunden) – die übrigen mypy-Fehler und Regressionen wurden behoben

Tokenkosten:

„Gesamtzeit: etwa 31 Stunden über vier Sitzungen. Gesamte Tokenkosten von Codex zu den Tarifen von gpt-5.3-codex: etwa $44.“

Den größten Anteil am Preis haben die Output-Tokens von gpt-5.3-codex mit 14 $ pro Million. Damit kosten 31 Stunden autonomer Arbeit etwa so viel wie ein ChatGPT-Plus-Abonnement für mehrere Wochen.

Was der Agent nicht selbst erledigte:

• Er schrieb keine Migrationsdokumentation für das Team (Codex verstand nicht, dass diese zur „Migration“ gehörte)
• Er aktualisierte keine Konfigurationsdateien für die Veröffentlichung mit der neuen Pydantic-Version
• Er übersah eine Produktionsregression, die erst einen Tag später entdeckt wurde

Mit anderen Worten: /goal erledigte 95 % der Arbeit; die übrigen 5 % müssen weiterhin von Hand erledigt werden. Das ist bei der aktuellen Generation normal und kein Grund, das Tool nicht zu verwenden.

14 Stunden über Nacht an einem macOS-Treiber arbeiten#

Die Aufgabenarten, bei denen dieser Ansatz den größten Nutzen bietet:

• Low-Level-Arbeiten, bei denen eine Iteration samt Prüfung Minuten dauert (Kompilieren, Tests ausführen)
• Migrationen mit klaren formalen Kriterien (Typen, Tests, Lint)
• Benchmarks und Optimierungen mit messbaren Ergebnissen
• Dokumentation und Changelogs mit klarer Struktur

Claude /goal erledigt das genauso gut. Für Treiber wird jedoch häufiger Codex gewählt, weil es Dateien und Logs selbst prüft, statt sich auf einen externen Prüfer zu verlassen.

Was kostet es, und wie vermeidest du, über Nacht deine Tokens aufzubrauchen?#

Zahlen aus öffentlichen Berichten:

Das Wichtigste: Weder Claude Code noch Codex bietet eine harte Grenze wie „Stoppe die Ausgaben bei 𝑁 $“. Es gibt drei Schutzmaßnahmen:

1. Abonnementlimits – Pro, Max oder Enterprise. Beim Max-Tarif von Anthropic (100 $/Monat) liegt ein 14-stündiger Lauf über Nacht innerhalb des Wochenkontingents, mit reichlich Spielraum
2. Textlimit in der Bedingung – schreibe „oder nach 20 Durchläufen stoppen“ direkt in /goal. Der Claude-Prüfer liest dies und schließt das Ziel ab
3. Token-Limit in Codex – ein integrierter Mechanismus, der budget_limit.md einfügt, wenn die Tokens ausgehen

Was die Rechnung über Nacht in die Höhe treibt:

• Ein vages Kriterium wie „mach es praktischer“ – der Agent wird nie anhalten, weil der Prüfer nicht weiß, was „besser“ bedeutet
• Zugriff auf externe APIs ohne Stubs – jeder erneute Versuch kostet Tokens
• Ein langer Kontext – nach 6,7 Millionen Tokens setzt die Kontextkomprimierung ein, wobei ein Teil des Gedächtnisses verloren geht

Mehr zum Sparen erfährst du in den Anleitungen wohin die Claude-Code-Tokens gehen und wie du dein Limit nicht aufbrauchst.

Wann solltest du /goal NICHT verwenden: 5 Situationen#

OpenAIs Dokumentation nennt ausdrücklich, was man NICHT tun sollte:

1. Änderungen an einer einzelnen Zeile – /goal zum Umbenennen einer Variablen zu verwenden kostet mehr, als es von Hand zu tun
2. Vage Ziele – „Leistung verbessern“, „den Code sauberer machen“, „es praktischer machen“. Der Prüfer hat kein Kriterium, also dreht sich der Agent endlos im Kreis
3. Produktionsdatenbanken mit Nutzerdaten – der Agent könnte eine Migration beschädigen, und eine Wiederherstellung aus einem Backup kostet mehr als jede mögliche Ersparnis
4. Sicherheitsänderungen – Authentifizierung, Verschlüsselung, Zahlungsabwicklung. Hier muss ein Mensch jeden Commit prüfen
5. Externe APIs ohne Stubs – jeder Netzwerkausfall kostet Tokens und liegt außerhalb deiner Kontrolle

Was solltest du tun, wenn der Agent stecken bleibt?#

So erkennst du eine Schleife schnell:

• Der Agent bearbeitet dieselben Dateien über 3+ Durchläufe hinweg und setzt sie auf ihren vorherigen Stand zurück
• Im Log erscheinen wiederholt Fehler, auf die er bereits reagiert hat
• Für dich sieht es so aus, als sei die Bedingung erfüllt, aber der Agent sagt „nicht erfüllt“
• Der Tokenverbrauch pro Durchlauf steigt, aber der Code macht keine Fortschritte

So gehst du vor:

• In Claude Code: /goal clear, dann die Bedingung präziser formulieren
• In Codex: /goal pause, den aktuellen Thread prüfen, die Bedingung mit /goal edit ändern und dann /goal resume
• In beiden: Prüfen, ob sich das Kriterium tatsächlich verifizieren lässt (ein Befehl gibt Exit-Code 0 zurück oder erzeugt eine bestimmte Ausgabe)

Oft liegt die Ursache der Schleife in der Aufgabe selbst, nicht im Agenten. Die Bedingung „alle Tests bestehen“ setzt voraus, dass die Tests überhaupt bestehen können. Bei einem tiefgreifenden Architekturproblem im Code kreist der Agent immer wieder um das Symptom.

„Fertig“-Kriterien: Aufgabendisziplin für /goal#

OpenAI formuliert diese Regel in seinem offiziellen Codex Cookbook klar:

Vorlagen für Kriterien, die sich bewähren:

Das Beispiel kombiniert mehrere Prüfungen: Tests, mypy und Lint. Ist auch nur eine Prüfung noch rot, wird das Ziel nicht abgeschlossen. Der Prüfer kann nicht schummeln.

Anti-Muster:

• „Der Code ist besser“
• „Die Benutzerfreundlichkeit hat sich verbessert“
• „Die Leistung hat sich verbessert“
• „Die Dokumentation ist vollständig“

Der Unterschied zwischen „funktioniert“ und „funktioniert nicht“ liegt in der Überprüfbarkeit. Ein Kriterium, das sich nicht mit einem Befehl prüfen lässt, lässt sich überhaupt nicht prüfen. Das meint OpenAI auch mit „Langzeithorizont-Kohärenz“: Ein Agent kann lange nachdenken, aber nicht selbst entscheiden, was als „gut genug“ gilt.

Du kannst die Idee „ein Prompt – ein Ergebnis“ an einem echten Projekt ausprobieren: Setze /goal, formuliere ein Kriterium, führe es aus und analysiere, was schiefgelaufen ist.

Lerne Ailoot kennen.