Teams und Workflows

Ein Subagent erledigt eine Nebenaufgabe in einem eigenen Kontext und gibt eine Zusammenfassung zurück, das erklärt Kapitel 20. Wie mehrere Sitzungen nebeneinander laufen, jede in ihrem eigenen Worktree, zeigt Kapitel 21. Dieses Kapitel geht einen Schritt weiter: Hier führt Claude Code selbst eine ganze Gruppe von Agenten, verteilt die Arbeit und setzt die Ergebnisse zusammen. Dafür gibt es drei Formen, die Agent Teams, die Workflows und die Projects.

Die Übersicht des Herstellers (externe Seite, code.claude.com) ordnet alle Wege zum parallelen Arbeiten nach zwei Fragen. Wie viel steuert man selbst noch, und läuft die Arbeit auf dem eigenen Rechner oder in der Cloud? Bei allen drei Formen dieses Kapitels koordiniert Claude. Sie unterscheiden sich darin, wo der Plan liegt und wer den Überblick behält.

Drei Formen und wer den Überblick behält

Die Doku zu den Workflows (externe Seite, code.claude.com) fasst den Unterschied in einen Satz: Es kommt darauf an, wer den Plan hält.

• Im Agent Team hält ihn eine Sitzung, der Lead. Sie verteilt Aufgaben an weitere Sitzungen, die Teammates, und entscheidet Zug um Zug, was als Nächstes geschieht.
• Im Workflow steht der Plan in einem Skript. Claude schreibt es, eine Laufzeitumgebung führt es im Hintergrund aus und startet dabei viele Subagents, je nach Aufgabe bis zu Hunderte.
• Im Project plant ein Projektgespräch in der Cloud. Es startet für jede Aufgabe einen Thread, also eine eigene Sitzung, und bekommt von jedem Thread eine Rückmeldung.

Die Unterscheidung kennt der Grundkurs. In Agenten und Harness, Kapitel 01 trennt Anthropic Abläufe, deren Reihenfolge im Code steht, von Agenten, die ihren nächsten Schritt selbst wählen. Ein Workflow in Claude Code ist in diesem Sinn ein Ablauf, dessen Code Claude selbst schreibt, mit Agenten in den einzelnen Schritten. Lead und Projektgespräch entscheiden als Agenten über die Arbeit anderer Agenten.

Agent Teams mit Lead und Teammates

Ein Agent Team besteht aus einer Sitzung, die als Lead die Arbeit koordiniert, Aufgaben verteilt und die Ergebnisse zusammenführt (Doku zu Agent Teams (externe Seite, code.claude.com)). Die Teammates arbeiten unabhängig, jedes in seinem eigenen Kontextfenster, und schreiben einander direkt. Ein Subagent berichtet dagegen an die Sitzung, die ihn gestartet hat. Man kann auch selbst jedem Teammate schreiben, ohne den Umweg über den Lead.

Agent Teams kamen mit Version 2.1.32 vom 05.02.2026 als Research Preview (Versionsliste (externe Seite, code.claude.com)). Am 12.10.2026 sind sie weiter experimentell und in der Voreinstellung abgeschaltet. Eingeschaltet werden sie mit der Umgebungsvariable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Danach genügt eine Bitte in Alltagssprache, etwa nach drei Teammates, von denen eines die Bedienung prüft, eines die Architektur und eines Gegenargumente sucht.

Für den Anfang empfiehlt die Doku drei bis fünf Teammates. Dazu kommt eine Bedingung: Ändern zwei Teammates dieselbe Datei, überschreibt das eine die Arbeit des anderen. Die Arbeit wird deshalb so geteilt, dass jedes Teammate eigene Dateien bekommt. Eigene Worktrees wie bei parallelen Sitzungen bekommen Teammates keine.

Workflows mit einem Skript als Plan

Ein Workflow verlegt den Plan in Code. Seit Version 2.1.154 vom 28.05.2026 schreibt Claude auf Wunsch ein Skript in JavaScript, das viele Subagents startet, ihre Ergebnisse sammelt und weiterreicht (Versionsliste (externe Seite, code.claude.com)). Schleife, Verzweigungen und Zwi­schen­er­geb­nisse hält das Skript selbst, im Kontext von Claude landet nur die fertige Antwort. Der Lauf geht im Hintergrund, die Sitzung bleibt währenddessen frei.

Gedacht ist das für Aufgaben, die mehr Agenten brauchen, als ein Gespräch koordinieren kann. Der zweite Anlass ist ein Ablauf, den man als Skript lesen und wiederholen will. Als Beispiele nennt die Doku eine Fehlersuche über die ganze Codebasis, die Migration von 500 Dateien und eine Recherche, deren Quellen gegeneinander geprüft werden. Weil der Plan im Code steht, kann ein Workflow unabhängige Agenten die Befunde der anderen prüfen lassen, bevor etwas gemeldet wird.

Den Überblick gibt /workflows. Der Befehl listet laufende und fertige Läufe, zeigt jede Phase mit der Zahl ihrer Agenten und lässt bis zu einem einzelnen Agenten hinunterschauen. Ein Workflow ist schon eingebaut: /deep-research recherchiert eine Frage über viele Quellen und liefert einen Bericht mit Belegen. Einen eigenen Lauf speichert man in der Ansicht mit s als Befehl.

Anstoßen lässt sich ein Workflow auf drei Wegen:

• mit einer Bitte in eigenen Worten,
• mit dem Wort ultracode im Prompt,
• mit der Einstellung Ultracode.

Mit der Einstellung plant Claude für jede größere Aufgabe von selbst einen Workflow.

Wann sich diese Einstellung lohnt, steht auf der zweiten Ebene.

Projects mit einem Koordinator in der Cloud

Projects sind die jüngste der drei Formen. Anthropic hat sie am 17.09.2026 angekündigt (externe Seite, claude.com), am 12.10.2026 sind sie eine öffentliche Beta für die Abos Pro und Max, die schrittweise freigeschaltet wird. Ein Project ist ein langes Gespräch, in dem Claude als Koordinator arbeitet (Doku zu Projects (externe Seite, code.claude.com)). Für jede Aufgabe startet es einen Thread. Jeder Thread ist eine eigene Sitzung mit eigenem Kontextfenster, die ein Stück Arbeit erledigt und danach an das Gespräch berichtet.

Ein Thread läuft in der Regel als Cloud-Sitzung. Er arbeitet auf einem eigenen Branch und öffnet einen Pull Request, wenn die Arbeit danach verlangt. Braucht eine Aufgabe etwas, das nur der eigene Rechner hat, läuft ihr Thread auf Wunsch dort, verbunden über Remote Control. Arbeiten zwei Threads am selben Code, entsteht daraus ein Merge-Konflikt wie bei jedem anderen Pull Request. Der Koordinator sieht nur, was die Threads zurückmelden. Projects gibt es im Browser unter claude.ai/code, in der Desktop-App und in der Claude-App auf dem Telefon. In der Kommandozeile gibt es sie nicht.

Ein Project lohnt sich nach der Doku, wenn die Arbeit ein Ziel hat, das länger dauert als eine Sitzung und immer neue Aufgaben hervorbringt. Die Threads in der Cloud arbeiten weiter, während der eigene Rechner zugeklappt ist, und lassen sich vom Telefon aus verfolgen.

Wann sich mehr Agenten lohnen

Alle drei Formen verbrauchen mehr als eine einzelne Sitzung, weil jeder Agent sein eigenes Kontextfenster füllt. Ein Agent Team kostet Abstimmung und deutlich mehr Token als eine einzelne Sitzung. Ein Workflow-Lauf kann spürbar mehr Token verbrauchen als dieselbe Aufgabe im Gespräch. Ein Project zehrt vom selben Kontingent wie die übrigen Sitzungen und verbraucht es schneller.

Für Recherche, Review und neue Funktionen hält die Doku zu Agent Teams die zusätzlichen Token meist für gerechtfertigt. Für Routinearbeit rät sie zu einer einzelnen Sitzung. Am besten wirkt ein Team, wenn die Teammates unabhängig voneinander arbeiten können.

Vor dem Start helfen drei Fragen:

• Zerfällt die Arbeit in Teile, die nicht aufeinander warten? Wenn ja, lohnt sich ein Team oder ein Workflow. Hängt jeder Schritt am vorigen, genügt eine Sitzung oder ein Subagent.
• Wie lange lebt das Ziel? Eine Aufgabe für heute passt zu Team oder Workflow. Ein Ziel über Tage mit immer neuen Aufgaben passt zu einem Project.
• Soll der Ablauf wiederholbar sein? Dann ein Workflow, weil sich sein Skript speichern und erneut starten lässt.

Wer unsicher ist, was ein großer Lauf kostet, probiert ihn zuerst an einem kleinen Ausschnitt aus, etwa an einem Verzeichnis statt am ganzen Repository.

Die erste Ebene hat die drei Formen vorgestellt. Hier geht es um die Bedienung. Wie entsteht ein Team, und wie stimmt es sich ab? Was sieht und darf ein Teammate? Wann lohnt sich Ultracode, wie groß wird ein Workflow, und was übernimmt ein Project von seinen Repositorys?

Wie ein Team entsteht

Ist die Umgebungsvariable gesetzt, startet Claude ein Teammate, sobald es einem Subagent beim Start einen Namen gibt. Ausgenommen sind ein Fork und ein Aufruf mit eigener Isolation. Eine Rückfrage kommt dabei nicht. So ist es seit Version 2.1.178 vom 15.06.2026: Seither hat jede Sitzung mit der Variable genau ein Team, ohne eigenen Schritt zum Anlegen. Die Werkzeuge TeamCreate und TeamDelete sind damals entfallen (Versionsliste (externe Seite, code.claude.com)).

Daraus folgt eine Nebenwirkung. Claude benennt auch gewöhnliche Subagents von sich aus, um ihnen später schreiben zu können. Solange Agent Teams eingeschaltet sind, wird aus einem solchen Subagent ein Teammate. So kann ein Team entstehen, ohne dass man darum gebeten hat (Doku zu Agent Teams (externe Seite, code.claude.com)). Wer das abstellen will, setzt die Variable in der Einstellungsdatei auf 0. Claude Code übernimmt den Wert beim Speichern und liest ihn bei jedem Start eines Subagent neu, ein Neustart der Sitzung ist dafür nicht nötig. Ohne interaktive Sitzung gibt es keine Teammates: Mit claude -p und im Agent SDK läuft ein benannter Subagent als gewöhnlicher Subagent.

Die Teammates erscheinen in einer Leiste unter der Eingabe. Mit den Pfeiltasten wählt man eines aus, die Eingabetaste öffnet sein Protokoll, und was man dann tippt, geht an dieses Teammate. Wer jedes Teammate in einem eigenen Bereich des Terminals sehen will, braucht tmux oder iTerm2. Eingestellt wird das mit teammateMode.

Das Modell eines Teammates kommt aus der ersten Quelle, die zutrifft. Die Reihenfolge lautet: der Auftrag beim Start, die Beschreibung eines eigenen Subagent, die Variable CLAUDE_CODE_SUBAGENT_MODEL, zuletzt das Modell des Leads. Die Kostenseite (externe Seite, code.claude.com) rät, Teammates auf Sonnet laufen zu lassen. Modell und Fast Mode eines Teammates stehen fest, sobald es gestartet ist.

Aufgaben mit Abhängigkeiten

Version 2.1.16 vom 22.01.2026 brachte ein neues System für Aufgaben, das Abhängigkeiten kennt (Versionsliste (externe Seite, code.claude.com)). Im Team wird daraus eine gemeinsame Aufgabenliste. Der Lead legt die Aufgaben an, die Teammates arbeiten sie ab. Jede Aufgabe ist offen, in Arbeit oder erledigt. Eine offene Aufgabe, deren Vorgänger noch fehlen, kann niemand übernehmen, bis diese erledigt sind.

Verteilt wird auf zwei Arten. Der Lead weist eine Aufgabe einem bestimmten Teammate zu, oder ein Teammate nimmt sich nach getaner Arbeit die nächste freie Aufgabe selbst. Greifen zwei gleichzeitig nach derselben, verhindert eine Dateisperre den Doppelgriff. Ist eine Aufgabe erledigt, gibt Claude Code die von ihr abhängigen von selbst frei. Ctrl+T blendet die Liste ein und aus.

Die Liste setzt die Werkzeuge für Aufgaben voraus, und die gibt es seit Version 2.1.268 in der Voreinstellung nur noch auf älteren Modellen. Welche das sind und wie man sie zurückholt, steht in Kapitel 04. Fehlen die Werkzeuge, stimmt sich das Team über Nachrichten ab.

Feste Regeln für das Team setzen Hooks. TeammateIdle läuft, bevor ein Teammate untätig wird, TaskCreated beim Anlegen einer Aufgabe und TaskCompleted beim Abhaken. Endet ein solcher Hook mit dem Code 2, geht seine Rückmeldung an das Teammate. Je nach Hook wird die Aufgabe dann nicht angelegt, bleibt offen, oder das Teammate arbeitet weiter.

Was ein Teammate mitbringt

Ein Teammate lädt beim Start denselben Projektkontext wie eine gewöhnliche Sitzung: CLAUDE.md, MCP-Server und Skills. Dazu bekommt es den Auftrag des Leads. Der bisherige Verlauf des Leads kommt nicht mit. Was das Teammate über die Aufgabe wissen muss, gehört deshalb in den Auftrag, mit Pfaden, Rahmenbedingungen und dem gewünschten Ergebnis.

Teammates starten im Berech­ti­gungs­modus des Leads, nur dontAsk erben sie nicht. Ihre Rückfragen zu Berechtigungen erscheinen in der Sitzung des Leads und werden dort beantwortet. Bei einem großen Team sind das viele Rückfragen. Die Doku rät, häufige Befehle vor dem Start in den Berech­ti­gungs­re­geln freizugeben. Eine Ausnahme gibt es: Den Plan eines Teammates im Plan-Modus genehmigt Claude Code sofort, ohne Prüfung durch den Lead und ohne Rückfrage an den Menschen, sofern sich der Berech­ti­gungs­modus des Teammates seit dem Start nicht geändert hat. Wer einen Plan in anderen Fällen freigibt, zeigt Kapitel 23 auf der dritten Ebene.

Schreibt ein Agent einem anderen, kennzeichnet Claude Code die Nachricht als Nachricht einer anderen Claude-Sitzung. Ein Teammate kann deshalb an Stelle des Menschen keine Freigabe erteilen. Auch ein abgelehnter Schritt lässt sich über ein anderes Teammate nicht umgehen.

Ultracode und wann es sich lohnt

Ultracode steht als Schalter im Regler von /effort, vorgestellt in Kapitel 06. Hier steht, was er tut und wann er sich lohnt.

Es gibt zwei Wege. Das Wort ultracode im Prompt macht genau diese eine Aufgabe zum Workflow, der Effort der Sitzung bleibt, wie er ist. Das Wort ändert nur die Art, wie Claude die Arbeit aufteilt. Jeder Werkzeugaufruf der Agenten durchläuft dieselben Berech­ti­gungs­prü­fungen wie sonst auch. Vor Version 2.1.160 vom 02.06.2026 hieß das Auslösewort workflow. Seither löst dieses Wort nichts mehr aus (Versionsliste (externe Seite, code.claude.com)). Eine Bitte in eigenen Worten wirkt weiter. Wer das Wort aus Versehen getippt hat, nimmt die Markierung mit Option+W auf dem Mac oder Alt+W unter Windows und Linux zurück.

Der zweite Weg ist die Einstellung: /effort ultracode schaltet für die Sitzung ein, dass Claude für jede größere Aufgabe von selbst einen Workflow plant (Doku zu den Workflows (externe Seite, code.claude.com)). Das gilt auf jeder Stufe des Effort. Nicht verfügbar ist Ultracode, wenn Workflows abgeschaltet sind oder das Modell die Stufe xhigh nicht kennt (Doku zur Modellwahl (externe Seite, code.claude.com)).

Ob sich die Einstellung lohnt, entscheidet die Arbeit, die in der Sitzung ansteht. Aus einer einzigen Anfrage können mehrere Workflows hintereinander werden: einer, der den Code versteht, einer, der ändert, und einer, der prüft. Das gilt für jede Aufgabe der Sitzung. Jede Anfrage verbraucht also mehr Token und dauert länger als ohne Workflow. Im Abo ist dadurch die Grenze für die Sitzung oder die Woche früher erreicht.

Dazu kommt, dass Ultracode drei Sicherungen abschaltet. Wer es einschaltet, hat großen Läufen damit schon zugestimmt.

• Die Warnung vor einem großen Workflow erscheint nicht.
• Die Grenze für gleichzeitige Subagents, in der Voreinstellung 20, gilt nicht für die Subagents, die Claude über das Agent-Werkzeug startet.
• Im Auto-Modus fragt Claude Code vor dem ersten Workflow nicht nach.

Daraus ergibt sich die Faustregel. Ultracode lohnt sich für eine Sitzung, die aus großen Aufgaben besteht, etwa eine Prüfung der ganzen Codebasis oder eine Migration über viele Dateien. Dort braucht jede Aufgabe ohnehin Erkunden, Ändern und Prüfen. Für eine einzelne große Aufgabe genügt das Wort im Prompt. Kehrt die Sitzung zur Routinearbeit zurück, schaltet man Ultracode mit /effort ultracode off wieder ab.

Die Größe eines Workflows

Wie viele Agenten Claude in einen Workflow plant, lenkt seit Version 2.1.202 vom 06.07.2026 eine Größenvorgabe (Versionsliste (externe Seite, code.claude.com)). Sie steht in /config unter Dynamic workflow size:

Voreingestellt ist medium, im Abo Pro small. Die Vorgabe geht als Rat an Claude, und ein Prompt, der ein anderes Maß verlangt, setzt sich darüber hinweg. Im Prompt lässt sich die Größe deshalb ebenso steuern.

Wird ein Lauf ungewöhnlich groß, warnt Claude Code: bei mehr als 25 Agenten oder mehr als 1,5 Millionen vorhergesagten Token. Die Warnung erscheint in der Zeile des Laufs unter der Eingabe und hält ihn nicht an. Wer eine Größenvorgabe gewählt hat, bekommt die Warnung bei deren Zahl statt bei 25. In /workflows steht der Verbrauch jedes Agenten, und mit x lässt sich der Lauf dort jederzeit anhalten.

Das Modell eines Workflow-Agenten bestimmt Claude Code in derselben Reihenfolge wie bei einem Subagent. Ein Modell, das das Skript für einen Schritt nennt, zählt dabei wie eine Angabe beim Aufruf. Weist nichts anderes ein Modell zu, läuft der Agent auf dem Modell der Sitzung. Wer sonst für Routinearbeit auf ein kleineres Modell wechselt, prüft deshalb vor einem großen Lauf /model. Seit Version 2.1.296 legt CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL ein Modell für alle Agenten eines Workflows fest (Versionsliste (externe Seite, code.claude.com)).

Einen gelungenen Lauf speichert man in /workflows mit s. Im Ordner .claude/workflows/ des Projekts steht er allen zur Verfügung, die das Repository klonen, unter ~/.claude/workflows/ nur einem selbst. Abschalten lassen sich Workflows in /config, mit "disableWorkflows": true in den Einstellungen oder mit CLAUDE_CODE_DISABLE_WORKFLOWS=1. Eine Organisation setzt dieselbe Einstellung in ihren verwalteten Einstellungen. Wie eine Organisation Einstellungen verteilt, erklärt Kapitel 15.

Was ein Project erbt und verbraucht

Jeder Thread in der Cloud klont die Repositorys des Projects (Doku zu Projects (externe Seite, code.claude.com)). Aus jedem lädt er nur die Anweisungen, also CLAUDE.md, .claude/CLAUDE.md und .claude/rules/ an der Wurzel. Skills, MCP-Server aus .mcp.json und .claude/settings.json bleiben draußen, auch bei einem einzigen Repository. Rechteregeln und Hooks aus einem Repository gelten deshalb in keinem Thread in der Cloud. Feste Regeln gehören in die Anweisungen des Projects.

Netzzugang, Umge­bungs­va­ria­blen, Geheimnisse für Netzanfragen und installierte Werkzeuge legt die Cloud-Umgebung des Projects fest. Von der Einrichtung auf dem eigenen Rechner übernehmen die Threads in der Cloud nichts. Einen Skill bekommen sie über das eigene Konto bei claude.ai: Dort aktivierte Skills laden sie, bis auf manche Threads in einer selbst betriebenen Umgebung. MCP-Werkzeuge kommen über die Connectors desselben Kontos.

Bezahlt wird aus demselben Kontingent wie bei allen anderen Sitzungen. Threads und Projektgespräch zehren gemeinsam davon, und ein Project verbraucht es schneller als eine einzelne Sitzung. Das hat drei Gründe:

• Jeder laufende Thread ist eine vollständige Sitzung, und mehrere laufen gleichzeitig.
• Das Projektgespräch verbraucht selbst Token, wenn es die Rückmeldungen liest und über den nächsten Schritt entscheidet.
• Ein Thread, der einen Pull Request beobachtet, wacht bei einem fehlgeschlagenen CI-Lauf oder einem Kommentar auf und arbeitet weiter.

Wie viele Threads gleichzeitig laufen, entscheidet Claude nach der Arbeit. Eine Zahl, die man selbst nennt, gilt als Wunsch. Fest begrenzt sind 200 neue Threads am Tag über alle Projects. Über das Kontingent hinaus geht ein Project nur, wenn man selbst zusätzliches Guthaben eingeschaltet hat. Erreicht ein Thread die Grenze, wartet er und arbeitet nach dem Zurücksetzen von selbst weiter. Ein Thread, den eine Routine gestartet hat, wartet nicht. Was ein Project verbraucht hat, zeigen die Einstellungen des Projects unter Usage, nach Thread und nach Modell.

Die drei Formen dieses Kapitels sind jung. Die älteste, das Agent Team, gibt es seit Februar 2026, und sie gilt weiter als Experiment. Projects sind eine Beta. Diese Ebene ordnet die Schritte seit Januar 2026. Sie nennt die Grenzen, an die ein großer Lauf stößt, und zeigt, was beim Abbruch erhalten bleibt.

Die Entwicklung in Versionen

Die Tabelle folgt der Versionsliste (externe Seite, code.claude.com), die Projects der Ankündigung (externe Seite, claude.com). Die Daten sind die Erscheinungstage, Stand 12.10.2026.

Zwei Linien fallen auf. Die erste betrifft den Start eines Teams: Bis Juni legte Claude ein Team mit eigenem Werkzeug an, seit 2.1.178 entsteht es von selbst, sobald ein Subagent einen Namen bekommt. Die zweite betrifft die Grenzen. Die Grenze von 200 Starts je Sitzung hielt drei Wochen, vom 17.07. bis zum 07.08.2026. Seither können lange Sitzungen wieder unbegrenzt neue Agenten starten. Die Grenzen für gleichzeitige Agenten und für die Tiefe bleiben.

Obergrenzen für viele Agenten

Jede Form hat eigene Grenzen, auch der gewöhnliche Subagent, und sie gelten getrennt voneinander. Die Doku zu Subagents (externe Seite, code.claude.com) sagt das für ihre Grenze ausdrücklich: Agenten aus Workflows und Teammates folgen ihren eigenen.

Subagents über das Agent-Werkzeug. Laufen in einer Sitzung 20 Subagents, scheitert der Start eines weiteren. Die Fehlermeldung sagt Claude, es solle es nicht erneut versuchen. Ändern lässt sich die Zahl mit CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS. Eine Grenze für die Gesamtzahl über die Sitzung gibt es seit 2.1.224 nicht mehr. Mit eingeschaltetem Ultracode fällt auch die Grenze für gleichzeitige Subagents weg.

Workflows. Die Doku zu den Workflows (externe Seite, code.claude.com) nennt drei Grenzen der Laufzeitumgebung:

• bis zu 16 Agenten gleichzeitig, weniger auf einem Rechner mit weniger Prozessorkernen. Die Variable CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS ändert die Zahl auf einen Wert von 1 bis 256.
• höchstens 4.096 Einträge in einem einzelnen Aufruf von parallel() oder pipeline(). Eine längere Liste weist die Umgebung mit einem Fehler ab.
• 1.000 Agenten je Lauf, gegen Schleifen, die sich nicht beenden.

Agent Teams. Eine feste Obergrenze für Teammates gibt es nicht. Die Doku zu Agent Teams (externe Seite, code.claude.com) begründet die Empfehlung von drei bis fünf mit den Kosten: Jedes Teammate hat sein eigenes Kontextfenster und verbraucht seine Token unabhängig von den anderen. Dazu wachsen Abstimmung und Konflikte, und ab einem Punkt beschleunigt ein weiteres Teammate die Arbeit nicht mehr im selben Maß. Drei Teammates mit klarem Auftrag sind nach der Doku oft besser als fünf verstreute.

Projects. Auch hier steht die Zahl 200, sie zählt aber etwas anderes: neue Threads am Tag über alle Projects eines Kontos. Wie viele davon gleichzeitig laufen, bestimmt Claude.

Wenn ein Lauf abbricht

Ein Workflow lässt sich in derselben Sitzung fortsetzen. Claude Code spielt den Lauf dafür in der Reihenfolge ab, in der die Agenten gestartet sind:

• Ein fertiger Agent liefert sein gespeichertes Ergebnis. Hat sich sein Auftrag geändert, etwa durch ein bearbeitetes Skript, laufen er und alle nach ihm gestarteten Agenten neu.
• Ein Agent, der beim Anhalten noch lief, beginnt von vorn.
• Wer den ganzen Lauf anhält, macht damit keinen Agenten zum Fehlschlag.

Anders bei einem Fehlschlag. Dann laufen der gescheiterte Agent und jeder nach ihm gestartete erneut, auch wenn er schon fertig war. Ein Fehler mitten in einer breiten Verteilung wiederholt also Arbeit, die schon erledigt war. Wer einen einzelnen Agenten in /workflows mit x anhält, löst genau diesen Fall aus, denn das gilt als Fehlschlag.

Zwei Fälle fängt die Laufzeitumgebung selbst ab. Stockt ein Agent zu lange ohne Ausgabe, startet Claude Code ihn bis zu fünfmal neu. Erreicht ein Lauf die Grenze des Abos, wartet er seit Version 2.1.271 auf das Zurücksetzen, statt die betroffenen Agenten scheitern zu lassen. Das gilt nur unter Bedingungen, etwa in einer interaktiven Sitzung mit einem Abo von claude.ai und bei einer Grenze, die binnen 24 Stunden zurückgesetzt wird.

Bei Agent Teams ist die Liste der Grenzen länger, und die Doku führt sie offen als Einschränkungen eines Experiments:

• /resume und /rewind holen Teammates, die im selben Terminal laufen, nicht zurück. Nach dem Fortsetzen startet man neue.
• Eine Sitzung hat genau ein Team.
• Teammates starten keine eigenen Teammates, ein Team verwaltet nur der Lead.
• Lead bleibt die Sitzung, die das Team gestartet hat, solange sie läuft.
• Der Stand einer Aufgabe hinkt manchmal hinterher, weil ein Teammate sie nicht als erledigt markiert. Abhängige Aufgaben bleiben dann blockiert.

Ein Thread in einem Project pausiert zwischen zwei Antworten in seiner Sandbox. Lässt sie sich nicht fortsetzen, beginnt der Thread mit einem frischen Klon, und was nicht committet war, kann verloren sein. Bei langen Aufgaben rät die Doku, Claude Zwischenstände committen und pushen zu lassen.

Was eine Messung von außen über die Kosten sagt

Die Doku des Herstellers nennt für Teams eine Zahl, mit Bedingung: Laufen die Teammates im Plan-Modus, braucht ein Agent Team ungefähr siebenmal so viele Token wie eine gewöhnliche Sitzung (Kostenseite (externe Seite, code.claude.com)).

Kosten und Ergebnis nebeneinander stellt eine Messung von Vals AI vom 09.10.2026, auf einem eigenen Benchmark des Anbieters (Bericht (externe Seite, vals.ai)). Gemessen wurde der Bau von 50 Web-Anwendungen nach einer Spezifikation. Das Team war dort ein Leitagent mit Subagents. Opus 5.5 lief über Claude Code im nicht interaktiven Modus, als Einzelagent ohne die Werkzeuge für Subagents und als Team mit ihnen. Ohne interaktive Sitzung startet Claude Code keine Teammates. Gemessen ist also die Form aus Kapitel 20.

Über beide Modelle und beide Stufen des Effort kosteten die Teams das 1,8- bis 5,1-Fache eines Einzelagenten. Bei Opus 5.5 erreichte der Einzelagent auf mittlerem Effort im Mittel 91,5 Prozent der Oberflächentests für 4,08 Dollar je Anwendung. Das Team auf höchstem Effort kam auf 93,2 Prozent für 122 Dollar, rund das Dreißigfache. Den Unterschied im Ergebnis wertet der Bericht als statistisch nicht gesichert. Den größten Teil der Mehrkosten machen nach dem Bericht zwi­schen­ge­spei­cherte Eingaben aus. Jeder Subagent hält Spezifikation und Arbeitsstand in seinem eigenen Kontext und schickt beides bei jedem Aufruf mit. Das ist dieselbe Rechnung, mit der die Doku die Kosten eines Teams begründet.

Die Grenzen der Messung nennt der Bericht selbst. Jeder der acht Aufbauten lief genau einmal. Und die Befunde stammen aus einem einzigen Benchmark für Web-Anwendungen, für andere Arbeit müssen sie nicht gelten. Dazu bekamen die Teams eine Anweisung zum Delegieren, die den Einzelagenten fehlte. Für die Kernfrage dieses Kapitels heißt das: In allen vier Vergleichen kostete das Team mehr. Ob es mehr bringt, hängt nach dem Bericht von Modell, Aufgabe und Budget ab. Den Probelauf an einem kleinen Ausschnitt, den die Doku für Workflows empfiehlt, ersetzt eine fremde Messung deshalb nicht.