Subagents die Subagents spawnen, die 5-Ebenen-Regel von Claude Code

Bis vor Kurzem war ein Subagent-Setup flach. Ein Coordinator hat Worker gestartet, und da war Schluss. Ein Worker konnte selbst keinen weiteren Subagent spawnen. Seit dem Changelog-Eintrag von Anfang Juni ist das anders, Subagents dürfen jetzt eigene Subagents starten, bis zu fünf Ebenen tief. Das klingt erstmal nach mehr Power. In der Praxis ist es vor allem eine neue Art sich Kosten und Kontext zu zerschießen, wenn man es ohne Plan macht. Ich hab das eine Woche mit verschiedenen Tiefen getestet und bin bei einer ziemlich konservativen Regel gelandet. Dieses Playbook zeigt sie Dir.

Voraussetzung: Du hast "Dein erster Sub-Agent in 30 Minuten" durch und kennst das CEO-Worker-Pattern aus Level 5 Lesson 2. Wenn Du schon ein Team aus mehreren Subagents fährst, ist auch "Subagent-Team strukturieren" eine gute Grundlage.

1. Was sich geändert hat

Früher galt eine harte Regel: nur die Hauptsession startet Subagents. Ein Subagent war ein Sackgassen-Worker, er erledigt seine Aufgabe und gibt das Ergebnis zurück. Jetzt kann jeder Subagent selbst wieder welche starten, und das geht rekursiv weiter bis Ebene fünf. Ebene null ist Deine Hauptsession, Ebene eins der erste Worker, und so weiter bis Ebene fünf, dann ist die Grenze erreicht und ein weiterer Spawn wird abgelehnt.

Wichtig zu verstehen: fünf Ebenen ist eine Obergrenze, kein Ziel. Die meisten guten Setups bleiben bei Ebene eins oder zwei. Tiefe ist ein Werkzeug für genau einen Fall, und den schauen wir uns gleich an.

2. Warum Tiefe selten die Antwort ist

Jede Ebene multipliziert. Wenn Dein Coordinator drei Worker startet und jeder dieser Worker wieder drei startet, bist Du auf Ebene zwei schon bei neun parallelen Subagents. Eine Ebene tiefer sind es 27. Jeder davon hat seinen eigenen Kontext, seine eigenen Token, seine eigene Latenz. Ich hatte einen Test wo ich naiv drei mal drei mal drei aufgemacht hab, und ein simpler Recherche-Auftrag hat statt der erwarteten zwei Dollar plötzlich elf gekostet. Nicht weil die Arbeit größer war, sondern weil 27 Subagents jeweils den halben Kontext nochmal aufgebaut haben.

Mein Daumenwert: jede zusätzliche Ebene rechtfertigt sich nur, wenn die Aufgabe auf der Ebene wirklich in unabhängige Teilaufgaben zerfällt die parallel laufen können. Sonst baust Du eine teure Hierarchie für etwas das ein einzelner Worker sequenziell erledigt hätte.

3. Die eine Stelle wo Tiefe wirklich hilft

Der Fall der Tiefe rechtfertigt heißt Fan-out bei Recherche. Stell Dir vor Du willst fünf Konkurrenten analysieren, und pro Konkurrent gibt es vier Unterfragen. Hier ergibt eine zweite Ebene Sinn: Ebene eins ist ein Researcher pro Konkurrent, Ebene zwei je ein Worker pro Unterfrage. Jeder Worker auf Ebene zwei arbeitet mit einem schmalen, klar abgegrenzten Auftrag und braucht den großen Kontext der oberen Ebenen gar nicht.

Das funktioniert weil die Teilaufgaben echt unabhängig sind. Konkurrent A hängt nicht an Konkurrent B, Unterfrage eins nicht an Unterfrage zwei. Genau diese Unabhängigkeit ist die Bedingung. Wenn Deine Teilaufgaben aufeinander aufbauen, gehört das nicht in parallele Subagents sondern in einen sequenziellen Plan.

4. Ebenen-Budget vorher festlegen

Bevor Du irgendwas startest, schreib in die CLAUDE.md oder in den Subagent-Prompt eine harte Grenze. Bei mir steht im Coordinator-Prompt ein Satz wie "Du darfst maximal Ebene zwei aufmachen, also Du selbst startest Worker, und diese Worker dürfen nochmal genau eine Ebene tiefer gehen wenn die Aufgabe in unabhängige Teile zerfällt. Tiefer nicht."

Das ist wichtiger als es klingt. Ohne diese Grenze tendiert ein Coordinator dazu, bei jeder Unklarheit einen weiteren Subagent zu starten statt selbst nachzudenken. Die Fünf-Ebenen-Grenze des Systems fängt Dich erst am absoluten Limit, da hast Du schon längst zu viel Geld verbrannt. Setz Deine eigene Grenze deutlich darunter.

5. Permission-Vererbung verstehen

Ein tiefer Subagent erbt nicht automatisch dieselben Rechte wie sein Parent, und das ist gut so. Du legst pro Subagent-Definition fest welche Tools und welche Permission-Scopes erlaubt sind. Ein Researcher auf Ebene zwei sollte typischerweise nur lesen und recherchieren dürfen, niemals Files schreiben.

Mein Muster: je tiefer die Ebene, desto enger die Rechte. Der Coordinator auf Ebene eins darf Drafts anlegen und Ergebnisse zusammenführen. Die Worker auf Ebene zwei dürfen nur lesen und Bericht zurückgeben. So kann ein tiefer Subagent im schlimmsten Fall Quatsch recherchieren, aber nicht Deine Files anfassen. Wer Permission-Profile noch nicht sauber im Griff hat, sollte vorher das Recipe zu settings und Permissions durcharbeiten.

6. Kontext-Isolation pro Ebene

Jeder Subagent hat einen eigenen Kontext, er sieht nicht automatisch was der Parent gesehen hat. Du gibst ihm im Spawn-Auftrag genau das mit was er braucht. Das ist der eigentliche Hebel gegen die Kosten-Explosion aus Schritt 2.

Konkret heißt das: gib einem Worker auf Ebene zwei nicht den ganzen Recherche-Stand mit, sondern nur die eine Unterfrage plus die zwei, drei Fakten die er als Ausgangspunkt braucht. Je schmaler der Auftrag, desto billiger der Subagent und desto schärfer das Ergebnis. Ein Worker der mit drei Sätzen Kontext startet und einen klaren Bericht zurückgibt ist genau das was Du willst.

7. Kosten messen mit /usage

Seit dem Juni-Update zeigt /usage in VSCode eine Aufschlüsselung pro Subagent, Skill, Plugin und MCP-Server über die letzten 24 Stunden oder sieben Tage. Nutz das. Nach einem tiefen Run schaust Du Dir an wo die Token wirklich hingeflossen sind.

Bei meinem 27-Subagents-Desaster aus Schritt 2 hat genau dieser Breakdown gezeigt, dass nicht die eigentliche Recherche teuer war, sondern der wiederholte Kontext-Aufbau auf der tiefsten Ebene. Ohne die Aufschlüsselung hätte ich auf das Modell geschoben und am falschen Ende optimiert. Drück /usage nach jedem Run mit mehr als einer Ebene.

8. Timeout und Abbruch-Strategie

Tiefe Setups haben ein Failure-Pattern das flache nicht haben: ein Subagent auf Ebene drei hängt, und die Ebenen darüber warten. Du siehst oben nur "Working" und weißt nicht warum. Leg deshalb vorher fest wie lange ein Worker maximal laufen darf, und was der Parent tut wenn ein Kind nicht zurückkommt.

Mein Muster: der Coordinator wartet nicht ewig. Wenn ein Worker nach einer vernünftigen Frist nichts liefert, macht der Coordinator ohne dieses Teilergebnis weiter und vermerkt die Lücke im Bericht. Lieber ein Bericht mit vier von fünf Konkurrenten plus klarer Notiz, als eine Session die seit zwanzig Minuten auf einen hängenden Subagent wartet.

9. Debugging wenn ein tiefer Subagent hängt

Wenn etwas klemmt, geh die Ebenen von oben nach unten durch. Die Agents-Ansicht zeigt Dir welcher Subagent aktiv ist. Das Juni-Update hat hier einige Bugs gefixt, zum Beispiel dass ein Subagent nach dem Stoppen eines von ihm gestarteten Kindes als "active" hängen blieb. Wenn Du auf einer alten Version bist, update zuerst, viele dieser Hänger waren schlicht Bugs.

Wenn der Subagent wirklich an seiner Aufgabe scheitert und nicht an einem Bug, liegt es fast immer an zu viel oder zu wenig Kontext aus Schritt 6. Zu wenig, und er weiß nicht was er tun soll. Zu viel, und er verliert sich. Schau Dir den Spawn-Auftrag an den der Parent geschickt hat, dort steht die Ursache.

10. Wann Du stattdessen flach bleibst

Die ehrliche Antwort für die meisten Solo-Founder und kleinen Teams: bleib bei Ebene eins. Ein Coordinator der vier, fünf Worker startet und deren Ergebnisse zusammenführt deckt 90 Prozent ab. Tiefe brauchst Du erst wenn eine einzelne Worker-Aufgabe selbst wieder sauber in unabhängige Teilaufgaben zerfällt, und das ist seltener als man denkt.

Mein Test über die Woche hat das bestätigt. Von allen Setups die ich gefahren hab, hat genau eines von der zweiten Ebene wirklich profitiert, nämlich der Konkurrenz-Fan-out aus Schritt 3. Alle anderen waren mit einer Ebene schneller, billiger und einfacher zu debuggen. Fünf Ebenen tief zu dürfen heißt nicht fünf Ebenen tief zu sollen.

Was als nächstes

Wenn Du jetzt ein größeres Agent-Setup planst, geh weiter zu Level 6 Lesson 7, Multi-Agent-Orchestrierung. Wer wissen will ob eine Aufgabe überhaupt einen Subagent braucht oder ob ein Skill reicht, schaut in "Sub-Agent oder Skill oder MCP-Tool". Und wenn Dir die Kosten Sorgen machen, ist "Claude Code Cost Controls" der nächste logische Schritt.

Source

Das Feature "Sub-agents can now spawn their own sub-agents (up to 5 levels deep)" und der /usage Subagent-Breakdown stammen aus dem offiziellen Claude Code Changelog, Juni 2026: https://code.claude.com/docs/en/changelog