Claude Code Projects als Beta: Agententeams, die parallele Arbeit planen und koordinieren

Wie Claude Code Agententeams mit der Projekte-Beta zusammenhängen

Das Ankündigung der überarbeiteten Projekte stellt ein Projekt vor, das um fortlaufende Arbeit herum organisiert ist: Ein Koordinator steuert Threads, ein gemeinsamer Speicher überträgt Kontext zwischen ihnen, und eine Bibliothek sammelt Dateien und Artefakte.

Der Koordinator hat eine klar definierte Rolle. Er steckt Anfragen ab, delegiert Arbeit an parallele Threads, prüft deren Ergebnisse und führt sie zusammen. Jeder Thread erledigt seine Arbeit in einer Claude Code Cloud-Sitzung.

Agententeams gab es bereits vor dieser Einführung. Claude Code v2.1.32, veröffentlicht am 5. Februar 2026, führte sie als Forschungsvorschau für die Zusammenarbeit mehrerer Agenten ein. Bei dieser Veröffentlichung wurde die Funktion als tokenintensiv beschrieben und erforderte eine experimentelle Umgebungsvariable.

Diese Unterscheidung ist beim Lesen von Einrichtungsanleitungen wichtig. Die CLI-Funktion vom Februar und die Projekte-Beta vom September haben unterschiedliche dokumentierte Einstiegspunkte. Die Projektankündigung nennt das experimentelle CLI-Flag nicht als Voraussetzung für die Aktivierung.

Zur Orientierung zwischen diesen Funktionen bietet der Übersichtsseite mit Leitfäden zu Claude Code einen Ausgangspunkt. Unterscheiden Sie zwischen Projektkoordinator, Cloud-Threads und Subagenten, wenn Sie entscheiden, welcher Workflow zu einer Aufgabe passt.

Zugriff und Einrichtung zum Stand vom 21. September

Der anfängliche Zugriff war auf ausgewählte Pro- und Max-Abonnenten beschränkt, die Claude Code Cloud-Sitzungen nutzten und keine bestehenden Web- oder Desktop-Projekte hatten. Ein breiterer Zugang für Pro und Max war geplant; der Zugang für Team und Enterprise sollte folgen.

Der Kurzbericht belegt nicht, dass der breitere Rollout bis zum 21. September abgeschlossen war. Ein Abonnement allein sollte daher nicht als Nachweis gelten, dass die Beta der überarbeiteten Projekte für ein bestimmtes Konto verfügbar war.

Was Sie konfigurieren

Die Projekteinrichtung beginnt mit einem Ziel und einem Repository oder Kontext. Die Konfiguration umfasst die Cloud-Umgebung, Konnektoren, Plugins, Anweisungen und das Modell.

Bei einer Entwicklungsaufgabe sollte ein hilfreiches Ziel das gewünschte Ergebnis und die für die Umsetzung relevanten Einschränkungen beschreiben. Beispielsweise könnten Sie eine Funktion anfordern, die eine API und ihre Benutzeroberfläche umfasst, und anschließend Akzeptanzkriterien sowie Codebereiche angeben, die besondere Sorgfalt erfordern. Dies ist ein Vorschlag, wie Sie die Arbeit für den Koordinator formulieren können, und keine dokumentierte Garantie dafür, wie er die Anfrage aufteilt.

Sie können die Arbeit über den Projektchat oder einzelne Threads steuern, auch vom Smartphone aus. Im Projektchat können Sie die gesamte Arbeit lenken; in einem einzelnen Thread können Sie einen bestimmten Teil davon steuern.

Was nicht näher festgelegt ist

Die Ankündigung zur Einführung nennt weder eine Mindestversion der CLI noch eine zahlenmäßige Obergrenze für gleichzeitige Threads oder einen gesonderten Beta-Preis. Sie belegt auch nicht, dass bis zum Redaktionsschluss alle berechtigten Abonnementstufen Zugang erhalten hatten.

Diese Lücken sind für die Planung relevant. Bauen Sie keinen Workflow auf einer angenommenen Anzahl gleichzeitiger Threads oder einem angenommenen Rollout-Datum auf.

Wie parallele Threads arbeiten und wo Integration weiterhin wichtig ist

Der Koordinator steckt die Anfrage ab und delegiert parallele Threads. Jeder Thread läuft als Claude Code Cloud-Sitzung mit eigenem Branch und eigener Repository-Kopie, sodass für die parallele Arbeit getrennte Arbeitskopien zur Verfügung stehen.

Threads können selbst Subagenten, Schleifen und Workflows verwenden. Das Projekt hat daher mehr als eine Delegationsebene: Der Koordinator steuert Threads, und ein Thread kann weitere Arbeit an Subagenten delegieren.

Arbeit nach abzuliefernden Ergebnissen aufteilen

Eine praktische Möglichkeit, eine Anfrage vorzubereiten, besteht darin, voneinander trennbare Ergebnisse zu identifizieren. Bei einer vorgeschlagenen Funktion könnten dies die API-Implementierung, Änderungen an der Benutzeroberfläche und die Prüfung sein. Dies sind beispielhafte Aufgabengrenzen, keine zugesicherte Regel für die Aufteilung.

Legen Sie für jedes abzuliefernde Ergebnis eine klare Abschlussbedingung fest. Wenn zwei Teile von derselben Schnittstelle abhängen, beschreiben Sie diese gemeinsame Schnittstellenvereinbarung in den Projektanweisungen, damit sie dem Koordinator beim Abstecken der Arbeit vorliegt.

Die frühere Ankündigung zu Agententeams vom Februar betonte insbesondere unabhängige Aufgaben mit hohem Leseanteil, etwa die Prüfung einer Codebasis. Diese Ausrichtung bleibt bei der Auswahl parallelisierbarer Arbeit hilfreich: Berücksichtigen Sie, wie viel Koordination eine Aufgabe erfordert, bevor Sie sie in mehrere Aufträge aufteilen.

Getrennte Branches verhindern keine Konflikte

Die Projektankündigung hält ausdrücklich fest, dass bei sich überschneidenden Codeänderungen weiterhin Merge-Konflikte gelöst werden müssen. Getrennte Branches und Repository-Kopien beseitigen den Integrationsaufwand nicht, wenn Threads denselben Code bearbeiten.

Deshalb sollte die Prüfung auch berücksichtigen, wie die Ergebnisse zusammenpassen. Eine vorgeschlagene Prüfliste umfasst die Fragen, ob die Schnittstellen übereinstimmen, sich überschneidende Änderungen miteinander abgestimmt wurden und das zusammengeführte Ergebnis das ursprüngliche Ziel erfüllt.

Der Kurzbericht belegt keinen Workflow zur Koordination von Änderungen über mehrere Repositories hinweg. Dass ein Thread eine eigene Repository-Kopie hat, ist kein ausreichender Nachweis für eine unterstützte repositoryübergreifende Orchestrierung. Diese Fähigkeit sollte daher eine offene Frage bleiben.

Gemeinsamer Speicher und Projektbibliothek

Threads tragen zum gemeinsamen Projektspeicher bei, während die Projektbibliothek hochgeladene Dateien und generierte Artefakte sammelt. Dadurch entstehen zwei Formen dauerhaften Projektkontexts: von Threads beigesteuerter Speicher und eine Sammlung von Materialien, die mit der Arbeit verbunden sind.

Für Entwickler hilft diese Unterscheidung, Eingaben zu organisieren. Ein Designdokument oder eine Referenzdatei gehört sinnvollerweise zu den Projektmaterialien; Informationen, die bei der Erledigung der Arbeit entdeckt werden, können zum gemeinsamen Speicher beitragen.

Planen Sie, was künftige Arbeit benötigt

Überlegen Sie bei der Vorbereitung eines Projekts, welche Vorgaben im weiteren Verlauf der Arbeit verfügbar bleiben sollten. Dazu können etwa das beabsichtigte Verhalten einer Schnittstelle, Repository-Konventionen oder Entscheidungen gehören, die mehrere Arbeitsergebnisse betreffen.

Diese Beispiele sind Empfehlungen für die Organisation eines Projekts. Die Ankündigung legt weder das genaue Format des gemeinsamen Gedächtnisses fest noch garantiert sie, dass jedes Detail aus jedem Thread erhalten bleibt.

Sie definiert auch keine Aufbewahrungsfristen, Speicherlimits oder genauen Regeln dafür, wann gespeicherte Informationen einen anderen Thread erreichen. Die belegte Aussage ist enger gefasst: Threads tragen zum gemeinsamen Gedächtnis bei, und die Bibliothek sammelt hochgeladene Dateien und generierte Artefakte.

Prüfen Sie generierte Artefakte im Rahmen der Bewertung des zusammengeführten Ergebnisses. Ihre Präsenz in der Bibliothek belegt, dass sie dort gesammelt werden; sie belegt für sich genommen nicht ihre Korrektheit.

Subagenten und der frühere CLI-Workflow für Agententeams

Claude Code-Subagenten unterstützten bereits vor der Projekt-Beta die parallele Entwicklung. Die Ankündigung von Anthropic vom 29. September 2025 enthielt das Beispiel eines Subagenten, der eine Backend-API entwickelte, während der Hauptagent das Frontend erstellte.

In den neu gestalteten Projekten kann ein Thread Subagenten aufrufen. Damit sind Subagenten Teil der innerhalb eines Threads verfügbaren Ausführungsmöglichkeiten, während der Koordinator auf Projektebene den Umfang festlegt, Aufgaben delegiert und Ergebnisse zusammenführt.

Das Leitfaden zu Subagenten ist eine nützliche Ergänzung bei der Planung dieser inneren Delegationsebene. Trennen Sie deren Konfiguration von der Frage, ob Ihr Konto Zugriff auf die Projekt-Beta hat.

Das experimentelle CLI-Flag hat einen bestimmten Geltungsbereich

Die im Februar veröffentlichte Version v2.1.32 erforderte für ihre Forschungsvorschau für Agententeams diese Umgebungsvariable:

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Die Projektankündigung vom September nennt diese Variable nicht als Voraussetzung für die Aktivierung der Beta. Ihre Aktivierung sollte daher nicht als Anleitung für den Zugriff auf die neu gestalteten Projekte dargestellt werden.

Die Veröffentlichung im Februar dokumentierte außerdem die direkte Übernahme über Umschalt+Pfeil nach oben/unten oder tmux. Das sind Bedienelemente aus der Einführungsphase des früheren Workflows für Agententeams; es sollte nicht davon ausgegangen werden, dass sie die neu gestaltete Projektoberfläche beschreiben.

Veraltete Anleitungen zur Einrichtung von Subagenten vermeiden

Von v2.1.198 am 1. Juli 2026, war der /agents Assistent entfernt worden. Der datierte Änderungsverlauf weist Nutzer an, Claude zu bitten, Subagenten zu erstellen oder zu verwalten, oder .claude/agents/ direkt zu bearbeiten.

Ein Leitfaden vom September sollte diese Methoden verwenden, statt Leser zum Öffnen des älteren Assistenten aufzufordern. Dies ist ein konkretes Beispiel dafür, warum datierte Versionsinformationen wichtig sind, wenn Anleitungen für Projekte, Agententeams und Subagenten kombiniert werden.

Nutzung, Modellauswahl und lokale Ausführung

Parallele Projektsitzungen schöpfen die Nutzungslimits schneller aus. Laut Projektankündigung können Nutzer die Projektnutzung einsehen sowie Modelle und Aufwand für Koordinator und Worker auswählen. Sie nennt jedoch keinen numerischen Kostenmultiplikator für parallele Arbeit.

Damit ist der Umfang eine wichtige Planungsentscheidung. Überlegen Sie vor dem Hinzufügen von Threads, ob die Arbeit genügend unabhängige Teile umfasst, um die zusätzliche Aktivität zu rechtfertigen. Berücksichtigen Sie bei der Bewertung des Workflows die verfügbaren Optionen für Modelle und Aufwand zusammen mit den Informationen zur Projektnutzung.

Die Änderung der Limits im September

Das Hinweis zu den wöchentlichen Limits von Claude Code besagt, dass die wöchentlichen Limits für Pro, Max, Team und sitzplatzbasiertes Enterprise ab dem 14. September dauerhaft um 25 % gegenüber dem Stand vor der Aktion erhöht wurden.

Die vorherige Aktion mit einer Erhöhung um 50 % lief vom 13. Mai bis zum 13. September und endete um 11:59 Uhr PT. Sie änderte die Fünf-Stunden-Limits nicht; Free und verbrauchsbasierte Enterprise-Sitzplätze waren ausgeschlossen.

Claude Code stellt diesen CLI-Befehl zum Prüfen der Nutzung bereit:

/usage

Das Leitfaden zu Ratenlimits kann beim Verständnis der damit verbundenen Nutzungskonzepte helfen. Höhere wöchentliche Limits heben den Hinweis aus der Projektankündigung nicht auf, dass parallele Sitzungen die Limits schneller ausschöpfen.

Die lokale Ausführung stand noch bevor

Die Ankündigung vom September beschrieb die lokale Ausführung als bevorstehend. Mit Stand vom 21. September verwendete der dokumentierte Projektworkflow Cloud-Sitzungen, die über den Projektchat oder einzelne Threads gesteuert wurden.

Ein lokaler Claude Code-Workflow und die neu gestaltete Beta für Cloud-Projekte sollten daher getrennt bewertet werden. Die Ankündigung nennt weder einen Starttermin für lokale Projekte noch eine abgeschlossene lokale Einführung.

Wichtige Erkenntnisse

• Die neu gestalteten Projekte starteten am 17. September in der Beta, mit einem Koordinator, der den Umfang von Anfragen festlegt, Aufgaben an parallele Threads delegiert, Ausgaben prüft und Ergebnisse zusammenführt.
• Claude Code-Agententeams gab es bereits vor der Beta: v2.1.32 führte am 5. Februar die separate CLI-Forschungsvorschau ein.
• Jeder Projektthread hat eine eigene Cloud-Sitzung, einen eigenen Branch und eine eigene Repository-Kopie; bei überlappenden Änderungen müssen weiterhin Merge-Konflikte gelöst werden.
• Threads tragen zum gemeinsamen Projektgedächtnis bei, und eine Bibliothek sammelt hochgeladene Dateien und generierte Artefakte.
• Der anfängliche Zugriff war auf ausgewählte Pro- und Max-Abonnenten beschränkt, die die angekündigten Bedingungen erfüllten. Parallele Arbeit schöpft die Limits schneller aus, und die lokale Ausführung stand weiterhin bevor.

FAQ

Wie erhalte ich Zugriff auf die Beta der neu gestalteten Projekte?

Der anfängliche Zugriff galt für ausgewählte Pro- und Max-Abonnenten, die Claude Code-Cloud-Sitzungen nutzten und keine bestehenden Web- oder Desktop-Projekte hatten. Ein breiterer Zugriff für Pro und Max war geplant, gefolgt von Team und Enterprise. Die Ankündigung belegt jedoch keine abgeschlossene breitere Einführung bis zum 21. September.

Wie unterscheiden sich Projekte, Agententeams und Subagenten?

Ein neu gestaltetes Projekt hat einen Koordinator, der Threads in Cloud-Sitzungen steuert und ihre Ergebnisse zusammenführt. Agententeams wurden zuvor als separate CLI-Forschungsvorschau eingeführt, während Subagenten delegierte Arbeit erledigen und innerhalb von Projektthreads aufgerufen werden können.

Was passiert, wenn zwei Threads denselben Code bearbeiten?

Jeder Projektthread arbeitet in einem eigenen Branch und mit einer eigenen Repository-Kopie. Bei überlappenden Codeänderungen müssen weiterhin Merge-Konflikte gelöst werden; die Projektankündigung verspricht keinen automatischen Abgleich.

Können Projektthreads lokal ausgeführt werden, und wie steuere ich sie?

Mit Stand vom 21. September nutzte die dokumentierte Beta Claude Code-Cloud-Sitzungen, und die lokale Ausführung war als bevorstehend angekündigt. Sie können die Arbeit über den Projektchat oder einzelne Threads steuern, auch von einem Smartphone aus.