Claude Code länger arbeiten lassen: /loop, /goal und günstige Sub-Agenten

Wer mit Claude Code arbeitet, kennt das: Man gibt eine Aufgabe rein, der Agent legt los, und nach ein paar Minuten meldet er sich mit „Fertig!“. Nur ist es dann oft gar nicht fertig. Ein Test schlägt noch fehl, eine Datei wurde vergessen, oder er hat auf halber Strecke beschlossen, dass der Rest „ein guter nächster Schritt“ wäre. Dann tippt man wieder „mach weiter“. Und noch mal.
Ich nutze Claude Code inzwischen regelmäßig, für Websites, Android-Apps und kleinere Tools. Drei Funktionen haben meine Arbeitsweise dabei ziemlich verändert: /loop, /goal und Sub-Agenten, die mit einem kleineren Modell laufen. Die ersten beiden sorgen dafür, dass der Agent dranbleibt. Die dritte sorgt dafür, dass das nicht ins Geld geht.
/goal: Fertig ist, wenn es fertig ist
Mit /goal legt man fest, wann eine Aufgabe als erledigt gilt. Und zwar als Bedingung, nicht als Bitte. Zum Beispiel:
/goal Alle Tests in tests/ laufen grün und npm run build wirft keine FehlerDanach arbeitet Claude ganz normal. Der Unterschied kommt am Ende: Bevor er aufhört, wird geprüft, ob die Bedingung wirklich erfüllt ist. Wenn nicht, geht es weiter. Statt „sollte jetzt funktionieren“ gibt es also erst Ruhe, wenn der Build tatsächlich durchläuft.
Ein paar Dinge habe ich dabei gelernt:
- Die Bedingung muss prüfbar sein. „Der Code ist schön“ bringt nichts. „PHPStan meldet auf Level 6 keine Fehler“ dagegen schon.
- Kurz halten. Ein Ziel, nicht fünf.
- Mit
/goalohne Text sieht man das aktuelle Ziel, mit/goal clearwird es wieder gelöscht.
Gerade bei Aufräumarbeiten ist das Gold wert. Alte Funktionen umbenennen, Typen nachziehen, Warnungen beseitigen: alles Dinge, bei denen der Agent sonst gern nach der Hälfte stehen bleibt.
/loop: Immer wieder dasselbe, nur automatisch
/loop ist für Aufgaben gedacht, die sich wiederholen. Man gibt einen Prompt mit und optional einen Takt:
/loop 10m Prüfe, ob der CI-Lauf für meinen Branch durch ist, und behebe Fehler, falls einer rot istDann führt Claude den Prompt alle zehn Minuten erneut aus. Lässt man die Zeitangabe weg, entscheidet er selbst, wann er sich wieder meldet. Das ist praktisch, wenn man auf etwas wartet, dessen Dauer man nicht kennt, etwa einen Deploy oder ein langes Build.
Wofür ich das nutze:
- Pull Requests im Auge behalten und auf Review-Kommentare reagieren
- Logdateien in Abständen auf neue Fehler durchsehen
- Eine lange Liste abarbeiten, Stück für Stück
Wichtig ist der Unterschied zu /goal. Der Loop läuft, bis man ihn stoppt. Das Goal endet, sobald die Bedingung erfüllt ist. Man kann beides auch kombinieren: Ein Loop, der regelmäßig nachsieht, und ein Ziel, das festlegt, wann Schluss ist.
Das Problem: Tokens
Wer Claude Code so lange laufen lässt, merkt es irgendwann am Verbrauch. Jede Runde liest Dateien, sucht im Code, schaut sich Ausgaben an. Und wenn das alles das große Modell macht, das man eigentlich fürs Nachdenken braucht, wird es teuer. Mit einem Abo stößt man schneller an das Limit, mit API-Abrechnung sieht man es direkt auf der Rechnung.
Dabei ist ein Großteil dieser Arbeit gar nicht anspruchsvoll. Wo wird die Funktion überall aufgerufen? Was steht in den letzten 200 Zeilen vom Log? Welche Dateien importieren dieses Modul? Dafür braucht es kein Opus.
Sub-Agenten mit kleinerem Modell
Hier kommen Sub-Agenten ins Spiel. Claude Code kann Teilaufgaben an eigene Agenten abgeben. Die arbeiten in ihrem eigenen Kontext und liefern am Ende nur das Ergebnis zurück. Das hat zwei Vorteile: Der Hauptagent bleibt übersichtlich, weil nicht hunderte Zeilen Suchergebnisse in seinem Verlauf landen. Und der Sub-Agent kann mit einem anderen Modell laufen.
Angelegt wird so ein Agent als Markdown-Datei unter .claude/agents/ im Projekt (oder unter ~/.claude/agents/ für alle Projekte). Bei mir sieht das zum Beispiel so aus:
---
name: sucher
description: Durchsucht den Code und fasst Fundstellen kurz zusammen. Für alle reinen Such- und Leseaufgaben verwenden.
model: haiku
tools: Read, Grep, Glob
---
Du suchst im Projekt nach dem, was verlangt wird.
Antworte knapp: Datei, Zeile, ein Satz dazu. Keine Änderungen am Code.Die Zeile model: haiku ist der eigentliche Trick. Haiku ist deutlich günstiger als Opus und für Suchen und Zusammenfassen völlig ausreichend. Mit tools begrenze ich außerdem, was der Agent darf. Der Sucher kann nur lesen, nichts kaputt machen.
Bei mir haben sich drei Stufen eingespielt:
| Aufgabe | Modell |
|---|---|
| Suchen, Logs lesen, Dateien zusammenfassen | Haiku |
| Tests schreiben, kleine Änderungen nach klarer Vorgabe | Sonnet |
| Planen, Architektur, knifflige Fehler | Opus (Hauptsitzung) |
Die Hauptsitzung bleibt also beim großen Modell und verteilt die Arbeit. Ob Claude einen Sub-Agenten von selbst nimmt, hängt stark von der description ab. Je klarer da steht, wofür er gedacht ist, desto zuverlässiger wird er genutzt. Man kann es aber auch einfach sagen: „Lass den Sucher nachsehen, wo überall sendMail aufgerufen wird.“
Alles zusammen
Richtig gut wird es, wenn man die drei Sachen kombiniert. Ein typischer Ablauf bei mir:
/goalsetzen, zum Beispiel: alle PHP-Dateien im Plugin sind auf die neue Datenbankklasse umgestellt und die Tests laufen.- Claude plant den Umbau mit dem großen Modell.
- Die Fleißarbeit (welche Dateien sind betroffen, wo hängt was dran) erledigt der Haiku-Sucher.
- Die eigentlichen Änderungen macht die Hauptsitzung oder ein Sonnet-Agent.
- Vor dem Aufhören wird das Ziel geprüft. Ist es nicht erreicht, geht es in die nächste Runde.
Ich muss dabei nicht danebensitzen. Und am Ende ist die Aufgabe wirklich erledigt, nicht nur „größtenteils“.
Worauf man achten sollte
Ein Agent, der selbstständig weiterarbeitet, macht auch selbstständig Fehler. Ein paar Regeln, die ich mir angewöhnt habe:
- Lange Läufe nur in einem eigenen Git-Branch oder Worktree. Dann ist im Zweifel nichts verloren.
- Berechtigungen nicht pauschal freigeben. Lieber vorher festlegen, welche Befehle ohne Rückfrage laufen dürfen.
- Ab und zu reinschauen. Gerade bei
/loopohne festen Takt sollte man wissen, was da gerade passiert. - Sub-Agenten nicht zu klein wählen. Wenn Haiku für eine Aufgabe dreimal neu ansetzen muss, ist am Ende nichts gespart.
Fazit
/goal sorgt dafür, dass Claude Code nicht zu früh aufhört. /loop übernimmt wiederkehrende Aufgaben, ohne dass man daneben warten muss. Und mit Sub-Agenten auf Haiku oder Sonnet bleibt der Verbrauch im Rahmen, weil das teure Modell nur noch das macht, wofür man es wirklich braucht.
Am Anfang hat es ein bisschen gedauert, bis ich die passenden Ziele und Agenten gefunden hatte. Inzwischen möchte ich darauf nicht mehr verzichten.
Christian Ackermann
Softwareentwickler (C++, C, Java, C#) aus der Oberpfalz, bloggt seit 2001 über Linux, Technik und Kochen.