Was ist /goal in Claude Code? Anwendung, Bedingungen und Ergebnisse im Praxistest

Der Befehl /goal in Claude Code funktioniert so: Sie schreiben einen Satz dazu, wann die Aufgabe erledigt ist, und Claude arbeitet selbstständig weiter, bis dieser Punkt erreicht ist. Jedes Mal, wenn ein Turn (eine Antwort von Claude) endet, prüft ein kleines, separates Modell, ob die Bedingung erfüllt ist. Ist sie es nicht, bekommt Claude den nächsten Arbeitsschritt. Dieser Artikel fasst auf Grundlage der offiziellen Dokumentation (geprüft am 24. Oktober 2026) zusammen, wie der Befehl verwendet wird und wann er stoppt. Außerdem berichtet er über Versuche mit echten Aufgaben auf dieser Website, einschließlich Token-Verbrauch und einer Kontrolle der Endqualität.

1. Was /goal ist: Unterschied zu normalen Anfragen, /loop und Stop-Hooks

Wenn Sie Claude eine Aufgabe ohne /goal geben, hört Claude auf, sobald es die Arbeit für abgeschlossen hält, und wartet auf Ihre nächste Anweisung. Wenn Sie /goal festlegen, findet am Ende jedes Turns (einer Antwort von Claude) eine Prüfung statt. Ist die Bedingung noch nicht erfüllt, beginnt der nächste Turn auch dann, wenn Sie nichts senden. Die offizielle Dokumentation nennt als geeignete Beispiele größere Aufgaben, deren Endzustand sich prüfen lässt, etwa:

• ein Modul auf eine neue API umstellen, bis alle Aufrufstellen kompilieren und die Tests laufen
• ein Designdokument umsetzen, bis alle Abnahmekriterien erfüllt sind
• große Dateien aufteilen, bis jede Datei die festgelegte Größe nicht überschreitet
• eine Liste markierter Issues abarbeiten, bis die Liste leer ist

Es gibt drei ähnliche Mechanismen. Die offizielle Dokumentation empfiehlt, sie danach zu unterscheiden, was den nächsten Turn startet.

Im Kern ist /goal ein „Stop-Hook, der per Prompt prüft“, und er wirkt nur innerhalb des jeweiligen Gesprächs. Ein Stop-Hook steht in einer Einstellungsdatei und gilt für alle Gespräche. /goal legen Sie direkt im Gespräch fest, und es gilt nur für dieses Gespräch.

Quelle: Keep Claude working toward a goal (offizielle Dokumentation von Claude Code, geprüft am 24. Oktober 2026).

2. Verwendung: Festlegen, Status prüfen, Löschen

In einem Gespräch kann nur ein Ziel gesetzt sein. Derselbe Befehl /goal dient je nach Eingabe zum Festlegen, zum Prüfen und zum Löschen.

1. Festlegen: /goal gefolgt von der Bedingung Beispiel: /goal Die Tests in test/auth laufen alle durch, und lint ist ebenfalls sauber. Nach dem Festlegen beginnt sofort ein Turn. Die Bedingung selbst dient als Anweisung, Sie müssen also keine weitere Anfrage senden. Gibt es bereits ein Ziel, wird es durch die neue Bedingung ersetzt. Bedingungen dürfen bis zu 4.000 Zeichen lang sein.
2. Status anzeigen: /goal allein eingeben Angezeigt werden die Bedingung, die verstrichene Zeit, die Anzahl der Prüfungen, die verbrauchten Token und die Begründung der letzten Prüfung. Anzahl und Begründung erscheinen ab der ersten Prüfung.
3. Beenden: /goal clear Damit wird das Ziel entfernt, bevor eine Prüfung stattfindet. stop, off, reset, none und cancel haben dieselbe Wirkung. Mit /clear wird das Gespräch neu begonnen, und das Ziel wird ebenfalls entfernt.

Wenn Sie ein Gespräch fortsetzen, kommt ein noch nicht abgeschlossenes Ziel wieder zurück. Die Bedingung bleibt erhalten, die Zählung von Turns, Zeit und Token beginnt aber neu. Der Befehl funktioniert in der Desktop-App, bei Remote-Sitzungen und bei automatischen Läufen über claude -p. claude -p "/goal …" läuft in einer einzigen Ausführung bis zum Ende des Ziels. Wenn Sie den Fortschritt verfolgen möchten, ergänzen Sie --output-format stream-json --verbose.

3. Wie die Prüfung funktioniert und wann sie stoppt

Jedes Mal, wenn ein Turn endet, sendet Claude Code die Bedingung und das bisherige Gespräch an ein „kleines, schnelles Modell“. Die Prüfung hat drei mögliche Ergebnisse, jedes mit einer kurzen Begründung. In der Umgebung dieser Website war das Prüfmodell Claude Haiku 5.5 (anhand der Gesprächsaufzeichnungen bestätigt).

Der Prüfer verwendet keine Werkzeuge, und er urteilt nur anhand dessen, was im Gespräch steht. Er liest keine Dateien erneut und führt keine Tests selbst aus. Wenn Claude mehrere Turns hintereinander ohne Werkzeuge nur noch auf den Prüfer antwortet, stoppt Claude Code die Schleife, zeigt eine Warnung an und übergibt die Kontrolle an Sie, wobei das Ziel bestehen bleibt.

Wenn ein Fehler zum Stopp führt

Wenn Subagenten oder Hintergrundarbeiten laufen

Läuft am Ende eines Turns noch ein Subagent oder ein Befehl im Hintergrund, wird die Prüfung für diesen Turn zurückgestellt. Sobald die Ergebnisse vorliegen, erreichen sie Claude als neuer Turn. Vergehen beim Warten 30 Minuten, findet eine „Zwischenprüfung“ statt. Sie liest die Ausgabe der laufenden Arbeit. Kommt die Arbeit voran, wird weiter gewartet. Ist sie stehen geblieben, fordert sie Claude auf, das Problem zu beheben oder zu stoppen. Standardmäßig verdoppeln sich die Abstände: nach 30 Minuten, dann nach 1 Stunde, dann nach 2 Stunden. Danach wiederholt sich die Prüfung alle 2 Stunden. Den ersten Abstand können Sie mit der Umgebungsvariable CLAUDE_CODE_GOAL_CHECKIN_MINUTES ändern. Mit dem Wert 0 werden Zwischenprüfungen und automatische Wiederholungen abgeschaltet.

Wann es nicht genutzt werden kann, und Kosten

Der Prüfer ist Teil des Hook-Mechanismus. Wie bei Hooks lässt er sich deshalb in Ordnern, denen Sie nicht vertrauen, nicht nutzen. Ebenso wenig funktioniert er, wenn in den Einstellungen disableAllHooks auf true steht oder wenn in den Administratoreinstellungen allowManagedHooksOnly aktiviert ist. In diesen Fällen wird der Grund angezeigt. Die Token für die Prüfung werden zum Preis des kleinen, schnellen Modells berechnet. Die offizielle Dokumentation sagt, das sei „normalerweise im Vergleich zur eigentlichen Arbeit sehr gering“. Das Prüfmodell lässt sich mit ANTHROPIC_DEFAULT_HAIKU_MODEL ändern. Diese Einstellung wirkt aber auch auf andere Vorgänge, die das kleine Modell nutzen, etwa die Zusammenfassung von Gesprächen.

Quelle: Keep Claude working toward a goal (geprüft am 24. Oktober 2026).

4. So formulieren Sie eine Bedingung

Der Prüfer liest nur das Gespräch. Deshalb sollten Sie die Bedingung so formulieren, dass sie sich anhand von Claudes eigener Ausgabe belegen lässt. Die offizielle Dokumentation nennt drei Bestandteile, die auch über lange Läufe gut halten.

Wenn Sie die Laufzeit begrenzen möchten, schreiben Sie das in die Bedingung, etwa „oder nach 20 Turns anhalten“. Die offizielle Dokumentation kennt keine eigene Einstellung wie das Token-Budget bei Codex /goal.

Eine Vorsichtsregel aus den Tests auf dieser Website: Schreiben Sie das, was erhalten bleiben soll, in die Bedingung selbst und nicht in eine separate Anleitungsdatei. Der Prüfer urteilt wörtlich nach der Bedingung. Eine Anweisung in einer anderen Datei kann deshalb auch dann als „erfüllt“ gelten, wenn sie nicht befolgt wurde. Das ist in dem Test auf dieser Website tatsächlich passiert (siehe Kapitel 5).

5. Ergebnisse zweier /goal-Tests (im Vergleich zu einer normalen Anfrage)

Wir haben /goal für eine Aufgabe auf dieser Website eingesetzt: das Angleichen der Satzschlusszeichen. In den japanischen Artikeln gab es bei bestehenden Artikeln 1.035 Stellen, an denen das abschließende „。“ mal vorhanden und mal nicht vorhanden war (gezählt mit dem Prüfskript dieser Website für Satzschlusszeichen). Da die Regel für die Korrektur feststand und der Endzustand klar „0 Treffer in der Prüfung“ lautete, wählten wir eine Aufgabe, die sich für /goal eignet. Wir führten /goal zweimal mit unterschiedlichem Umfang aus und stellten zum Vergleich einen normalen Auftrag daneben.

Der Vergleichslauf entstand so: Wir hatten die Bedingung beim Ausprobieren von /goal in einem Stück eingefügt. Wie im Hinweis in Kapitel 2 beschrieben, wurde sie nicht als Befehl erkannt, sondern lief als normaler Auftrag. Wir führen ihn in der Tabelle als Richtwert für dieselbe Art von Aufgabe auf, die normal angefragt wurde. Umfang und Anzahl unterscheiden sich, daher ist es kein strenger Vergleich. Bei den beiden /goal-Läufen haben wir /goal von Hand eingegeben, ausgewählt und die Zeile „Goal set:“ kontrolliert. Die Läufe fanden am 23. Oktober 2026 in der Windows-Desktop-App mit Claude Code 2.1.308 statt. Als Arbeitsmodell diente Claude Opus 5.5, der Berechtigungsmodus war Auto.

Die Zahlen wurden aus den Aufzeichnungen der einzelnen Gespräche (JSONL-Dateien, die Claude Code speichert) berechnet. Der Gegenwert ist der Betrag, den Claude Code nach API-Preisen berechnet und festgehalten hat. Bei der Nutzung im Abonnement wird er nicht berechnet. Jedes Ergebnis stammt aus einem einzelnen Lauf, und Umfang und Anzahl unterscheiden sich von Lauf zu Lauf. Bei einer anderen Art von Aufgabe oder einem anderen Modell würden sich die Zahlen ändern. Die Cache-Schreibvorgänge des Prüfmodells entsprechen der Menge an Gespräch, die zur Prüfung geladen wurde. Der Gegenwert ist die Summe aus Arbeitsmodell und Prüfmodell.

Die tatsächlich formulierten Bedingungen

Dies sind die Bedingungen, die in den beiden /goal-Läufen nach /goal standen. Namen, die nur auf dieser Website gelten (das Prüfskript, die Arbeitsnotiz und die Werkzeuge zum Aktualisieren der Aufzeichnungen), haben wir durch Begriffe ersetzt, die deutlich machen, was sie tun. Die genauen Arbeitsschritte (Vorbilder für die Korrektur und Dateien, die nicht angefasst werden dürfen) standen in einer Arbeitsnotiz (einer Markdown-Datei). Die Bedingung verwies auf diese Datei.

# Kleinerer Lauf
Für den japanischen Text der Artikel 200 bis 209 (9 Artikel) meldet das Prüfskript für Satzschlusszeichen 0 Treffer (zeige die Prüfergebnisse aller 9 Artikel einzeln im Gespräch), und commit und push sind gemäß den Schritten in der Arbeitsnotiz abgeschlossen. Nach 30 Turns anhalten.

# Größerer Lauf
Für den japanischen Text der Artikel 100 bis 199 meldet das Prüfskript für Satzschlusszeichen 0 Treffer. Einhalten: Die Schritte in der Arbeitsnotiz befolgen (nur die Satzzeichen korrigieren, gemäß den festgelegten Vorbildern; Wörter, Bedeutung, Übersetzungen, Metadaten und Werkzeuge nicht ändern). Am Ende jedes Turns eine Zeile schreiben: „verbleibend ○ Treffer (○ Artikel)“. Am Ende im Gespräch zeigen: die Prüfergebnisse für alle 48 betroffenen Artikel, die Liste der geänderten Dateien (nur Text und Abgleich-Aufzeichnungen), eine bestandene Tag-Prüfung und das Ergebnis der Aktualisierung der Abgleich-Aufzeichnungen. Danach commit und push pfadbezogen abschließen. Nicht deployen. Nach 40 Turns anhalten.

Beim kleineren Lauf stand „jeden Turn die verbleibende Anzahl schreiben“ nur in der Arbeitsnotiz. Claude beendete die Arbeit, ohne es zu schreiben. Der Prüfer bewertete das Ziel als „erfüllt“ und vermerkte in der Begründung: „Die Anweisung im Ablauf wurde nicht befolgt, die Bedingung verlangt dies aber nicht.“ Diese Erkenntnis (Kapitel 4) haben wir in die Bedingung des größeren Laufs übernommen.

Kontrolle des fertigen Ergebnisses

Das „erfüllt“ des Prüfers haben wir nicht ungeprüft übernommen. Bei jedem Lauf haben wir die Unterschiede in einem separaten Gespräch Zeile für Zeile kontrolliert und die Prüfungen erneut ausgeführt.

6. Erkenntnisse: geeignete und ungeeignete Aufgaben

Mechanische Aufgaben sind in einem Turn erledigt

Jeder Lauf war in einem einzigen Turn fertig. Innerhalb eines Turns kann Claude Werkzeuge dutzendfach nutzen (der größere Lauf verwendete Bash 32-mal). Eine Aufgabe, die ein Skript erledigen kann, ist deshalb auch bei 321 Einträgen in einem Durchgang fertig. Der Hauptvorteil von /goal, dass bei Bedarf im nächsten Turn weitergemacht wird, kam bei dieser Art von Arbeit deshalb nie zum Tragen. Die Ergebnisse stammen jeweils aus einem Lauf pro Umfang. Zwischen dem normalen Richtwert und den beiden /goal-Läufen zeigten sich aber keine großen Unterschiede bei Zeit oder Ergebnisqualität. Der Mehraufwand betrug eine Prüfung pro Lauf, und jede Prüfung dauerte 5,6 bzw. 9,0 Sekunden (die gesamte Arbeit dauerte etwa 6 bzw. etwa 10 Minuten).

Der Prüfer liest das gesamte Gespräch

Im größeren Lauf las der Prüfer 114.410 Token, also das gesamte Arbeitsgespräch, so wie es übergeben wurde. Je länger das Gespräch, desto schwerer ist jede Prüfung. Bei Arbeiten mit vielen Turns oder wenn Sie /goal mitten in einem bereits langen Gespräch starten, dürften die Kosten der Prüfung höher ausfallen als in diesem Lauf.

Der Prüfer prüft, ob die Bedingung erfüllt ist

Der Prüfer kontrollierte die Punkte der Bedingung genau, etwa Prüfergebnisse oder das Vorhandensein eines Commits. Dagegen achtet er nicht auf Qualitäten, die sich nicht in Zahlen zeigen, etwa ob ein Satz natürlich klingt. „Erfüllt“ bedeutet, dass das, was in der Bedingung stand, im Gespräch erschienen ist. Es ersetzt nicht die Kontrolle des fertigen Ergebnisses.

Dieser Test hat nur „Arbeit, die in einem Turn fertig wird“ geprüft. Im Folgenden trennen wir die Beispiele aus der offiziellen Dokumentation von der eigenen Einschätzung der Verfasserin bzw. des Verfassers, welche Aufgaben geeignet sind.

7. Unterschiede zu Codex /goal

Auch OpenAIs Codex hat einen Befehl namens /goal. Das Konzept (weiterarbeiten, während eine Endbedingung eingehalten wird) ist dasselbe, die Bedienung und die Festlegung von Grenzen unterscheiden sich aber. Die ausführliche Anleitung für Codex finden Sie unter So verwenden Sie Codex /goal.

Quellen: Für Claude Code Keep Claude working toward a goal; für Codex Using Goals in Codex (OpenAI Cookbook) und der Artikel „So verwenden Sie Codex /goal“ dieser Website. Beides Stand 24. Oktober 2026.

Zusammenfassung

• /goal ist ein Befehl, bei dem Sie eine Endbedingung festlegen. Ein separates Modell prüft am Ende jedes Turns und lässt Claude weiterarbeiten, bis die Bedingung erfüllt ist. Festlegen, Status prüfen und Löschen erfolgen über denselben Befehl.
• Der Prüfer liest nur das Gespräch. Formulieren Sie die Bedingung so, dass Endzustand, Prüfweg und Erhaltenswertes sich anhand von Claudes Ausgabe belegen lassen, und nehmen Sie die Grenze ebenfalls auf.
• Der Berechtigungsmodus ändert sich nicht. Wenn Sie die Arbeit ganz abgeben möchten, kombinieren Sie /goal mit dem Modus Auto.
• In dem Test auf dieser Website war eine mechanische Aufgabe auch mit 321 Einträgen in einem Turn fertig. Bei dieser einen Aufgabe in einem Turn betrug der Mehraufwand eine Prüfung. Nach der Einschätzung der Verfasserin bzw. des Verfassers zeigt sich der Nutzen bei Arbeit, die sich nicht in einem Turn erledigen lässt.
• „Erfüllt“ bedeutet, dass das, was in der Bedingung stand, im Gespräch erschienen ist. Prüfen Sie die Qualität des fertigen Ergebnisses, etwa die Natürlichkeit der Sätze, gesondert.
• Wenn Sie in der Desktop-App eine ganze Bedingung einfügen, wird sie unter Umständen nicht als Befehl erkannt. Prüfen Sie das an der Zeile „Goal set:“.

So fangen Sie an: In den Modus Auto wechseln → die Bedingung in der Form aus Kapitel 4 formulieren (Endzustand, Prüfweg, Erhaltenswertes, Grenze) → /goal von Hand eingeben, die Bedingung einfügen und „Goal set:“ kontrollieren → nach „erfüllt“ die Unterschiede selbst lesen.

FAQ

F. Erhöht die Nutzung von /goal die Kosten?

Ja, und zwar um den Betrag der Prüfungen. Die Prüfungen laufen auf einem kleinen, schnellen Modell. Laut offizieller Dokumentation sind die Kosten „normalerweise sehr gering“. In dem Test auf dieser Website hatte die Arbeit, die in einem Turn fertig wurde, eine Prüfung, und sie dauerte einige Sekunden. Da der Prüfer aber das gesamte Gespräch liest, wird jede Prüfung umso schwerer, je länger das Gespräch ist.

F. Wie halte ich die Arbeit mittendrin an?

Entfernen Sie das Ziel mit /goal clear. stop und cancel wirken genauso. Wenn Sie mit claude -p arbeiten, stoppen Sie mit Strg+C. Das Entfernen des Ziels macht bisherige Änderungen nicht rückgängig.

F. Kann der Prüfer „noch nicht“ sagen, obwohl Claude meint, es sei fertig?

Ja. Deshalb prüft ein separates Modell. Sagt der Prüfer „noch nicht“, beginnt der nächste Turn mit seiner Begründung als Hinweis. Umgekehrt gilt: Erscheinen im Gespräch Ergebnisse, die der Bedingung entsprechen, lautet das Ergebnis „erfüllt“. Qualität, die Sie nicht in die Bedingung geschrieben haben, ist dann nicht garantiert.

F. Nach wie vielen Turns hört es auf?

Es gibt keine feste Obergrenze. Die Arbeit endet, wenn die Bedingung erfüllt ist, wenn sie als nicht erfüllbar beurteilt wird, wenn ein Fehler auftritt, der behoben werden muss, oder wenn Sie das Ziel entfernen. Wenn Sie eine Grenze möchten, schreiben Sie sie in die Bedingung, etwa „oder nach 20 Turns anhalten“. Der Prüfer liest nur das Gespräch. Deshalb hilft es, auch etwas wie „am Ende jedes Turns die Anzahl der bisherigen Turns angeben“ in die Bedingung aufzunehmen. (Keiner der Läufe in diesem Test endete in einem einzigen Turn. Deshalb haben wir das Anhalten an einer Grenze nicht getestet.)

F. Soll ich /loop oder /goal verwenden?

Verwenden Sie /goal, wenn der Endzustand feststeht. Verwenden Sie /loop, wenn Sie in festen Abständen dasselbe prüfen möchten. „Alle 5 Minuten nachsehen, bis das Deployment fertig ist“ passt zu /loop, „korrigieren, bis alle Tests laufen“ passt zu /goal.

Referenzen: Keep Claude working toward a goal, Run prompts on a schedule und Hooks guide (offizielle Dokumentation von Claude Code); Using Goals in Codex (OpenAI Cookbook). Geprüft am 24. Oktober 2026.