So nutzt man Goals in Codex

• Goals sind eine Funktion für persistente Ziele (persistent objectives), die dafür sorgt, dass ein Codex-Thread über mehrere Turns hinweg weiter auf ein definiertes Ergebnis hinarbeitet
• Geeignet für Aufgaben wie Profiling, Patches, Benchmarking, Reproduktion flakiger Tests und evidenzbasierte Audits, die sich nur schwer mit einem einzelnen Prompt erledigen lassen
• Wenn Ergebnis (outcome), Verifikationsmittel (verification surface) und Einschränkungen (constraints) definiert sind, kann Codex eigenständig auf Basis von Belegen beurteilen, ob die Aufgabe abgeschlossen ist
• Die Lebensdauer lässt sich mit den Befehlen /goal, /goal pause, /goal resume, /goal clear steuern, unterstützt ab Codex 0.128.0
• Es handelt sich um eine Abschlussvereinbarung (completion contract) mit Thread-Umfang; zentral ist Persistenz unter Benutzerkontrolle statt unbegrenzter autonomer Ausführung

---

Definition von Goals und Hintergrund der Einführung

• Goals sind eine Funktion, die Codex eine Abschlussbedingung (completion condition) gibt: was wahr sein muss, wie Erfolg geprüft wird und welche Einschränkungen eingehalten werden müssen
• Codex funktioniert bereits gut bei klar abgegrenzten Coding-Aufgaben wie Repository-Prüfung, Bugfixes, Hinzufügen von Tests, Erklären von Fehlern oder Umsetzen fokussierter Änderungen
• Goals eignen sich für Arbeiten, bei denen der nächste Schritt davon abhängt, was Codex unterwegs lernt
  • Profiling, Patching, Benchmarking, Reproduktion flakiger Tests oder das Umwandeln von Forschungsfragen in evidenzbasierte Audits
• Solche Aufgaben brauchen keinen größeren Prompt, sondern ein persistentes Ziel
• Sobald ein Goal aktiv ist, hält Codex das Ziel aufrecht, bewertet den Abschlussstatus und wählt die nächste Aktion, ohne dass das Ziel bei jedem Zwischenergebnis neu formuliert werden muss
• Ein Goal ist keine grenzenlose Hintergrundautonomie, sondern eine abgegrenzte, benutzerkontrollierte Abschlussvereinbarung

Quickstart: So verwendet man Goals

• Verwende ein Goal für Aufgaben, bei denen das Endziel klar ist, der Weg dorthin aber ungewiss
  • Gute Kandidaten: Performance-Optimierung, Untersuchung flakiger Tests, Abhängigkeitsmigrationen, Bug-Tracking mit notwendiger Reproduktion, mehrstufiges Refactoring, benchmarkbasiertes Tuning und Forschungsaufgaben mit benötigtem Endergebnis
  • Für einmalige Änderungen ist ein normaler Prompt besser geeignet

• Installation und Versionsprüfung

  • Goals sind ab Codex 0.128.0 verfügbar
  • npm: npm install -g @openai/codex@latest und danach codex --version
  • Homebrew: brew update && brew upgrade --cask codex und danach codex --version

• Goal setzen und Lebenszyklus-Befehle

  • Setzen im Format /goal <Ergebnis>, zum Beispiel: /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal: aktuelles Goal anzeigen
  • /goal pause: aktives Goal pausieren
  • /goal resume: pausiertes Goal fortsetzen
  • /goal clear: aktuelles Goal entfernen

• Stoppbedingung (stopping condition)

  • Stopp bei Erfolg, Pause, Entfernung, Abbruch, Erreichen des Budgetlimits oder wenn ein Blocker auftritt, der Benutzereingaben erfordert
• In Situationen, in denen man in jedem Turn wiederholt Anweisungen wie „mach weiter“, „probier als Nächstes einen möglichen Fix“, „führ den Benchmark noch einmal aus“ oder „prüf jetzt die Tests“ geben müsste, drückt ein Goal diese Absicht explizit aus

Goals vs. Prompts

• Normaler Prompt: „Führe diese nächste Aufgabe aus“
• Goal: „Arbeite weiter, bis dieses Ergebnis wahr ist“

• Unterschied im Verhalten

  • Bei einer normalen Anfrage führt Codex die unmittelbare Anweisung aus, berichtet das Ergebnis und wartet
  • Bei einem Goal wird dem Thread ein dauerhaftes Ziel (durable target) angehängt; nach Ende eines Turns prüft Codex die aktuelle Evidenz und entscheidet, ob das Ziel erfüllt ist
  • Ist es nicht erfüllt, das Goal aktiv und noch Budget vorhanden, kann Codex vom aktuellen Stand aus weiterarbeiten

• Beispiel: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • Liefert ein messbares Ergebnis, Verifikationsmittel und Einschränkungen
  • Codex wiederholt Benchmark ausführen → Hot Path prüfen → gezielte Änderung vornehmen → Benchmark erneut ausführen → Korrektheitssuite ausführen und macht weiter, wenn das Ergebnis noch nicht ausreicht

• Mentales Modell

  • Prompt: ask → work → result → wait
  • Goal: work → check → continue or complete
• Ein Goal definiert die Ziellinie, aber die Arbeit muss weiterhin gegen Evidenz auditiert (audited against evidence) werden

Wie man ein Goal formuliert

• Ein gutes Goal ist kein größerer Prompt, sondern eine knappe Vereinbarung darüber, wie Codex arbeiten soll, was Erfolg bedeutet und was zu tun ist, wenn Erfolg noch nicht erreicht ist

• Sechs Elemente eines starken Goals

  • Outcome: was bei Abschluss wahr sein muss
  • Verification surface: Tests, Benchmarks, Berichte, Artefakte, Befehlsausgaben oder Quellmaterial, die das belegen
  • Constraints: was während der Arbeit von Codex nicht regressieren darf
  • Boundaries: welche Dateien, Tools, Daten, Repositories und Ressourcen genutzt werden dürfen
  • Iteration policy: wie nach jedem Versuch entschieden wird, was als Nächstes zu tun ist
  • Blocked stop condition: wann gemeldet und gestoppt werden soll, wenn es innerhalb der aktuellen Grenzen keinen vertretbaren Weg mehr gibt

• Formulierungsmuster

  • /goal <gewünschter Endzustand> verified by <konkrete Evidenz> while preserving <constraints>. Use <erlaubte Inputs/Tools/Grenzen>. Between iterations, <wie die nächste beste Aktion gewählt wird>. If blocked or no valid paths remain, <was gemeldet wird und welche Eingaben für Fortschritt nötig sind>.

• Schwaches vs. starkes Beispiel

  • Schwach: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • Stark: spezifiziert zusätzlich Verifikationsmittel (checkout benchmark), Nutzungsbereich (checkout service, benchmark fixtures, relevante Tests), Iterationsrichtlinie (Änderungen, Benchmark-Ergebnisse und nächstes Experiment protokollieren) sowie Bedingungen zur Meldung von Blockern

• Goals für Forschung und Analyse

  • Wenn exakter Nachweis unmöglich sein kann, sollte vor Arbeitsbeginn ein Evidenzstandard (evidence standard) definiert werden
  • Beispiel: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• Das Schreiben eines Goals an Codex delegieren

  • Empfohlen wird ein zweistufiger Workflow: Aufgabe in einfacher Sprache beschreiben → Codex um einen Goal-Entwurf bitten → Erfolgsbedingungen, Verifikationsmittel, Einschränkungen und Blocker-Stoppbedingungen verfeinern und dann aktivieren

Was sich ändert, wenn ein Goal aktiv ist

• Das Ziel bleibt sichtbar

  • Auch wenn Tests fehlschlagen, behält der Thread das ursprüngliche Ziel
  • Wenn sich ein Benchmark verbessert, den Schwellwert aber noch nicht erreicht, arbeitet Codex weiter
  • Wenn ein Forschungsweg an fehlenden Daten scheitert, passt Codex den Evidenzplan an, ohne den Forschungsstandard aufzugeben

• Fortsetzung (continuation) in inaktiven Threads möglich

  • Es wird nicht fortgesetzt, wenn ein anderer Turn aktiv ist, Benutzereingaben in der Queue stehen oder andere Thread-Arbeiten noch ausstehen
  • Fortgesetzt wird nur, wenn der Thread inaktiv ist, das Goal aktiv ist und noch Budget vorhanden ist

• Abschluss muss evidenzbasiert sein

  • Es reicht nicht, dass das Modell glaubt, „es dürfte wohl fertig sein“
  • Abschluss erst nach Prüfung des Ziels anhand relevanter Dateien, Tests, Logs, Benchmark-Ausgaben, erzeugter Artefakte und anderer konkreter Evidenz
• Der Kern des Designs: Codex kann weiterarbeiten, aber ob etwas abgeschlossen ist, entscheidet die Evidenz

Designstruktur von Goals in Codex

• Goals sind als persistierter Thread-Zustand (persisted thread state) implementiert, nicht als globaler Speicher oder Anweisung auf Projektebene
  • Das Ziel gehört zu dem Thread, in dem auch der zugehörige Kontext liegt, etwa geprüfte Dateien, ausgeführte Befehle, erzeugte Diffs, eingesehene Logs und aufgezeichnete Überlegungen

• Architekturebenen

  • Ziele, Lebenszyklus, Budget und Fortschrittsbuchhaltung werden als persistenter Zustand mit Thread-Umfang gespeichert
  • Goal-Zustände: active, paused, complete, budget-limited
  • Je nach Zustand entscheidet Codex, ob es weitermacht, auf den Benutzer wartet oder statt neuer Arbeit den Fortschritt zusammenfasst

• Fortsetzung (continuation) ist ereignisgesteuert

  • Kein einfacher Loop, sondern Prüfung nur an sicheren Grenzen: nach Ende eines Turns, wenn keine wartenden Aufgaben existieren, keine Benutzereingaben in der Queue stehen und der Thread inaktiv ist
  • Das Dispatcher-Verhalten ist konservativ: rein planerische Arbeit löst keine Fortsetzung aus, bei Unterbrechung wird das Goal pausiert, bei Wiederaufnahme des Threads wird das Goal bei Bedarf wiederhergestellt, und wenn ein Fortsetzungsturn keine Tool-Aufrufe ausführt, wird die nächste automatische Fortsetzung unterdrückt, um Spinning zu vermeiden

• Prompting-Ebene

  • Der Continuation-Prompt richtet Codex am aktiven Goal aus, verlangt aber vor Abschluss weiterhin ein Audit
  • Das Ziel wird mit konkreter Evidenz abgeglichen: geänderte Dateien, ausgeführte Befehle, bestandene Tests, Benchmark-Ausgaben, erzeugte Artefakte und Forschungsevidenz

• Umgang mit Budget

  • Wird das Budget erreicht, wird die eigentliche Arbeit gestoppt, der Fortschritt und Blocker werden zusammengefasst und der nächste sinnvolle Schritt benannt
  • Das Erreichen des Budgetlimits ist nicht dasselbe wie der Abschluss des Goals

• Tool-Vertrag (tool contract)

  • Das Modell kann ein Goal beginnen und ein bestehendes Goal nur dann als abgeschlossen markieren, wenn Evidenz den Abschluss stützt
  • Pause, Fortsetzung, Entfernung und Wechsel in den Budgetlimit-Zustand bleiben unter Benutzer- oder Systemkontrolle

Schwache Goals in starke Goals verwandeln

• Beispiel Performance-Tuning

  • Schwach: /goal Improve performance
  • Stark: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • Die starke Version liefert Ergebnis, Verifikationsmethode und Einschränkungen und macht erkennbar, wann nicht gestoppt werden darf
    • Wenn sich p95 von 180 ms auf 135 ms verbessert, ist das Goal noch nicht erfüllt
    • Wenn die Latenz unter 120 ms fällt, aber die Korrektheitstests fehlschlagen, ist es nicht erfüllt
    • Wenn der Benchmark nicht ausgeführt werden kann, wird kein Erfolg deklariert, sondern ein Blocker offengelegt

• Angemessener Umfang eines Goals

  • Es sollte eng genug sein, um auditierbar zu bleiben, aber breit genug, damit die nächste Aktion gewählt werden kann
  • „Fix the failing checkout test“ ist zu eng, wenn in Wahrheit eine vorgelagerte Abhängigkeit das Problem ist
  • „Improve the whole system“ ist zu breit, weil eine Audit-Oberfläche fehlt
  • „Make the checkout test suite pass on the current branch without changing public API behavior“ ist passend

• Dasselbe Prinzip für erzeugte Artefakte

  • Schwach: /goal Write docs for this feature
  • Stark: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • Die starke Version liefert eine prüfbare Seite, einen Build-Befehl und überprüfbares Befehlsverhalten

• Evidenzstandard für Forschungs-Goals

  • Vor Beginn der Untersuchung definieren: was als exakte Reproduktion, partielle Rekonstruktion, Proxy-Unterstützung oder Blocker gilt
  • Ein starkes Forschungs-Goal verlangt den Aufbau eines Behauptungsinventars, ein Mapping von Behauptungen auf Evidenz, die Umsetzung ausführbarer Teile, das Kennzeichnen von Blockern und die Erstellung eines Audits, das bestätigte Behauptungen, nur indirekt gestützte Evidenz, blockierte Behauptungen und verbleibende Unsicherheit voneinander trennt

Goals in komplexer Forschung: Beispiel Reproduktion einer Quant-Publikation

• Überblick über den Fall

  • Gegenstand: die Publikation Deep Hedging von Buehler, Gonon, Teichmann und Wood
  • Thema der Publikation: ob neuronale Handelsstrategien modellbasierte Absicherung unter Risikoaversion, Transaktionskosten und hochdimensionalen Marktszenarien reproduzieren können
  • Ein korrektes Goal ist nicht das abstrakte „Paper reproduzieren“, sondern der Versuch, die zentralen Kennzahlen nachzubilden, exakte Mechanismen von approximativen Lernersatzlösungen zu trennen und klar zu benennen, was mit den verfügbaren Materialien nicht exakt reproduzierbar ist

• Schwaches vs. starkes Forschungs-Goal

  • Schwach: /goal Reproduce Buehler et al., "Deep Hedging"
    • Es bleibt offen, welche Abschnitte wichtig sind, was als Reproduktion gilt, wie mit fehlenden Trainingszuständen umzugehen ist und woran sich ungefähre Übereinstimmung von exakter Wiedergabe unterscheidet
  • Stark: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• Was Codex tatsächlich tut

  • Zentrale Behauptungen und stützende Nebenbehauptungen trennen
  • Behauptungen auf verfügbare Evidenz abbilden
  • Lokal testbare Teile rekonstruieren
  • Behauptungen kennzeichnen, die sich mit den verfügbaren Materialien nicht exakt reproduzieren lassen

• Was ausführbar war

  • Preisbildungs- und Hedging-Mechanismen rekonstruieren
  • Heston-Referenzpreise reproduzieren
  • Richtlinien für CVaR-Hedging-Experimente trainieren
  • Zentrale Histogramme und Hedge-Surface-Artefakte rekonstruieren
  • Black-Scholes-Transaktionskosten-Slopes reproduzieren
  • Gelernte Prüfungen für Heston-Transaktionskosten und hochdimensionale Beispiele ausführen

• Was als Blocker blieb

  • Die Publikation liefert keine exakten Random Seeds, erzeugten Trainingspfade, TensorFlow-Graphen, Optimizer-Zustände, Checkpoints oder vollständigen ursprünglichen Simulationszustand
  • Das ehrlichste Ergebnis ist daher eine partielle, approximative Reproduktion und keine exakte Wiedererzeugung des neuronalen Modells

• Wahrung des epistemischen Evidenzniveaus im Bericht

  • Gelernte Ersatzlösungen können Behauptungen stützen, eine nahe numerische Übereinstimmung kann das Vertrauen erhöhen und rekonstruierte Abbildungen können Teile der Ergebnisse verifizieren, aber nichts davon darf als exakte Wiederherstellung des Originalexperiments beschrieben werden
  • Beispiel für ein Ledger:
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: Modellmechanik rekonstruieren, Referenz-Hedge vergleichen, neuronale Policy trainieren
    • Evidence surface: Preisprüfung, Histogramme, Hedge-Flächen
    • Status: Close approximate reproduction
    • Remaining uncertainty: ursprüngliche Trainingspfade, Seeds und Checkpoints nicht verfügbar
• Der Demonstrationswert von Goals in der Forschung liegt darin, die Arbeit trotz Ambiguität fortzusetzen und zugleich zu verhindern, dass plausible Artefakte in überzogene Schlussfolgerungen umschlagen; Abschluss bedeutet hier behauptungsweises, evidenzbasiertes Audit, explizite Kennzeichnung von Approximationen und Ehrlichkeit über die Grenze zwischen Reproduktion und Replay

Wann man Goals nicht verwenden sollte

• Ungeeignet für Ein-Zeilen-Edits, einfache Erklärungen, kurze Code-Reviews oder Fragen, bei denen nach einer einzigen Antwort Schluss sein soll → dafür ist ein normaler Codex-Prompt passend
• Ungeeignet, wenn die Ziellinie unklar ist
  • „Make this better“ liefert keine verlässliche Abschlussbedingung
  • Auch „Refactor this code“ ist schwach, wenn erwarteter Endzustand, Tests und Einschränkungen nicht definiert sind
• Nicht verwenden, um Unsicherheit zu verbergen
  • Wenn Daten eventuell nicht verfügbar sind, muss das im Goal stehen
  • Wenn ein Benchmark flakig sein kann, sollte festgelegt werden, wie damit umzugehen ist
  • Wenn Proxy-Evidenz zulässig ist, muss definiert werden, wie sie gekennzeichnet wird
• Goals sind am stärksten bei Aufgaben, in denen persistentes Ziel, evidenzbasierte Ziellinie und ein Pfad mit Untersuchung über mehrere Turns zusammenkommen

Fazit: Das Ziel hält die Arbeit in Gang, über den Abschluss entscheidet die Evidenz

• Goals verändern das Betriebsmodell von Codex und machen aus einem Thread statt einer Folge isolierter Prompts einen zustandsbasierten Arbeits-Loop rund um ein definiertes Ergebnis
• Die Architektur ist bewusst begrenzt
  • Ein Goal ist auf einen Thread beschränkt, besitzt Lebenszyklusstatus und Budgetbuchhaltung und kann pausiert, fortgesetzt, entfernt, abgeschlossen oder wegen Budget gestoppt werden
  • Codex kann weiterarbeiten, aber nur innerhalb der vom Benutzer definierten Vereinbarung
• Es ist besonders nützlich für die Arbeiten, in denen Codex bereits den größten Wert liefert: Debugging, Optimierung, Migration, Tests und Forschung
• Der Benutzer gibt das Ziel vor, Codex folgt der Evidenz, und das Goal verbindet beides, bis die Arbeit abgeschlossen oder ehrlich als blockiert ausgewiesen ist
• In komplexer Forschung macht es den Unterschied zwischen dem Erzeugen einer Antwort und dem Erzeugen eines Audits
• Ein gutes Goal sagt Codex nicht einfach nur, dass es fertig werden soll, sondern was „fertig“ überhaupt bedeutet

[hmmhmmhm]

/goal Bitte prüfen Sie bis 12 Uhr mittags auf Grundlage meiner bisherigen Arbeiten alles, was sinnvoll machbar ist, und setzen Sie es um. Sie dürfen die Arbeit vor 12 Uhr nicht unterbrechen.

[shakespeares]

Ein toller Befehl.