/goal in Claude Code: Autonomer Modus und Agent View im Jahr 2026

Ailoot-Referenzdokumentation: ailoot.ai/docs/.

Was ist /goal in Claude Code?#

Früher stoppte Claude Code nach jeder Antwort und wartete auf deinen nächsten Prompt. Bei kurzen Aufgaben funktionierte das, aber bei langen Aufgaben stieß es an Grenzen: eine API-Migration, 12 fehlgeschlagene Tests beheben, eine 800-zeilige Datei umstrukturieren – solche Aufgaben erfordern 20–30 Iterationen, und nach jeder kehrtest du zum Terminal zurück.

/goal löst dieses Problem mit einer einfachen Idee: „Die Person, die die Arbeit erledigt“ wird von „der Person, die entscheidet, wann sie fertig ist“ getrennt. Der Hauptagent schreibt Code. Ein separater Evaluator (das schnelle Modell Haiku) liest nach jedem Durchlauf die Unterhaltung und beantwortet eine Frage: „Ist die Bedingung erfüllt?“ Wenn nicht, beginnt der Agent einen weiteren Durchlauf. Wenn ja, wird die Kontrolle an dich zurückgegeben.

Die offizielle Dokumentation von Anthropic definiert es so:

Tausende Agenten nachts von einem Smartphone aus – das ist kein Marketing, sondern die aktuelle Praxis eines Anthropic-Ingenieurs. Möglich wird dies durch die Kombination aus /goal und Agent View, die am 11. Mai 2026 in derselben Veröffentlichung eingeführt wurde.

Warum wird der autonome Modus benötigt: Was gab es vor und nach dem 11. Mai 2026?#

Die Idee, „KI über Nacht arbeiten zu lassen“, gab es bereits seit Herbst 2025, als Cursor Composer und der Auto-Modus von Cline schon im Hintergrund laufen konnten. Doch vor dem 11. Mai 2026 brauchte man in Claude Code einen manuellen Wrapper dafür: eine Cron-Aufgabe, die alle N Minuten claude -p aufrief, oder einen Wrapper, der den Git-Status überwachte und den nächsten Prompt startete.

Dieser Do-it-yourself-Ansatz führte regelmäßig zu Kostenproblemen. Am 22. Mai 2026 ließ ein Entwickler ein solches Skript über Nacht laufen und fand morgens eine Rechnung über 6.000 $ vor. Die Ursache: Anthropic änderte stillschweigend die Cache-TTL von Claude Code von einer Stunde auf fünf Minuten, ohne dies anzukündigen. Cron rief die Produktion alle 30 Minuten auf – der Cache konnte zwischen den Läufen ablaufen. Bei jedem Lauf wurde ein Verlauf mit 800.000 Tokens von Grund auf neu erstellt. Neue Daten in den Cache zu schreiben kostet deutlich mehr, als aus einem aktiven Cache zu lesen.

Der Entwickler tat nichts Außergewöhnliches – er nutzte das Tool genau so, wie Anthropic es beworben hatte.

/goal löst dieses Problem mit einer integrierten Architektur:

1. Supervisor-Prozess, der die Sitzung außerhalb deines Terminals hält und das Schließen des Fensters sowie den Ruhezustand des Laptops übersteht.
2. Haiku-Evaluator – ein kostengünstiges Modell prüft jeden Durchlauf; die Tokens des Evaluators kosten nur wenige Cent.
3. Feste Zugbegrenzung in der Bedingung – du kannst ausdrücklich or stop after 20 turns schreiben, und die Sitzung wird garantiert beendet.
4. Worktree-Isolierung für Hintergrundsitzungen – Änderungen gehen in einen separaten Branch, ohne deine Arbeitskopie zu berühren.

Der Unterschied zum Ansatz „Schreib dein eigenes Bash-Skript“ besteht darin, dass Anthropic all diese Mechanismen zu festen Bestandteilen des Tools macht und nicht zu Hacks von Drittanbietern.

So aktivierst du /goal in 3 Schritten#

Schritt 1. Aktualisiere Claude Code auf Version 2.1.139 oder neuer.

Prüfe die Version:

claude --version

Wenn sie unter 2.1.139 liegt, aktualisiere:

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

Veröffentlichungen zwischen dem 12. und 19. Mai 2026 behoben wichtige Fehler in der ersten Version. In 2.1.140 wurde ein unbemerkter Stillstand behoben, bei dem disableAllHooks den Evaluator blockierte. In 2.1.143 kamen worktree.bgIsolation: "none" und eine Korrektur für Stop-Hook-Schleifen hinzu. In 2.1.144 (19. Mai) wurden --resume für Hintergrundsitzungen und --json für Agents-Skripte hinzugefügt. Die Mindestversion ist 2.1.143.

Schritt 2. Gib /goal mit einer Bedingung ein.

Öffne eine reguläre Claude-Code-Sitzung und gib den Befehl ein:

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

Danach musst du keinen separaten Prompt senden – der Befehl startet sofort den ersten Durchlauf. Die Bedingung kann auf Russisch, Englisch oder gemischt formuliert werden; das Modell versteht beide Sprachen. Die Längenbegrenzung liegt bei bis zu 4.000 Zeichen.

Schritt 3. Überwache die Sitzung über die Live-Einblendung.

Nach dem Start von /goal erscheint am unteren Rand des Terminals eine Live-Anzeige:

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

Sie zeigt Folgendes an:

• Durchläufe – wie viele Durchläufe abgeschlossen wurden
• Verstrichene Zeit – wie viel Zeit seit dem Start vergangen ist
• Tokens – insgesamt verbrauchte Tokens (die wichtigste Kennzahl zur Budgetüberwachung)
• Zuletzt – der letzte Grund des Evaluators für die Antwort „noch nicht“

Ein hilfreicher Trick: Wenn der Evaluator drei Durchläufe hintereinander denselben Grund nennt, ist das ein Zeichen für eine Schleife. Drücke dann Ctrl+C oder gib /goal clear ein (Synonyme: stop, off, reset, cancel), formuliere die Bedingung um und starte erneut. Diese Regel wird in Community-Anleitungen zu /goal als wichtigstes Zeichen einer Schleife genannt: „dreimal am selben Grund hängen – das ist eine Schleife, beende sie“.

So formulierst du eine gute Bedingung: 5 Regeln + 5 Beispiele#

Anthropics Dokumentation nennt drei notwendige Elemente einer guten Bedingung:

Eine fertige Vorlage deckt alle drei Elemente in einer Zeile ab:

/goal [die Arbeit erledigen] bis [messbarer Endzustand] ohne [zu beachtende Vorgaben]

Fünf Regeln, über die die meisten stolpern:

Regel 1. Der Endzustand muss sich mit einem Befehl prüfen lassen, nicht nach Geschmack.

Nicht „lass es gut aussehen“, sondern npm test exits 0. Nicht „verbessere die UX“, sondern Lighthouse Performance score above 90. Der Evaluator liest nur das Transkript – er führt keine Befehle aus und sieht keine Screenshots an. Wenn sich das Ergebnis nicht in Text festhalten lässt, wird der Evaluator niemals „ja“ sagen.

Regel 2. Vorgaben müssen ausdrücklich und eng gefasst sein.

Ohne Vorgaben könnte Claude Tests beheben, indem es die Tests selbst löscht oder fehlgeschlagene Assertions auskommentiert. Gib an: without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Regel 3. Eine feste Zugbegrenzung ist erforderlich.

Füge jeder Bedingung or stop after N turns hinzu. Das schützt vor Endlosschleifen. Ohne eine Begrenzung verbraucht eine Stunde Laufzeit mehr Tokens als die manuelle Erledigung derselben Aufgabe. Plane das Budget ein.

Eine Schleife, die eine Stunde läuft, verbraucht mehr Tokens, als dieselbe Aufgabe manuell zu erledigen. Plane das Budget ein.

Regel 4. Beschreibe WAS, nicht nur WIE.

Wenn du die visuellen Elemente in der Bedingung nicht erwähnst, erstellt Claude sie nicht. Wenn die Bedingung nur „Tests bestehen“ verlangt, könnte Claude komplexe Tests auskommentieren. Beschreibe, WAS du willst, nicht nur, WIE du es überprüfen wirst.

Regel 5. Lass Claude Belege im Chat zeigen.

Der Evaluator führt keine Befehle aus – er liest nur, was Claude bereits gezeigt hat. Wenn die Bedingung „npm test ist erfolgreich“ verlangt, Claude aber die Ausgabe von npm test nicht im Transkript gezeigt hat, wird der Evaluator endlos „noch nicht“ sagen. Füge der Bedingung den Satz „zeige die Ausgabe von <command> in der Unterhaltung“ hinzu.

Fünf funktionierende Beispiele für häufige Aufgaben:

1. API-Migration:
/goal jeden Aufruf von getUser() durch fetchUser() ersetzen, npm test besteht, npm run build ist erfolgreich, keine anderen API-Namen geändert, oder nach 30 Durchläufen stoppen

2. Tests reparieren:
/goal alle fehlgeschlagenen Tests in test/auth bestehen jetzt (npm test zeigt im Chat 0 Fehler), ohne Assertions zu ändern oder Tests zu löschen, oder nach 20 Durchläufen stoppen

3. Codequalität (Dateigröße):
/goal src/legacy/UserService.ts in Dateien mit jeweils weniger als 200 Zeilen aufteilen, alle Imports aktualisieren, npm run build ist erfolgreich, oder nach 25 Durchläufen stoppen

4. Backlog abarbeiten:
/goal jedes mit 'good-first-issue' markierte Issue bearbeiten: Beschreibung lesen, eine Korrektur in einem Worktree-Branch implementieren, einen PR eröffnen. Fortfahren, bis die Warteschlange leer ist oder 6 Issues bearbeitet wurden

5. Sicherheitsaudit:
/goal jede npm audit-Sicherheitslücke mit Schweregrad >= high beheben, alle bestehenden Tests bestehen, keine inkompatiblen API-Änderungen, oder nach 15 Durchläufen stoppen

Möchtest du mehr tun, als nur /goal auszuführen, und eine Umgebung aufbauen, in der der autonome Modus wirklich in deinem Projekt funktioniert? /goal ist nur das letzte Glied. Davor müssen drei Säulen vorhanden sein: ein KI-Klon (deine Methodik in Skills und Subagents), ein zweites Gehirn (CLAUDE.md und ein plans/-Ordner) und Context Engineering (Plan Mode und /compact). Alle drei Komponenten sollten gemeinsam durchdacht werden – diese Kombination ermöglicht die Arbeit mit Kontext.

5 Beispiele, in denen /goal wirklich funktioniert#

Anthropics Dokumentation nennt vier Aufgabentypen, für die /goal gut geeignet ist:

Hier sind fünf Beispiele mit fertigen Bedingungen – übernimm sie und passe sie an dein Projekt an.

Beispiel 1. Ein Modul zu einer neuen API migrieren.

Szenario: Du wechselst von REST zu GraphQL oder ersetzt die alte Funktion getUser() durch die neue Funktion fetchUser(). Die Aufgabe ist mechanisch, betrifft aber 30–50 Dateien.

Bedingung:

/goal jedes getUser() in src/ durch fetchUser() ersetzen, alle Aufrufe auf die neue Schnittstelle aktualisieren (id statt userId), npm test besteht, keine Dateien außerhalb von src/ angefasst, oder nach 30 Durchläufen stoppen

Warum das funktioniert: Der Endzustand lässt sich mit grep -r getUser src/ | wc -l prüfen (sollte 0 sein) und mit npm test exits 0. Die Vorgabe schützt Testdateien.

Beispiel 2. Fehlgeschlagene Tests reparieren.

Szenario: Nach einer Bibliotheksaktualisierung sind 15 Tests fehlgeschlagen. Du weißt, dass die Korrektur mechanisch ist – Mocks aktualisieren und Assertions an das neue Format anpassen. Du möchtest das nicht von Hand erledigen.

Bedingung:

/goal alle fehlgeschlagenen Tests in test/ bestehen jetzt, npm test zeigt die Ergebnisse im Chat mit 0 Fehlern, ohne Tests zu löschen oder Assertions auszukommentieren, oder nach 25 Durchläufen stoppen

Ein Beispiel für eine solche Bedingung:

Behebe alle fehlgeschlagenen Tests, bis npm test 0 zurückgibt, ohne Dateien außerhalb des Verzeichnisses /auth zu ändern

Beispiel 3. Eine God Class aufteilen.

Szenario: Eine Datei mit 1.200 Zeilen enthält alles – Modell, Service, Hilfsfunktionen und API-Client. Du möchtest sie nach dem Prinzip „eine Datei, eine Verantwortung“ aufteilen, alle Imports aktualisieren und die Tests bestehen lassen.

Bedingung:

/goal src/legacy/UserService.ts in Dateien mit weniger als 200 Zeilen aufteilen, jede Datei erfüllt eine Aufgabe (model, repository, api-client, validator), alle Imports aktualisieren, npm run build ist erfolgreich, bestehende Tests bestehen, oder nach 25 Durchläufen stoppen

Beispiel 4. Den Issue-Backlog über Nacht schließen.

Szenario: Du hast ein Open-Source-Repository mit 20 Issues, die mit good-first-issue markiert sind. Du möchtest, dass Claude sie über Nacht abarbeitet.

Bedingung:

/goal jedes mit 'good-first-issue' markierte Issue bearbeiten: Beschreibung lesen, eine Korrektur in einem separaten Worktree-Branch worktree-issue-N implementieren, einen PR mit Beschreibung eröffnen. Fortfahren, bis die Warteschlange leer ist oder 6 Issues bearbeitet wurden, oder nach 80 Durchläufen stoppen

Die Zahl 6 wurde nicht willkürlich gewählt – sie ist ein realistischer Grenzwert für eine Nacht im Pro-Tarif. Dieser Wert ist ein individueller Fall, kein reproduzierbarer Standardwert.

Beispiel 5. Sicherheitsaudit.

Szenario: npm audit zeigt 8 Sicherheitslücken mit hohem Schweregrad. Du möchtest, dass Claude sie behebt, ohne Hauptversionen zu aktualisieren.

Bedingung:

/goal jede npm audit-Sicherheitslücke mit severity high+ beheben, npm audit zeigt im Chat 0 mit hohem Schweregrad, alle bestehenden Tests bestehen, keine inkompatiblen API-Änderungen, keine Aktualisierung der Hauptversionen von Paketen, oder nach 15 Durchläufen stoppen

Was du mit /goal NICHT tun solltest:

Croucher formuliert die Faustregel in seinem Field Guide sehr deutlich: Verwende /goal nicht für Aufgaben, bei denen „fertig“ bedeutet: „sieht gut aus“, „fühlt sich richtig an“, „gut gestaltet“ oder „macht Spaß“. Der Evaluator liest nur das Transkript – er führt keine Tools aus und kann nicht beurteilen, wie das Ergebnis funktioniert. Damit sind 80 % der subjektiven Aufgaben ausgeschlossen, bei denen /goal ohne nützliche Ausgabe in einer Schleife hängt.

Wann /goal umsonst Geld verbrennt: 3 Anti-Patterns#

Anti-Pattern 1. Vage Bedingung ohne feste Zugbegrenzung.

Der häufigste Fehler ist eine Bedingung wie „verbessere den Code“ / „mach ihn gut“ / „optimiere ihn“. Ohne Zugbegrenzung läuft der Agent weiter, bis er dein Kontingent aufgebraucht hat.

Findskill beschreibt einen konkreten Fall:

200 $ für 14 Stunden mit einer vagen Bedingung entsprechen dem gesamten Wochenlimit im Max-Tarif. Du wachst morgens ohne Kontingent und ohne nützliches Ergebnis auf.

Schutzmaßnahme: Beende jede Bedingung mit or stop after N turns (15 bei einfachen Aufgaben, 50 bei schwierigen und höchstens 100 bei nächtlichen Läufen).

Anti-Pattern 2. Rekursive Schleife mit defektem Caching.

Die Geschichte vom 22. Mai 2026: 6.000 $ über Nacht, weil Anthropic die Cache-TTL stillschweigend von einer Stunde auf 5 Minuten änderte. Der Entwickler verwendete /goal nicht direkt, aber die Logik war dieselbe: Eine autonome Schleife mit einem 30-Minuten-Cron-Timer erstellte jedes Mal von Grund auf einen Verlauf mit 800.000 Tokens neu.

Das Grundproblem war, dass die externe Automatisierung nichts von den internen Änderungen des Anbieters wusste. Dasselbe könnte mit /goal passieren, wenn du es 8 Stunden ohne Aufsicht laufen lässt: Der Tokenverbrauch wächst nichtlinear, und der Prompt-Cache funktioniert möglicherweise anders, als du denkst.

Schutzmaßnahmen:

1. Lass /goal nicht 8+ Stunden ohne Zwischenkontrollen laufen.
2. Aktiviere Nutzungsgrenzen unter Einstellungen → Nutzung (eine neue Schutzmaßnahme nach dem Vorfall mit 6.000 $).
3. Öffne claude agents über Nacht zweimal – wirf mit Space einen kurzen Blick darauf und prüfe, ob die Zahl der Durchläufe nicht schneller steigt als erwartet.
4. Lege bei teuren Modellketten (Opus 4.7) eine strengere Zugbegrenzung fest – höchstens 30.

Anti-Pattern 3. Kreativität mit /goal.

Croucher ließ mit /goal ein Spiel erstellen – die Bedingung umfasste Determinismus, Invarianten und die Prüfung, ob das Level zu schaffen war. Das Spiel wurde erstellt, die Tests bestanden, und der Evaluator meldete „erreicht“. Das Spiel hatte keine visuellen Elemente – die Bedingung erwähnte Grafik nicht.

Das veranschaulicht die allgemeine Regel: Der Evaluator optimiert genau das, was du misst. Wenn die Bedingung visuelle Elemente nicht erwähnt, gibt es keine. Wenn sie nur Tests nennt, könnte Claude Assertions auskommentieren.

Schutzmaßnahme: Verwende /goal nicht für Aufgaben, die vom Geschmack abhängen (Design, Texte, UX). Kehre zu einer regulären Sitzung oder zum Plan Mode zurück – dort bleibst du in der Entscheidungsschleife.

Was ist Agent View und wie öffnet man das Dashboard?#

Wenn /goal der Befehl „arbeite, bis du fertig bist“ ist, dann ist Agent View der Kontrollraum, in dem du all diese Befehle gleichzeitig sehen kannst. Anthropic beschreibt es so:

Befehl zum Öffnen:

claude agents

Eine TUI wird geöffnet – ein textbasiertes Dashboard im Terminal. Die Sitzungsliste befindet sich links, der Peek-Bereich mit der neuesten Nachricht der ausgewählten Zeile rechts.

Sechs Sitzungsstatus:

Wichtige Tastenkürzel:

↑ / ↓             in der Sitzungsliste bewegen
Space             Peek-Bereich (Ansicht ohne Verbinden)
Enter / →         mit einer Sitzung verbinden (öffnen)
←                 Verbindung trennen (beenden, ohne sie zu schließen)
Ctrl+T            anheften (Sitzung vor automatischem Stoppen schützen)
Ctrl+X            Sitzung stoppen; zum Löschen innerhalb von 2 sec erneut drücken
Ctrl+R            umbenennen
Ctrl+S            Gruppierung umschalten (Status ↔ Verzeichnis)

So startest du eine Hintergrundsitzung:

Über Claude Code im interaktiven Modus:

/bg fix the failing test test/auth/login.test.ts

Oder direkt über die Shell:

claude --bg "fix the failing test test/auth/login.test.ts"

Oder mit einem Namen (damit sie in Agent View unter einer erkennbaren Bezeichnung erscheint):

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

Die Hintergrundsitzung wird automatisch zu Agent View hinzugefügt – starte sie mit --bg, öffne claude agents, und du siehst sie in der Liste.

Die wichtigste Funktion: Sitzungen überstehen den Ruhezustand des Laptops und das Schließen des Fensters:

Doch wenn du den Laptop herunterfährst oder manuell neu startest, enden die Hintergrundsitzungen mit dem Status Failed. Übernachtläufe mit vielen Hintergrundagenten funktionieren nur, wenn der Laptop eingeschaltet bleibt.

Worktrees: So isoliert Claude parallele Sitzungen#

Worktrees lösen das Hauptproblem paralleler autonomer Arbeit: Was ist, wenn zwei Sitzungen gleichzeitig src/auth.ts bearbeiten wollen? Vor 2.1.139 konnten solche Sitzungen die Änderungen der jeweils anderen buchstäblich überschreiben. Mit Agent View führte Anthropic eine automatische Isolierung ein:

So funktioniert es in der Praxis:

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate repo copy on branch worktree-split-userservice

Jede Sitzung arbeitet in ihrer eigenen Kopie. Wenn die Aufgabe erledigt ist, führst du die benötigten Branches in main zusammen.

Gefährliche Falle – das Löschen einer Sitzung löscht ihren Worktree.

Wenn du eine Sitzung in Agent View beendest (zweimal Ctrl+X drücken), verschwindet ihr Worktree. Alle nicht committeten Änderungen gehen verloren. Bevor du eine Sitzung in Agent View löschst, solltest du immer committen oder pushen.

Opt-out (für seltene Fälle):

Wenn du ein Repository hast, in dem Git-Worktrees nicht funktionieren (zum Beispiel eine Einrichtung mit Symlinks oder ein großes Monorepo mit langsamem Checkout), kannst du die Isolierung deaktivieren:

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

Dann bearbeiten Hintergrundsitzungen direkt deine Arbeitskopie. Diese Opt-out-Möglichkeit kam in 2.1.143 nach Beschwerden von Teams mit großen Monorepos hinzu.

Parallelität verbraucht Kontingent:

Das bedeutet: Ein Pro-Tarif (20 $/Monat) reicht über Nacht für 1–2 parallele Sitzungen, nicht für zehn. Wenn du viele Agenten parallel ausführen möchtest, brauchst du Max oder Enterprise.

/goal, Plan Mode und Subagents für lange Aufgaben kombinieren#

Ein typischer Fehler ist, sofort /goal build a new feature einzugeben. Das funktioniert nicht, weil der Evaluator nicht weiß, wie ein „fertiges Feature“ aussieht. Du brauchst einen Plan mit Kontrollkästchen, die der Evaluator einzeln überprüfen kann.

Ebene 1. Plan Mode erstellt einen mehrstufigen Plan.

Bitte Claude im Plan Mode, einen detaillierten Änderungsplan in 5–7 Phasen mit überprüfbaren Kontrollkästchen zu erstellen. Speichere ihn unter plans/2026-05-24-google-oauth.md. Jede Phase umfasst 3–7 Kontrollkästchen mit konkreten Aufgaben.

Ebene 2. Subagents teilen die Arbeit nach Phasen auf.

Wenn sich der Plan parallelisieren lässt (zum Beispiel, weil die Phasen unabhängig sind – ein Backend-Endpunkt, ein Frontend-Formular und eine DB-Migration), kannst du jede Phase über claude --bg --name "<phase>" in einer separaten Hintergrundsitzung starten. Jede Sitzung erhält ihren eigenen Worktree.

Ebene 3. /goal führt den Zyklus aus, bis die Kontrollkästchen erledigt sind.

/goal alle Phasen 1–7 in plans/2026-05-24-google-oauth.md sind abgeschlossen und mit [x] markiert, alle Tests in test/auth bestehen (npm test zeigt 0 Fehler), npm run build ist erfolgreich, oder nach 50 Durchläufen stoppen

Nach jedem Durchlauf liest der Evaluator den Plan, prüft, welche Kästchen erledigt sind, und wenn etwas offen bleibt, macht der Agent weiter.

Diese Kombination beruht auf drei Komponenten:

• Context Engineering: der richtige Kontext in plans/ – der Evaluator liest ihn
• zweites Gehirn: Der Ordner plans/ speichert den Plan zwischen den Sitzungen
• KI-Klon: CLAUDE.md legt die Regeln fest, denen der Agent folgt

Ohne CLAUDE.md könnte /goal eine Lösung vorschlagen, die die Architektur beschädigt. Ohne einen Plan in plans/ kennt der Evaluator die Erfolgskriterien nicht. Ohne Subagents gibt es keine parallelen Phasen – alles läuft nacheinander.

Wie du /goal mit Codex, Cursor und anderen Agentenmodi vergleichst#

/goal ergänzt nach jedem Durchlauf eine separate Abschlussprüfung. Andere Produkte haben unterschiedliche Modi. Eine lokale CLI, eine gehostete Cloud-Aufgabe und eine beaufsichtigte Editorsitzung sind keine austauschbaren Vergleichseinheiten. Beschreibe insbesondere nicht jede Codex-CLI-Arbeit als Cloud-Container und unterstelle nicht jedem Lauf dasselbe Validatormodell oder dieselbe Abrechnung.

Nutze denselben Repository-Stand, dieselbe Aufgabe und identische Abnahmeprüfungen. Halte je Kandidat fest:

Ein fester Tokenmultiplikator braucht diese Bedingungen und gemessene Verbräuche für dasselbe erfolgreiche Ergebnis. Ein Benchmark-Prozentwert braucht ebenso Benchmarkversion, Modell, Harness und Laufeinstellungen. Terminal-Bench-Prozentwerte ohne diese Angaben ersetzen solche Nachweise nicht. Dieser Artikel liefert keinen unabhängigen Vergleichsbenchmark.

Entscheide nach dem benötigten Ablauf: beaufsichtigte Bearbeitung, begrenzte Hintergrundaufgabe oder mehrstufige Arbeit mit ausdrücklicher Abschlussbedingung. Teste den unterstützten Modus des installierten Produkts, statt einem Wettbewerber pauschal Autonomie abzusprechen. Trenne Berechtigungsfreigabe von Aufgabenfortsetzung: Ein automatisch genehmigter Toolaufruf belegt nicht, dass das Nutzerziel erreicht ist.

/goal im Vergleich zu /loop:

/loop ist ein weiterer Befehl aus derselben Veröffentlichung und startet periodische Aufgaben in einem Zeitintervall (alle N Minuten). /goal ist bedingungsbasiert (bis die Bedingung erfüllt ist). Verwende /loop für Cron-ähnliche Aufgaben und /goal, wenn ein bestimmtes Ziel erreicht werden soll.

Aus der Dokumentation von Anthropic:

Checkliste vor dem Start von /goal: 7 Punkte#

Checkliste vor jedem /goal-Lauf:

1. Claude-Code-Version 2.1.139+ – Prüfe mit claude --version und aktualisiere, wenn die Version niedriger ist. Die empfohlene Mindestversion ist 2.1.143 (15. Mai 2026), in der Stop-Hook-Schleifen behoben wurden.

2. Die Bedingung enthält einen überprüfbaren Endzustand – Statt „verbessere es“ gib npm test exits 0 an. Wenn dir kein bash-Befehl einfällt, mit dem sich das Ergebnis überprüfen lässt, ist /goal für diese Aufgabe nicht geeignet.

3. Es gibt eine feste Zugbegrenzung – Jede Bedingung enthält or stop after N turns. Verwende 15 für einfache Aufgaben, 50 für schwierige und höchstens 100 für nächtliche Läufe.

4. Vorgaben sind ausdrücklich und eng gefasst – without modifying files outside /auth, without removing existing assertions, without bumping major versions. Ohne diese Vorgaben könnte Claude Tests beheben, indem es die Tests selbst löscht.

5. Alle wichtigen Änderungen sind committet oder gepusht – Wenn du nicht in einem Worktree arbeitest (zum Beispiel mit worktree.bgIsolation: "none"), bearbeitet Claude deine Arbeitskopie. Ein Fehler könnte dazu führen, dass nicht gespeicherte Arbeit verloren geht.

6. Nutzungsgrenzen sind unter Einstellungen → Nutzung aktiviert – Eine neue Schutzmaßnahme nach dem Vorfall mit 6.000 $. Lege ein Limit pro Tag, pro Sitzung und pro Monat fest.

7. Agent View claude agents ist in einem separaten Fenster geöffnet – Bei langen Aufgaben wirf einmal pro Stunde mit Space einen kurzen Blick darauf. Wenn die Zahl der Durchläufe schneller als erwartet steigt oder der Evaluator drei Durchläufe lang denselben Grund wiederholt, drücke Ctrl+C und formuliere die Bedingung um.

Ein zusätzlicher Punkt – führe /goal bei fremdem oder unbekanntem Code niemals mit --dangerously-skip-permissions aus. Diese Kombination deaktiviert alle Prüfungen und lässt den Agenten in deinem Projekt tun, was er will. Der Autor dieser Analyse verwendet sie nur in einem frischen Worktree, in dem nichts zu verlieren ist.

/goal ist leistungsstark, aber keine Zauberei. Es funktioniert genau so gut, wie du die Bedingung formulierst. Wenn du „fertig“ in Worten so beschreiben kannst, dass ein Befehl es überprüfen kann, erledigt /goal den Rest. Wenn nicht, kehre zu einer regulären Sitzung oder zum Plan Mode zurück.

Entdecke Ailoot weiter unter ailoot.ai.