Subagents in Claude Code: wann sie sich lohnen, Job für Job, und wann die Hauptsession günstiger ist

Die Subagents-Seite der Claude-Code-Doku beantwortet „wann sollte ich einen nutzen“ in einem Satz: wenn eine Nebenaufgabe „deine Hauptkonversation mit Suchergebnissen, Logs oder Dateiinhalten fluten würde, auf die du nicht wieder zurückgreifst: Der Subagent erledigt diese Arbeit in seinem eigenen Kontext und gibt nur die Zusammenfassung zurück.“ Über zwei Wochen meiner eigenen Transkripte machten Hintergrund-Subagents etwa 11,5 % der bepreisten Nutzung aus, und 64 % davon waren Cache-Writes. Der Subagent zahlt also tatsächlich dafür, das Chaos zu lesen. Was der Satz der Doku auslässt: was du zurückbekommst und was du damit verlierst.

Delegieren verändert drei Dinge auf einmal. Tokens: Der Output wird woanders gecacht, zu einem anderen Preis, mit einer anderen Lebensdauer. Belege: Der Parent sieht den Bericht des Subagents, während der rohe Output in einem Transkript auf der Platte liegt, das niemand öffnet, solange nichts merkwürdig aussieht. Framing: Ein frischer Subagent bringt die Theorie des Parents über das Problem nicht mit, und manchmal ist genau das der Sinn. Jeder Job unten wägt diese drei anders ab.

Labels, damit du weißt, worauf was beruht. Dokumentiert: Die Claude-Code-Doku beschreibt das Muster. Gemessen: Ich habe auf meinem eigenen Setup etwas daran gemessen, in einem Post, der an der Stelle verlinkt ist. Berichtet: Anthropic hat ein Ergebnis aus seinem eigenen Research-System veröffentlicht, und das ist nicht Claude Code. Die Kostenüberlegungen sind Arithmetik zu Listenpreisen, und ich habe keinen dieser Jobs auf beide Arten laufen lassen.

Wie verändert ein Claude-Code-Subagent die Kosten einer Aufgabe?

Er verschiebt, wo Tool-Output gecacht wird. In der Hauptkonversation bleibt ein Tool-Ergebnis im Kontext und wird bei jedem späteren Request erneut gelesen, bis zur Compaction, bis /clear oder bis Claude Code alte Tool-Ergebnisse entfernt. In einem Subagent wird derselbe Output im eigenen Kontext des Subagents gelesen, und nur sein Ergebnis landet beim Parent.

Die Doku zum Prompt Caching legt die Defaults fest. Mit einem Claude-Abo innerhalb der Plan-Nutzung bekommt die Hauptkonversation den Ein-Stunden-Cache; Subagents bekommen fünf Minuten, „auch mit einem Abo, bis du einen längeren wählst“, und der erste Request eines Subagents „liest den Cache des Parents nicht, weil sich die beiden Präfixe unterscheiden.“ Mit einem API-Key, einem Cloud-Anbieter oder Usage Credits steht auch die Hauptkonversation standardmäßig auf fünf Minuten. Mit promptCacheTtl und subagentPromptCacheTtl änderst du jeden der beiden Töpfe. Zu den Listenpreisen von Opus 5.5 laut der Kostenaufschlüsselung für Claude Code kostet ein Cache-Read das 0,05-Fache des Basis-Inputs, ein Fünf-Minuten-Write das 1,25-Fache und ein Ein-Stunden-Write das 2-Fache.

Nimm einen idealisierten Output-Block, der ohne Misses im Cache bleibt. In der Hauptkonversation mit dem Abo-Default wird er einmal zum 2-Fachen geschrieben, und je zwanzig spätere Requests kostet das erneute Lesen einen weiteren Basis-Input-Preis (20 × 0,05). Ein Subagent schreibt ihn zum 1,25-Fachen, liest ihn ein paar Mal und lässt ihn zurück. Dafür bezahlt der Subagent einen Start: seine Anweisungen, Tool-Definitionen und sein Briefing, kalt geschrieben. Wie groß dieser Start ist, kannst du in jedem Subagent-Transkript ablesen, als Cache-Write-Tokens seines ersten Requests.

Lass die eigenen Reads des Subagents und seine zurückgegebene Zusammenfassung außen vor, dann ist der Break-even die Blockgröße, ab der Delegieren günstiger ist, als Vielfaches dieses Starts:

Mit einem Abo ist ein großer Block im Subagent günstiger, selbst wenn die Session direkt danach endet, weil der Ein-Stunden-Write mehr kostet als der Fünf-Minuten-Write. Stehen beide auf fünf Minuten, gleicht sich der Write aus, und nur die eingesparten Re-Reads bezahlen den Start. Zähl API-Requests, nicht die Nachrichten, die du tippst: Jede Antwort, die Tool-Ergebnisse zurückgibt, startet einen weiteren.

Der Start war in der Praxis der kleine Teil. In meinem Audit der Hintergrund-Subagents (gemessen) machten erste Requests etwa 10 % der Cache-Writes von Subagents aus. Der Rest kam später, aus dem, was die Subagents einlasen, und aus Rebuilds, und die Transkripte können beides nicht auseinanderhalten. Dasselbe Audit, aggregiert über unterschiedliche Arbeit, liefert einen groben Lebenszeitpreis pro gecachtem Token: 29,6 Reads pro Write in der Hauptkonversation, etwa das 3,5-Fache des Basis-Inputs bei Listenverhältnissen, gegenüber 9,4 in Hintergrund-Subagents, etwa das 1,7-Fache. Unterschiedliche Jobs, also eine Skizze, kein Vergleich.

Ein Fork überspringt den Kaltstart. Er erbt Anweisungen, Tools und Verlauf des Parents exakt, also gilt laut Caching-Doku: „sein erster Request liest den Cache des Parents“, und die Subagents-Doku sagt, ein Fork „kostet weniger als ein frischer Subagent bei Aufgaben, die denselben Kontext brauchen.“ Er ist aus demselben Grund günstiger, aus dem er riskanter ist, und das kommt beim Review wieder. Alles davon zehrt an einem einzigen Limit: Ein Subagent „sendet eigene Requests, die auf dieselben Nutzungslimits angerechnet werden wie deine Hauptkonversation.“

Sollte ein Claude-Code-Subagent deine Testsuite ausführen?

Ja, und es ist der sauberste Fall. Das erste Beispiel der Doku unter „Isolate high-volume operations“ ist genau dieser Prompt:

Use a subagent to run the test suite and report only the failing tests with their error messages

Ein vollständiger Testlauf ist genau der Block, auf den du nicht wieder zurückgreifst, und meist ein großer, also liegt er deutlich über dem Break-even. Was du aufgibst, ist das Log. Ich würde einen Schritt weiter gehen als der Prompt der Doku und die Namen der fehlschlagenden Tests und die Fehlermeldungen wörtlich anfordern, damit sich der Bericht gegen das Transkript prüfen lässt, falls etwas nicht aufgeht.

Für die schmale Version des Jobs gibt es ein günstigeres Werkzeug. Wenn du nur das Ende des Outputs willst, zeigt die Kostenseite einen PreToolUse-Hook, der Testbefehle so umschreibt, dass nur die letzten 100 Zeilen bleiben. Das ist ein Shell-Filter, ohne zweiten Kontext, den du bezahlen müsstest. Ein Subagent verdient sich seinen Platz gegenüber dem Hook dann, wenn die Fehler gelesen und gruppiert werden müssen, nicht bloß gekürzt.

Langsame Suites kosten noch etwas. Der Cache eines Subagents steht standardmäßig auf fünf Minuten, also kommt einer, der länger untätig auf einen Befehl wartet, zu einem abgelaufenen Cache zurück. Seit 2.1.318 wandert der Shell-Befehl eines Hintergrund-Subagents nach 3 Minuten in den Hintergrund, um das zu verhindern. In meinem Audit war der Fall selten: Requests, die mehr als fünf Minuten nach dem vorherigen Request desselben Subagents kamen, trugen 0,73 % der Cache-Writes von Hintergrund-Subagents. Das ist ein Proxy, und meine Subagents ließen selten lange Builds laufen.

Lohnt sich ein Claude-Code-Subagent für die Codesuche?

Für „wo steckt dieses Verhalten“ in einem Repository, das du nicht im Kopf hast, ja, auch wenn die Antwort klein ist. Der eingebaute Explore-Agent ist read-only, und laut Doku gilt: „Explore und Plan starten ohne deine CLAUDE.md-Dateien und den Snapshot des git status, damit die Recherche schnell und günstig bleibt.“

Hier geht es mehr um Framing als um Tokens. Im August habe ich geschrieben, dass ich ständig zum Sucher mit sauberem Kontext greife: Ein frischer Sucher liest den Code, ein Sucher mit deiner Theorie über den Bug findet Belege für deine Theorie. Die Grenze ist also nicht die Größe des Outputs. Wenn du die Datei kennst, such selbst mit grep darin; ein Subagent würde seinen ganzen Start bezahlen, um dieselben paar Zeilen zurückzugeben. Wenn du nur glaubst, sie zu kennen, spricht genau das für einen sauberen Sucher.

Die Rechnung hat eigene Haken. Explore läuft auf dem Modell der Parent-Konversation, nicht auf Haiku: Seit v2.1.198 erbt es das Modell der Session, gedeckelt bei Opus, also ist unter einer Opus-Session jede Suche ein Opus-Call, wie der Post zu Haiku 5.5 als Subagent nachverfolgt hat (unter einer Fable-Session hängt es laut Doku davon ab, wie du dich verbindest). CLAUDE_CODE_SUBAGENT_MODEL allein bewegt Explore oder Plan nicht; laut jenem Post brauchst du zusätzlich CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 oder einen eigenen Agenten namens Explore mit model: haiku. Und Explore ist One-Shot: Es gibt keine Agent-ID zurück und lässt sich nicht fortsetzen, also gehört eine Suche, die du später erweitern willst, in general-purpose oder einen eigenen Agenten.

Sollte ein Claude-Code-Subagent deinen Diff reviewen?

Ja, und hier sagt die Arithmetik: bleib in der Hauptsession, und du solltest trotzdem delegieren. Die Hauptkonversation hat den Diff schon, also bezahlt ein Reviewer dafür, zu lesen, was der Parent bereits im Cache hat. Was du dafür kaufst, ist ein Leser, der das Framing des Autors nicht teilt. Ein Reviewer, der die Session erbt, die den Code geschrieben hat, erbt auch ihre verworfenen Vermutungen, geschrieben im selben flachen Ton wie ihre Schlussfolgerungen.

Das Beispiel code-reviewer aus der Doku ist ein read-only Subagent mit tools: Read, Grep, Glob, Bash, der bei git diff anfängt. Dieser Ausgangspunkt zählt, weil der Parent das Briefing schreibt: Gib dem Reviewer den Diff und eine Checkliste, nicht die Darstellung des Autors, was die Änderung tut.

Damit ist der Fork auch der falsche Subagent für diesen Job, und seit 2.1.302 sind Forks auch in claude -p und im Agent SDK standardmäßig an. In dem einen Lauf mit neutralem Prompt, den ich auf 2.1.302 gemacht habe (gemessen: Haiku, mit meinen eigenen Plugins und Agenten geladen), hat das Modell general-purpose angefordert, keinen Fork. Ein Lauf auf einem Modell sagt nichts über deins. Für einen Review-Schritt nimm "Agent(fork)" in permissions.deny auf oder setz CLAUDE_CODE_FORK_SUBAGENT=0, beides dokumentiert.

Das Problem mit der Zusammenfassung ist hier am schärfsten, denn „keine Probleme gefunden“ ist eine Zusammenfassung. Verlang Befunde mit Datei und Zeile, damit sich jeder in Sekunden prüfen lässt. Behandle ein leeres Review als unverifiziert, bis das Transkript des Subagents unter ~/.claude/projects/ zeigt, dass er den Diff tatsächlich geöffnet hat.

Zahlen sich Claude-Code-Subagents für parallele Recherche aus?

Manchmal, und es ist der eine Job, bei dem ein Subagent keine Ersparnis ist. Fan-out kauft Ergebnisse, indem es mehr Tokens ausgibt, als ein einzelner Kontext könnte. Das Muster „Run parallel research“ der Doku startet mehrere Subagents auf getrennten Modulen und sagt, es „funktioniert am besten, wenn die Recherchepfade nicht voneinander abhängen“, mit der Warnung, dass viele Subagents, die jeweils detaillierte Ergebnisse zurückgeben, „erheblichen Kontext verbrauchen können, und jeder Subagent verbraucht eigene Tokens, während er läuft.“

Die stärksten Zahlen sind berichtet, aus Anthropics Post über sein Research-System vom Juni 2025, über das Research-Feature auf Claude Opus 4 und Sonnet 4. Sie stammen aus getrennten Vergleichen. Gegenüber einem einzelnen Opus-4-Agenten schnitt das Multi-Agent-Setup in einer internen Research-Eval um 90,2 % besser ab. Bei BrowseComp erklärte der Tokenverbrauch allein 80 % der Varianz in der Leistung. Und gegenüber Chat: „Agenten verbrauchen typischerweise etwa 4× mehr Tokens als Chat-Interaktionen, und Multi-Agent-Systeme verbrauchen etwa 15× mehr Tokens als Chats.“ Der Post zieht auch die Linie, die fürs Coding zählt: „Die meisten Coding-Aufgaben enthalten weniger wirklich parallelisierbare Teilaufgaben als Recherche.“

Einige seiner Lehren gelten auch ohne die Zahlen. Jeder Subagent braucht ein Ziel, ein Ausgabeformat, Hinweise zu Tools und Quellen und klare Grenzen; bei vagen Briefings, schreibt Anthropic, haben Agenten Arbeit doppelt gemacht, Lücken gelassen oder nicht gefunden, was sie brauchten. Und um das „Stille-Post-Spiel“ zu entschärfen, legten ihre Subagents Arbeit in externen Systemen ab und gaben „leichtgewichtige Referenzen zurück“. In Claude-Code-Begriffen: Lass jeden Researcher seine Befunde in eine Datei schreiben, mit Quell-URLs oder Datei-und-Zeile-Zitaten neben jeder Behauptung, und den Pfad zurückgeben. Ein Pfad zu einer Paraphrase ist immer noch eine Paraphrase; erst die Zitate machen es dem Parent möglich, zu prüfen.

Sollten parallele Edits an Claude-Code-Subagents gehen?

Selten. Ein Edit liefert einen kleinen Diff, also gibt es keinen Output, der sich zu isolieren lohnt, und der einzige Gewinn ist Zeit auf der Uhr, und dafür gibt es separate Sessions. Die Doku zieht dieselbe Grenze: „Für Arbeit, die parallel weiterlaufen muss oder nicht in ein Kontextfenster passt, nutze separate Sessions.“

Die Mechanik zeigt in dieselbe Richtung. Ein Subagent startet im Arbeitsverzeichnis der Hauptkonversation, also bearbeiten parallele Subagents denselben Checkout. isolation: worktree gibt einem davon eine eigene Kopie, „standardmäßig von deinem Default-Branch abgezweigt statt vom HEAD der Parent-Session.“ Wenn du worktree.baseRef auf "head" setzt, kommen deine Commits mit, aber in meinen Tests blieben uncommittete Änderungen trotzdem zurück, und das ist mitten in einem Feature der Normalzustand. Committe oder übergib die Änderung explizit.

In meinen Worktree-Tests auf 2.1.316 (gemessen, Sessions mit claude -p --worktree; Subagents habe ich nicht laufen lassen) kollidierten zwei Worktrees auf einem Port, Docker Compose plante für jeden ein eigenes Postgres-Volume, und die Default-Basis übersprang den ungepushten Commit. Laut Doku nutzt ein Subagent-Worktree dieselbe worktree.baseRef, also erwarte ich dasselbe von isolation: worktree. Dieser Teil ist ungetestet.

Wann ist die Claude-Code-Hauptsession günstiger als ein Subagent?

Wenn die Arbeit Kontext über mehrere Schritte teilt oder der Output klein genug ist, um unter dem Break-even zu bleiben. Die Doku nennt vier Fälle, in denen du in der Hauptkonversation bleibst: häufiges Hin und Her oder iterative Verfeinerung; mehrere Phasen, die viel Kontext teilen, etwa Planung, Implementierung und Tests; eine schnelle, gezielte Änderung; und Latenz, weil ein Subagent, der kein Fork ist, „frisch startet und Zeit brauchen kann, um Kontext zu sammeln.“

Jeder davon passt zur Kostenstruktur. Iteration heißt wiederholte Starts oder Resumes, die nur günstig bleiben, solange der Fünf-Minuten-Cache des Subagents warm ist. Geteilte Phasen heißen, dass der Subagent Kontext übergeben bekommen muss, den der Parent schon hat, und ein so reichhaltiges Briefing ist der größte Teil dessen, was du sparen wolltest; wenn die Arbeit wirklich ein fortlaufender Gedankengang ist, ist das ein Job für den Fork, nicht für einen frischen Subagent. Eine gezielte Änderung erzeugt zu wenig Output, um ihn zu isolieren. Für eine Frage zu etwas, das schon in der Konversation steht, verweist die Doku auf /btw: Es „hat keinen Tool-Zugriff, und die Antwort wird nicht in den Verlauf aufgenommen.“

Subagents zu verketten, Review im einen und Fix im nächsten, ist ebenfalls dokumentiert, aber jeder Schritt läuft als Zusammenfassung durch den Parent. Wenn der Fixer die Belege des Reviewers braucht und nicht seine Schlussfolgerungen, schreib die Befunde zwischen den Schritten in eine Datei.

Auf welchem Modell sollte ein Claude-Code-Subagent laufen?

Auf dem des Parents, außer du routest ihn bewusst um. Laut Doku „läuft ein Subagent, den du definierst, auf demselben Modell wie die Konversation, die ihn startet“, und Claude Code nimmt zuerst den Parameter pro Aufruf, dann das Feld model der Definition, dann CLAUDE_CODE_SUBAGENT_MODEL, dann den Parent; CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 übersteuert die ersten beiden. Die Kostenseite empfiehlt model: haiku für „einfache Subagent-Aufgaben“.

Prüf, worauf der Alias auflöst, bevor du Ersparnisse zählst. haiku heißt Haiku 5.5 auf der Anthropic API, während Bedrock, Google Cloud, Microsoft Foundry und Claude Platform on AWS ihn noch auf Haiku 4.5 abbilden. Und Haiku 5.5 ist pro Token günstiger, nicht automatisch pro Aufgabe. Eine Zusammenfassung, die in einen Call passt, ist genau das, wofür seine Preisliste gemacht ist. In einer langen Suchschleife schlägt der Long-Prompt-Tarif ab 100K zu, also fixier zuerst den Effort und setz /autocompact 100k, wie der Post zu Haiku 5.5 als Subagent durchgeht. Für Reviews ist der nächstliegende Beleg dort Bug Hunt Bench: 21,5 von 105 eingeschleusten Bugs für Haiku 5.5 bei max effort, gegenüber 36 für Opus 5.5 bei xhigh.

Wie prüfst du, ob sich Claude-Code-Subagents in deinen Sessions lohnen?

Schau zuerst auf den Anteil, dann darauf, was ihn füllt. In einem Pro-, Max-, Ultra-, Team- oder Enterprise-Plan ordnet /usage die jüngste Nutzung prozentual den Subagents zu, über 24 Stunden oder 7 Tage, berechnet aus dem lokalen Verlauf. Die Zeile Prompt cache (main) deckt nur die Hauptkonversation ab, für das Cache-Verhalten der Subagents selbst brauchst du also die Transkripte unter ~/.claude/projects/.

Als ich dieses Audit gemacht habe (gemessen, ein Max-Plan, 22. Oktober bis 4. November), machten Hintergrund-Subagents etwa 11,5 % der bepreisten Nutzung aus, und 64 % ihrer Kosten waren Fünf-Minuten-Cache-Writes. Die meisten dieser Writes kamen nach dem ersten Request, und das Audit konnte neuen Inhalt nicht von Cache-Rebuilds trennen. Das Skript steht in jenem Post. Es kann nicht sagen, ob dieselben Jobs in der Hauptkonversation mehr gekostet hätten, weil ich sie nicht auf beide Arten ausgeführt habe.

Der Test der Doku, Output, auf den du nicht wieder zurückgreifst, ist also nur die halbe Entscheidung. Die andere Hälfte: Gibt es genug davon, um den Start zu decken, was mit einem Abo nicht viel ist; kommt das Ergebnis in einer Form zurück, die du gegen das Transkript prüfen kannst; und braucht der Job einen Leser ohne dein Framing? Testläufe bestehen alle drei. Ein grep in einer bekannten Datei scheitert am ersten. Review fällt beim Kostentest durch und sollte trotzdem delegiert werden.