Claude Code Projects schicken einen Coordinator los, der parallele Cloud-Threads ansetzt — klingt nach dem Traum, nicht mehr alles selbst zu mergen. Spoiler: Jeder Thread ist eine volle Session, und das Limit merkt das, bevor die Pull Requests sauber übereinanderliegen. Wer die Beta nicht sieht oder den Usage-Schock scheut, bleibt besser bei einem Chat, bis lokale Threads klar sind.
Spoiler: Das Limit war weg, drei Threads hatten gearbeitet, zusammengebaut war nichts. Ich hatte einem Coordinator ein Ziel hingeworfen, das in meinem Kopf nach einem Nachmittag klang. Checkout schneller. Klingt einfach, ist es aber nicht. Der Coordinator nickte auf die Art, wie ein Chat nickt — mit einem Plan statt mit einem Kopf — und schickte drei Threads los. Büroleitung, drei Freelancer, drei Schreibtische. Jeder bekam eine eigene Kopie des Repos, jeder bastelte auf einem eigenen Branch, jeder kam stolz zurück. Ich war unterwegs und habe vom Telefon nur noch „läuft“ gelesen. Die Rechnung, also das Usage-Limit, war schon aufgegangen. Der Merge? Null.
Zwei Threads hatten dieselbe Funktion angefasst. Konflikt, wie bei jeder anderen Pull Request. Der dritte hatte Tests mitgebracht, die niemand mehr einsortiert hat. Im Ernst: Das ist kein Märchen aus dem Forum. Das ist die Lesart, die ich aus der Ankündigung ziehe, bevor die Folien hübsch werden.
Nerd-Alarm: Am 17. September 2026 hat Anthropic genau dieses Muster als neues Projects in Claude Code beschrieben. Beta. Nicht als meinen Fail. Als Produkt. Ich leihe mir den Fail nur, weil er die Mechanik schneller erklärt als jede Produktseite.
Der Blog heißt „Projects redesigned: from folder to conversation“. Übersetzung, die den Kern trifft: vom Ordner zur Unterhaltung. Sie beschreiben ein Ziel. Claude schneidet den Auftrag zu, verteilt ihn, koordiniert parallele Threads, prüft die Ergebnisse und setzt sie zusammen. Steuern können Sie aus dem Projekt-Chat oder aus dem einzelnen Thread, auch vom Telefon. Die Arbeit läuft weiter, wenn Sie den Rechner zumachen und in die Bahn steigen.
Wir bei digital-magazin.de geben die Beispiele aus dieser Ankündigung nicht als eigene Messung aus. Kein p75 von uns, keine Stunde, die jemand angeblich spart, kein Token-Zähler. Die These steht trotzdem fest: Der Traum ist, nicht mehr alles selbst zu mergen. Die Rechnung kommt, weil jeder Cloud-Thread eine volle Session ist. Das Limit merkt das. Punkt.
die kurze Version, bevor die Büroleitung weiter Personal einstellt: Coordinator jetzt nur, wenn Sie in der ausgewählten Beta sitzen, Cloud-Sessions in Claude Code haben und das Limit im Blick behalten. Alle anderen bleiben bei einem Chat. Warten, bis lokale Threads da sind — Anthropic sagt „very soon“, ohne Datum — und bis Team und Enterprise nicht mehr „später“ heißen.
Kennen Sie das Gefühl, drei Leute gleichzeitig loszuschicken und hinterher selbst die drei Versionen zu lesen? Genau da steht Projects. Nur dass die drei Leute Cloud-Sessions sind und die Gehaltsabrechnung Usage heißt.
Claude Projects: der Ordner wird zur Unterhaltung
Bisher waren Projects, grob gesagt, ein Ordner mit Kontext. Dateien rein, Anweisung dran, Chat dazu. Praktisch, wenn Sie dem Modell denselben Hintergrund nicht bei jeder Frage neu erzählen wollten. Die neue Fassung, Beta in Claude Code, dreht die Rolle. Sie liefern Ziel plus Repo oder anderen Kontext. Claude schlägt laut Anthropic Arbeit vor, die es sofort aufnehmen kann. Danach entsteht nicht eine lange Antwort, sondern eine Baustelle mit mehreren Threads.
Mal ehrlich: Ein Ordner vergisst nichts, entscheidet aber auch nichts. Eine Unterhaltung mit Coordinator entscheidet ständig. Welcher Thread. Welches Stück. Wann Rückfrage. Das ist der Sprung, und er ist größer als ein neues Icon.
Beim Start lässt sich laut Blog einiges festnageln: Cloud-Umgebung, Connectors, Plugins, Instructions, Modell. Keine Preisliste, keine Plug-in-Inventur von mir — nur die Stellschrauben, die Anthropic nennt. Wer Claude Code bisher als einzelnen Werkzeugkasten im Blick hat, erkennt die Session wieder. Projects setzt mehrere davon unter ein Dach und gibt ihnen eine Büroleitung.
Anthropic formuliert den Tonfall so: Briefen Sie Claude im Projekt, wie Sie eine Chief of Staff briefen würden. Die Büroleitung reicht den Auftrag an neue oder schon laufende Threads weiter. Das ist kein nettes Verb. Das ist die Schnittstelle. Unklar gebrieft, unklar verteilt.
Ein Brief, den ich selbst so schreiben würde — Gedankenspiel, kein Laborlauf:
- Ziel in einem Satz, nicht in einem Roman.
- Welche Repos, welche Dateien tabu sind.
- Was sich überlappen darf und was auf keinen Fall.
- Ob am Ende Pull Requests liegen sollen oder nur ein Entwurf.
- Wie oft der Coordinator sich melden soll, bevor er den nächsten Thread öffnet.
Klingt einfach, ist es aber nicht. Die Chief of Staff in einem menschlichen Büro fragt nach, wenn der Satz zwei Bedeutungen hat. Ein Coordinator kann nachfragen. Er kann auch loslegen, sobald das Ziel „voll genug“ wirkt. Der Unterschied liegt in Ihrer ersten Nachricht, nicht in einem versteckten Schalter, den ich Ihnen als Garantie verkaufen könnte. Eine Garantie steht in der Quelle nicht.
Lange Läufe sind der erklärte Zweck. Anthropic schreibt, Projects seien für Arbeit gedacht, die länger dauert als eine Antwort und aus mehr als einem Teil besteht. Ein einzelner Chat bleibt die richtige Kammer, wenn die Aufgabe in eine Antwort passt. Ein Endpoint, eine Datei, eine Frage. Projects ist die Kammer für das, was sich sonst in fünf Chats zerlegt und dann in Ihrem Kopf wieder zusammenkommt.
Das Kuriose daran: Sie müssen nicht am Schreibtisch sitzen bleiben. Projekt-Chat oder einzelner Thread, auch vom Telefon. Die Threads arbeiten weiter, wenn Sie weggehen. Das ist der Satz, bei dem ich hellhörig werde. Weggehen heißt: Die Büroleitung schickt weiter Freelancer, während Sie im Zug nach einem Sitzplatz suchen. Bequem. Und die Rechnung läuft.
Steuern heißt auch korrigieren. Sie können im Hauptchat den Überblick halten oder in einen Thread steigen und das Detail drehen. Beides ist in der Ankündigung beschrieben. Beides setzt voraus, dass Sie hinsehen. Wer nur das Ziel absetzt und drei Stunden später den Merge erwartet, behandelt den Coordinator wie einen Nachtportier. Der Nachtportier räumt nicht Ihren Konflikt auf. Er notiert ihn.
Der Coordinator schickt die Threads — und merkt die Rechnung
Personifikation, weil sie hier genauer ist als jedes Schichtendiagramm. Der Coordinator ist die Büroleitung. Er nimmt das Ziel, schneidet es, verteilt, schaut drauf, setzt zusammen. Die Threads sind die Freelancer. Jeder hat einen Auftrag, einen eigenen Schreibtisch, wenig Lust, dem anderen in die Tastatur zu fassen — bis sie es doch tun.
Unter der Haube, und das ist kein Bild mehr, sondern der Satz aus dem Blog: Jeder Thread ist eine Claude-Code-Cloud-Session. Eigener Branch. Eigene Kopie des Repos. Der Coordinator hält die Arbeit sortiert. Wenn zwei Threads denselben Code anfassen, wird die Überlappung als Merge-Konflikt gelöst. Wie jede andere PR.
Stevie Bonifield zitiert genau diesen Mechanismus-Satz bei The Verge am 17. September 2026, 20:58 Uhr (Berlin). Verge rahmt das Ganze als Team von Agenten mit gemeinsamem Gedächtnis, Zielen und einer Bibliothek aus Dateien und Artefakten. „Team“ ist die Verge-Brille. Anthropic selbst spricht von Coordinator und Threads. Ich bleibe bei den Produktworten, sonst stellt sich jemand einen Besprechungsraum vor, den es so nicht gibt.
Under the hood, each thread is a Claude Code cloud session working on its own branch and copy of the repo. The coordinator keeps work organized, but if any threads work on the same code, the overlap is resolved as a merge conflict just like any other PR.
Anthropic, Blog zu Projects, 17. September 2026 — von Stevie Bonifield bei The Verge zitiert
Übersetzt, ohne den Satz weichzuspülen: Jeder Thread ist eine volle Cloud-Session von Claude Code, auf eigenem Branch, mit eigener Repo-Kopie. Der Coordinator organisiert. Überlappung wird Merge-Konflikt. Nicht Magie. Git, wie Sie es kennen, nur dass die Autorinnen und Autoren der Commits Sessions sind.
Und der Thread darf weiter aufteilen. Anthropic schreibt, ein Thread könne delegierte Arbeit mit Subagents, Loops und Workflows in Stücke schneiden, damit große Aufträge schneller fertig werden. „Schneller“ ist ihr Claim, keine Stoppuhr von digital-magazin.de. Für die Personifikation heißt das: Der Freelancer stellt Helfer ein. Die Helfer sitzen nicht am selben Schreibtisch umsonst. Sie sind weitere Arbeit in derselben Session-Logik. Ob jede Unterteilung eine extra abgerechnete Session ist, steht so nicht da. Was dasteht: Der Thread selbst ist schon eine volle Session. Alles, was er intern aufmacht, passiert nicht außerhalb des Limits, nur weil es „Workflow“ heißt. Hand aufs Herz, ich lese das konservativ. Lieber eine Session zu viel im Kopf einplanen als eine zu wenig.
Mit angebundenen Repos öffnet ein Thread Pull Requests und lässt Ihre Tests laufen. Mit Dokumenten liest er und entwirft. Wieder: Claim der Ankündigung. Wenn Ihre Tests rot sind, werden sie nicht grün, weil ein Coordinator „zusammenbauen“ gesagt hat. Er setzt zusammen, was die Threads liefern. Müll in drei Branches bleibt Müll in drei Branches, nur mit einer ordentlichen Aktennotiz.
Aber Moment mal: Warum fühlt sich Parallelität nach einem Geschenk an? Weil Sie eine Nachricht tippen und mehrere Dinge gleichzeitig „passieren“. Der Kopf rechnet: eine Anfrage, ein Preis. Das Produkt rechnet: mehrere volle Sessions. Die Büroleitung merkt die Rechnungen. Sie merken sie am Limit.
Modell und Effort lassen sich laut Anthropic für den Coordinator-Chat und für die Worker-Threads wählen. Getrennt. Das ist einer der wenigen Hebel, die die Quelle Ihnen ausdrücklich in die Hand gibt. Welches Modell wie viel Usage frisst, erfinde ich nicht. Dass die Wahl existiert, schon. Wer den Coordinator auf einem schweren Gang laufen lässt und jeden Worker ebenso, sollte sich nicht wundern, wenn die Anzeige schneller fällt als bei einem einzelnen Chat am selben Nachmittag.
Projektbezogene Usage ist einsehbar. Anthropic sagt das so. Kein Screenshot von mir, keine Schwelle in Prozent. Der praktische Satz: Schauen Sie hin, bevor Sie den dritten Thread feiern. Die Anzeige ist der Kassenzettel. Wer ihn nicht öffnet, diskutiert hinterher mit einem leeren Konto.
Eigener Branch, eigene Kopie — der Konflikt ist kein Bug
Ein Merge-Konflikt klingt nach Panne. In diesem Aufbau ist er der vorgesehene Ausgang, sobald sich die Arbeit überschneidet. Anthropic schreibt nicht, der Coordinator verhindere Überschneidungen magisch. Er hält die Arbeit organisiert. Die Auflösung bleibt ein Merge, wie Sie ihn aus jedem anderen Pull Request kennen.
Stellen Sie sich das Repo als Wohnung vor. Jeder Thread bekommt eine Kopie, keinen Zweitschlüssel zur selben Kommode. Thread A räumt die Kommode im Flur um, weil dort die Latenz „logisch“ sitzt. Thread B räumt dieselbe Kommode um, weil der Checkout-Pfad dort eine Hilfsfunktion hat. Beide sind fertig. Beide haben recht, in ihrer Kopie. Beim Zusammenlegen passen die Schubladen nicht mehr. Das ist der Konflikt. Nicht Bosheit. Zwei Kopien, ein Original.
Was Sie daraus machen, steht nicht als Ein-Klick-Versprechen im Blog. „Aufgelöst wie jede andere PR“ heißt: Jemand schaut hin. Sie, oder ein weiterer Lauf, den Sie anstoßen. Der Coordinator soll am Ende zusammensetzen. Ersetzt das Ihr Review? Ich finde, nein. Ein Review, das die Ankündigung verspricht, ist ihre Review-Rolle im Ablauf — scoped, delegated, koordiniert, geprüft, zusammengebaut. Das ist der beschriebene Prozess, kein Audit-Bericht mit Stempel.
Nerd-Alarm zur Reihenfolge. Im zweiten Beispiel der Ankündigung — dazu später, ausdrücklich als Beispiel, nicht als Benchmark — soll Claude Ihnen sagen, welche Pull Requests zuerst gemergt werden müssen. Merge-Reihenfolge mitteilen ist etwas anderes, als den Merge fehlerfrei für Sie zu erledigen. Mitteilen können Sie ignorieren. Fehlerfrei ist ein anderes Verb, und das steht so nicht da.
Wer schon einmal drei Feature-Branches am Freitag übereinandergelegt hat, kennt die Stimmung. Der eine Branch ist grün, der zweite grün, zusammen rot. Projects ändert die Stimmung nicht per Dekret. Es vervielfacht die Branches, während Sie woanders sind. Das kann der Punkt sein, warum Sie es wollen. Es kann der Punkt sein, warum Sie es lassen.
Ein einzelner Chat hat dieses Problem seltener, weil er nacheinander denkt. Langsamer, enger, ein Kontext. Sie mergen in Ihrem Kopf oder in einem Branch, den Sie selbst aufgemacht haben. Der Preis ist Zeit am Stück. Der Gewinn: weniger Kopien, die sich widersprechen. Für ein Bastelprojekt mit einem Repo und einer klaren Datei reicht das oft. Für „ändere den v1-Endpoint in API, Web und Mobile gleichzeitig“ ist der einzelne Chat der Flaschenhals, den Projects auflösen will. Ob er ihn auflöst, hängt an Brief, Überlappung und Limit. Nicht am Wörtchen parallel.
Die Tabelle, damit die drei Wege nicht in einem Absatz verschwimmen. Die rechte Spalte ist kein Produkt, das Sie heute anklicken. Sie ist die Ankündigung „very soon“, Zeitpunkt unbekannt.
| Frage | Cloud-Thread in Projects | Einzelner Chat | Lokale Threads |
|---|---|---|---|
| Wo läuft die Arbeit? | Cloud. Jeder Thread ist eine Claude-Code-Cloud-Session. | Eine Session, ein Gespräch, ein Kontext. | Auf der eigenen Maschine, neben lokalen Werkzeugen und Code, hinter dem eigenen Netz. Anthropic: „very soon“. Datum: keins. |
| Branch und Repo | Eigener Branch, eigene Kopie. Überlappung wird Merge-Konflikt wie jede andere PR. | Sie halten den Faden. Ein Verlauf, keine parallelen Kopien von sich aus. | Nicht näher beschrieben. Nicht raten. |
| Wer verteilt? | Coordinator: scoped, verteilt, prüft, setzt zusammen. | Sie. Eine Frage, eine Antwortkette. | Offen, bis das Stück da ist. |
| Steuerung | Projekt-Chat oder einzelner Thread, auch vom Telefon. Läuft weiter, wenn Sie weggehen. | Das Fenster, in dem Sie sitzen. | Nicht spezifiziert. |
| Gedächtnis | Shared Memory plus Artifact Library. Threads schreiben hinein und lesen daraus. | Der Verlauf dieses Chats, plus was Sie selbst anheften. | Nicht beschrieben. |
| Limit | Mehrere volle Sessions. Usage-Limit schneller erreicht. Projekt-Usage einsehbar. Modell und Effort je Coordinator und Worker wählbar. | Eine Session. Das Limit dieser einen Unterhaltung. | Keine Angabe. Deshalb keine Fantasiezahl. |
| Wer kommt rein? | Beta: ausgewählte Pro- und Max-Abonnentinnen und -Abonnenten mit Cloud-Sessions in Claude Code, ohne bestehende Projekte in Web oder Desktop. Danach weitere Schritte, Warteliste. | Der Chat, den Sie heute schon haben. | Noch nicht. „Very soon“, ohne Termin. |
Lesen Sie die rechte Spalte zweimal, bevor Sie eine Kauf- oder Migrationsentscheidung daran hängen. „Very soon“ ist ein Produktfakt aus dem Blog, kein Kalender. Ich setze keinen Montag dazu, keine Woche, kein Quartal.
Geteiltes Gedächtnis: praktisch, bis der Auftrag schief steht
Shared Memory ist der Teil, den ich gleichzeitig mag und fürchte. Jeder Thread schreibt hinein und zieht daraus. Anthropic sagt, das senke den Bedarf an kompliziertem Prompt-Gefummel, weil das Projekt mit der Zeit Details lernt und sie in die Arbeit nimmt. Beispiele, die der Blog selbst nennt — nicht meine Messfälle:
- Das Release ist auf Freitag gerutscht.
- Warum der Export gestrichen wurde.
- Wen Sie fragen, bevor jemand den Billing-Service anfasst.
Das ist Büroalltag, der endlich nicht in fünf Chats verstreut liegt. Die Wandtafel. Freitag, nicht Donnerstag. Export ist raus, und zwar aus diesem Grund. Billing nur nach Rücksprache mit einer konkreten Person. Ein neuer Thread muss das nicht aus Ihrem ersten Prompt erraten, wenn das Gedächtnis es schon hält.
Der Haken sitzt in derselben Tafel. Ein schiefer Satz bleibt nicht in einem Chat. Er steht im Raum, und der nächste Thread liest ihn mit. Stellen Sie sich vor — Gedankenexperiment, kein Vorfall, den Anthropic dokumentiert hätte —, Sie sagen „Export gestrichen“. Gemeint war der CSV-Export eines Berichts. Gespeichert wird „Export gestrichen“. Drei Threads, drei Repos, drei Branches, alle behandeln Export als erledigt und tot. API, Web, Mobile. Der schiefe Auftrag landet gleichzeitig. Das ist die These, nicht eine CVE.
Im Ernst: Geteiltes Gedächtnis ist genau dann ein Gewinn, wenn die Notiz stimmt. Es ist genau dann teuer, wenn die Notiz halb richtig ist. Halb richtig reicht, um drei Freelancer in dieselbe falsche Richtung zu schicken. Die Büroleitung ist stolz, weil alle drei demselben Zettel gefolgt sind. Der Zettel war der Fehler.
Deshalb gehört die Korrektur in denselben Kanal, nicht in eine Nebenmail, die niemand ins Projekt tippt. Wenn das Release doch Donnerstag bleibt, muss das im Projekt stehen, bevor der nächste Thread den Freitag in die Release-Notes schreibt. Klingt pedantisch. Ist die billigere Variante gegenüber drei Branches, die denselben Irrtum committet haben.
Neben dem Gedächtnis gibt es die Artifact Library. Anthropic beschreibt sie als Sammelstelle für Dateien, die Sie hinzufügen, und Artefakte, die Claude erzeugt. Neues Stück Arbeit soll auf altem aufsetzen können, ohne dass Sie die Fundstücke aus alten Threads kramen. Aktenregal, nicht Kurzzeitgedächtnis. Nützlich, wenn der dritte Tag kommt. Riskant, wenn ein früher Entwurf im Regal liegt und ein Thread ihn für den aktuellen Stand hält. Die Quelle sagt nicht, dass die Library veraltete Stände von selbst markiert. Also markieren Sie. Dateiname, Datum im Text, ein Satz „das war der Entwurf vor dem Schnitt“. Basteldisziplin. Kein Feature, das ich Ihnen andichte.
Anthropic schreibt außerdem, Claude merke sich Arbeits- und Kommunikationsstil. Sie können bitten, die Check-in-Frequenz zu ändern, seltener oder häufiger neue Threads zu starten, die Updates knapper oder ausführlicher zu machen. Das ist die Wandtafel plus die Hausordnung. Wer den Coordinator alle zehn Minuten um Meldung bittet, bekommt Meldungen. Wer ihn bittet, erst bei Pull Request zu kommen, sollte nicht überrascht sein, wenn zwischen Ziel und PR eine volle Session unbemerkt am Limit nagt.
Ich würde die Hausordnung am ersten Tag setzen, nicht am dritten, wenn der Schaden schon in drei Branches liegt. Häufigkeit der Check-ins. Schwelle für neue Threads. Detailgrad. Und ein Satz, was niemals ohne Rückfrage angefasst wird — Billing, Auth, die eine Datei, deren Name im Team schon für Seufzer sorgt. Das steht als Möglichkeit in der Quelle, weil der Billing-Service genau als Gedächtnisbeispiel auftaucht. Nutzen Sie das Beispiel als Warnschild, nicht als Einladung zum Herumprobieren an der Kasse.
Ein Projekt über eine Woche: Anthropic skizziert die Oberfläche so, dass jede Anfrage rechts einen Thread öffnet, während Gedächtnis, Entscheidungen und Ergebnisse darunter wachsen. Ob Ihre Ansicht genauso aussieht, hängt am Rollout. Die Idee ist klar. Oben der laufende Auftrag, unten das, was schon entschieden wurde. Wenn unten etwas Falsches wächst, wächst oben der nächste Thread darauf. Dann sind Sie nicht „ein bisschen daneben“. Sie sind mehrfach daneben, parallel, mit Rechnungen.
Das ist eine andere Baustelle als ein Agent-Host, der den Ordner zumacht und die Session trotzdem weiterlaufen lässt. Dort geht es um eine Session, die den Ordner überlebt. Hier geht es um mehrere Sessions, die sich ein Gedächtnis teilen. Ähnliches Wort, andere Rechnung. Und es ist nicht dasselbe wie Copilot in JetBrains, wo Sandbox und Keychain zwei verschiedene Schlösser sind. Schlösser sind wichtig. Sie sind nur nicht dieser Text.
Beta für ausgewählte Pro- und Max-Nutzende — der Rest steht davor
Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPerson on a commuter train holding a phone with a blurred chat, laptop bag closed on the seat, late-evening window light, documentary photo, no logos, no readable text, 16:9Zugang ist der Punkt, an dem viele Ankündigungen freundlicher klingen, als der erste Satz hergibt. Anthropic, 17. September 2026, wörtlich in der Sache: Ab diesem Tag sind die erneuerten Projects in der Beta für ausgewählte Claude-Pro- und Max-Abonnentinnen und -Abonnenten da, die Cloud-Sessions in Claude Code nutzen und keine bestehenden Projekte im Web oder auf dem Desktop haben.
Lesen Sie die Bedingungen einzeln. Ausgewählt, nicht alle. Pro oder Max, nicht irgendein Konto. Cloud-Sessions in Claude Code, nicht „ich habe die App mal geöffnet“. Und: keine bestehenden Projekte in Web oder Desktop. Wer Projects schon benutzt, ist in dieser ersten Welle ausdrücklich nicht dabei.
Das Kuriose daran, und ich finde die Formulierung ehrlicher als jedes „jetzt für alle“: Bestehende Projekte auf Pro- und Max-Plänen arbeiten weiter wie bisher. Ein Upgrade soll kommen, wenn der Rollout Chat und Cowork erreicht. Ihr alter Ordner bleibt der alte Ordner. Der Coordinator zieht nicht über Nacht ein, nur weil der Blog live ist.
Über die kommende Woche — gerechnet von der Ankündigung — will Anthropic den Zugang auf weitere Claude-Code-Nutzende derselben Pläne ausweiten. Danach: erneuerte Projects auf allen Claude-Oberflächen plus Team- und Enterprise-Pläne. Wer Pro oder Max hat und noch nicht drin ist, kann sich auf die Warteliste setzen. Ein Termin für Team und Enterprise steht nicht da. „Danach“ ist das Wort. Ich mache kein Quartal daraus.
The Verge fasst den späteren Kreis so: alle Pro-, Max-, Team- und Enterprise-Nutzenden, dazu Cowork und normale Claude-Chats. Das deckt sich mit dem Blog, der Chat und Cowork als Ausbaustufe der bestehenden Projekte nennt und Team sowie Enterprise nach der Claude-Code-Welle einsortiert. Zwei Texte, eine Richtung, kein festes Datum für den zweiten Schritt.
Wir bei digital-magazin.de empfehlen Team-Pläne nicht auf einer Ankündigung, die Team noch „danach“ nennt. Wer für ein Team entscheiden muss, wartet, bis der Satz aufhört, Zukunft zu sein. Bis dahin ist die ehrliche Ansage an Mitarbeitende: Der einzelne Chat bleibt das Werkzeug, das Sie heute in die Hand nehmen können, ohne auf eine Liste zu hoffen.
Die erste Welle hat eine unangenehme Eleganz. Gerade wer Projects schon im Alltag nutzt — Web, Desktop, der Ordner, den Sie gepflegt haben —, kommt später dran. Gerade wer neu ist, keine alten Projekte hat, Cloud-Sessions fährt und ausgewählt wird, darf den Coordinator ausprobieren. Das ist kein Urteil über Ihre Disziplin. Das ist die Gate-Logik, wie sie dasteht. Ärgern erlaubt. Sich den Zugang einzureden, ist nicht erlaubt.
Warteliste ist kein Zugang. Eine Liste ist eine Liste. Ich würde sie setzen, wenn Sie Pro oder Max haben und das Produkt sehen wollen. Ich würde den Kalender nicht umräumen. Und ich würde kein Team-Onboarding schreiben, dessen erster Schritt „später“ lautet.
Das Limit: jede Cloud-Session zählt voll
Jetzt der Satz, der die Freude auf Parallelität bezahlt. Anthropic warnt selbst: Projects kann mehrere Threads zugleich laufen lassen, und jeder davon ist eine volle Claude-Code-Session. Deshalb können Projects das Usage-Limit schneller erreichen. Projektbezogene Usage lässt sich ansehen. Modell und Effort für Coordinator-Chat und Worker-Threads lassen sich wählen.
Kein Token-Wert. Kein „drei Threads gleich dreifach“, wenn die Quelle den Faktor nicht nennt. Der Faktor kann anders aussehen, je nach Modell, Effort, Länge, Werkzeugen. Was nicht anders aussieht: Es ist nicht eine Anfrage. Es sind mehrere Sessions. Das Limit behandelt sie nicht als Fußnote unter Ihrem einen Satz „mach das parallel“.
Alltag, nochmal Büro: Sie sagen der Büroleitung, drei Freelancer sollen los. Die Büroleitung nickt. Am Abend liegen drei Rechnungen, auch wenn zwei Freelancer an derselben Schublade gescheitert sind und der Merge null ist. Erfolg ist keine Voraussetzung für Usage. Arbeit ist die Voraussetzung. Gescheiterte Arbeit auch.
Das ist der Fail vom Anfang, ohne dass ich ihn als Labor zitiere. Limit verbrannt, drei Threads, null Merge. Genau die Konstellation, vor der der Warnsatz steht. Wer sie trotzdem fährt, sollte es wissen. Wer sie nicht fahren will, bleibt bei einem Chat, bis die Hebel klarer sind — Modell, Effort, Anzeige, und irgendwann Threads, die nicht zwangsläufig in der Cloud sitzen.
Heute sitzen sie in der Cloud. Anthropic schreibt, der Lauf auf der eigenen Maschine, neben Ihren lokalen Werkzeugen und Ihrem Code, hinter Ihrem Netz, komme „very soon“. Bonifield gibt dieselbe Richtung wieder: zum Start Cloud, lokale Werkzeuge und Code very soon. Ein Datum erfinde ich nicht. Eine Abhandlung über Rechner unter dem Schreibtisch auch nicht. Das ist ein Satz zum Produkt Claude Code, nicht ein zweites Thema.
Was der Satz praktisch ändert, bis er eintritt: Alles, was der Coordinator heute verteilt, läuft als Cloud-Session. Connectors, Plugins, Cloud-Umgebung — die Stellschrauben, die der Blog nennt, zeigen in dieselbe Richtung. Wer Code oder Werkzeuge braucht, die nur auf der eigenen Maschine und hinter dem eigenen Netz liegen, hat das Stück noch nicht. Warten ist dann keine Trägheit. Es ist Deckungsgleichheit zwischen Aufgabe und Laufumgebung.
Bis dahin bleibt der einzelne Chat der Ort, an dem eine Session eine Session bleibt. Sie sehen den Verlauf. Sie sehen, wann es eng wird. Sie schicken nicht drei volle Sessions los, weil ein Ziel in einem Satz so schön parallel klang. Für Lesende, die ihr Limit schon an einem langen Nachmittag leergeräumt haben, ist das kein romantischer Rat. Das ist Schonung.
Wahl von Modell und Effort ist die Gegenmaßnahme, die die Quelle hergibt, ohne Zahlen. Coordinator knapper, Worker gezielter, Check-ins seltener, neue Threads nicht bei jedem Halbsatz. Ob das reicht, sehen Sie an der projektbezogenen Anzeige, nicht an meiner Vermutung. Ich habe keine Schwelle, ab der „zu viel“ rot wird. Sie schon, in Ihrem Konto.
Zwei Beispiele aus der Ankündigung — keine Messung von uns
Anthropic gibt zwei Bilder mit, damit das Abstrakte Beine bekommt. Ich gebe sie weiter, gekennzeichnet, und messe sie nicht nach. Wir bei digital-magazin.de waren nicht in diesen Repos. Keine Latenz, die wir bestätigen. Keine Zeit, die wir subtrahieren.
Erstes Bild: Projekt anlegen, Ziel „Checkout-Latenz p75 senken“. Claude soll jeden Endpoint profilieren, Optimierungen testen und Pull Requests in parallelen Threads öffnen. p75 ist ihr Beispielmaß, nicht unseres. Ob Ihr Checkout dort überhaupt der Engpass ist, wissen wir nicht. Ob drei Threads drei verschiedene Endpoints sauber trennen oder sich in einer gemeinsamen Hilfsfunktion treffen, hängt an Ihrem Code. Die Ankündigung zeigt die Absicht: profilieren, testen, PRs parallel. Sie zeigt kein Ergebnis, das Sie in eine Folie kopieren sollten.
Zweites Bild: API-, Web- und Mobile-Repo anbinden, Ziel „den veralteten v1-Endpoint ablösen“. Claude legt je Repo einen Thread an, migriert die Aufrufer, lässt Tests laufen, öffnet Pull Requests und sagt Ihnen, welche zuerst gemergt werden müssen. Thread je Repo ist die saubere Variante der Personifikation: drei Wohnungen, nicht drei Leute in derselben Kommode. Trotzdem können gemeinsame Verträge — ein Schema, ein Client, ein Fehlercode — in mehreren Repos liegen. Dann ist die Überlappung wieder ein Merge-Thema, nur über Repo-Grenzen hinweg, plus die Reihenfolge, die der Coordinator Ihnen nennen soll.
Ich mag das zweite Bild mehr, weil die Schnitte sichtbar sind. Repo-Grenzen sind echte Grenzen. Das erste Bild, Latenz über Endpoints, ist genau die Sorte Auftrag, bei der zwei Threads dieselbe Utility anfassen und Sie am Ende den Konflikt lesen statt einer schnelleren Kasse. Beides sind Beispiele. Keines ist ein Versprechen, dass Ihr Checkout oder Ihr v1-Umzug so ausgeht.
Was sich daraus stehlen lässt, ohne Zahlen zu klauen: Schneiden Sie das Ziel so, dass die Threads möglichst nicht dieselbe Datei wollen. Sagen Sie die Merge-Reihenfolge, wenn Sie sie schon kennen, statt sie hinterher als Überraschung zu kassieren. Und behandeln Sie „Tests laufen lassen“ als Anspruch der Ankündigung, nicht als grünen Haken, den ich gesehen hätte.
Dokumente sind der ruhigere Zwilling. Ohne Repo, dafür mit Texten: der Thread liest und entwirft. Gleiche Büroleitung, anderes Lieferstück. Auch hier schreibt das Gedächtnis mit. „Tonfall so, Export raus, Freitag ist der Termin“ wirkt auf den Entwurf, den der nächste Thread baut. Wieder praktisch. Wieder der Ort, an dem ein schiefer Satz mehrere Entwürfe gleichzeitig färbt.
Coordinator jetzt — oder beim einen Chat bleiben?
Die Kernfrage, ohne Trommel: Coordinator mit parallelen Cloud-Threads jetzt, oder bei einem Chat bleiben, bis Limit und lokale Werkzeuge klar sind?
Ich würde den Coordinator anlassen, wenn alle diese Sätze stimmen. Sie sind in der Beta, also ausgewählt, Pro oder Max, Cloud-Sessions in Claude Code, und Sie haben keine bestehenden Projekte in Web oder Desktop, die Sie in der ersten Welle ausschließen. Ihr Ziel hat mehr als einen Teil und überlebt eine einzelne Antwort. Die Schnitte zwischen den Threads sind Ihnen vor dem Start klar, nicht erst beim Konflikt. Sie schauen auf die projektbezogene Usage, bevor Sie den nächsten Thread feiern. Modell und Effort sind eine bewusste Wahl, keine Default-Hoffnung. Und der Code darf in der Cloud laufen. Wenn eine dieser Zeilen wackelt, wackelt der ganze Plan.
Ich würde warten, wenn eine dieser Zeilen stimmt. Die Beta zeigt sich bei Ihnen nicht, die Warteliste ist Ihr einziger Knopf. Sie brauchen Team oder Enterprise, und dort heißt es noch danach. Sie brauchen den Lauf auf der eigenen Maschine, mit lokalen Werkzeugen, hinter dem eigenen Netz — angekündigt als very soon, ohne Datum. Ihr Limit ist schon dünn, und ein einzelner Chat bringt die Aufgabe zu Ende. Oder Ihr Brief ist noch wacklig, und Sie wissen, dass das Gedächtnis Wackliges an mehrere Branches gleichzeitig verfüttert. Warten ist dann der nüchterne Schritt, nicht die Angst vor dem Neuen.
Dazwischen liegt ein schmaler Streifen. Ziel formulieren, bevor der Zugang da ist. Tabus aufschreiben. Merge-Reihenfolge für den v1-Fall skizzieren, falls Sie so einen Fall haben. Check-in-Wunsch festlegen. Das ist Vorbereitung, keine Session. Sie verbrennt kein Limit. Sie macht den ersten echten Lauf kürzer im Irrtum, nicht automatisch billiger. Billiger behaupte ich nicht.
Ehrlich gesagt: Der Traum, nicht mehr alles selbst zu mergen, ist berechtigt. Drei Repos, ein veralteter Endpoint, ein Mensch, der die Diffs hinterher allein liest — das ist ein schlechter Freitag. Ein Coordinator, der Threads je Repo schickt und die Reihenfolge nennt, ist die richtige Form von Faulheit. Faulheit mit Kassenbon. Wer die Form nimmt und den Bon ignoriert, steht da wie ich in der Eingangsszene. Drei Fleißige, null Zusammenbau, Limit alle.
Wer parallel schaut, wie ein Agent Mode den nächsten Edit vorschlägt, sieht den Kontrast in einem Satz. Dort ein Vorschlag im Editor, den Sie annehmen oder liegen lassen. Hier eine Büroleitung, die mehrere Cloud-Sessions beschäftigt, während Sie das Telefon in der Tasche haben. Beides kann Code bewegen. Nur eines schickt von sich aus mehrere volle Sessions los, sobald das Ziel groß genug klingt.
Für den Alltag merke ich mir fünf Fragen, bevor ich „parallel“ tippe:
- Ist das Ziel ein Teil oder mehrere — und überleben die Teile eine Antwort?
- Welche Datei darf nur ein Thread anfassen?
- Was muss ins Gedächtnis, und was darf auf keinen Fall falsch dort landen?
- Welches Modell, welcher Effort, welche Check-in-Frequenz?
- Was sagt die projektbezogene Usage, bevor der nächste Thread aufgeht?
Fünf Fragen sind kein Framework-Poster. Es sind die Fragen, die der Eingangs-Fail nicht gestellt hat. Hätte ich die Datei-Frage gestellt, wären zwei Threads nicht in derselben Funktion gelandet. Hätte ich die Usage-Frage gestellt, wäre der dritte Thread vielleicht ein einzelner Chat geblieben. Hinterher ist die Hausordnung billig. Vorher ist sie der einzige Hebel ohne erfundene Prozentzahl.
Was bleibt? Claude Code Projects ist in der Beta eine Unterhaltung mit Coordinator, nicht mehr nur ein Ordner. Threads sind volle Cloud-Sessions, eigene Branches, eigene Repo-Kopien, Merge-Konflikt bei Überlappung, Shared Memory und Artifact Library als gemeinsame Tafel und gemeinsames Regal. Steuern geht aus dem Projekt-Chat, aus dem Thread, vom Telefon; die Arbeit läuft weiter, wenn Sie gehen. Ausgewählt Pro und Max, mit den Gates, die der Blog nennt. Team und Enterprise später. Lokal very soon, ohne Datum. Der Punkt ist: Der Traum, nicht mehr alles selbst zu mergen, ist real beschrieben. Bezahlt wird er in Sessions. Wer das Limit nicht beobachten will oder den Zugang nicht hat, bleibt beim einen Chat. Wer den Coordinator schickt, schreibt den ersten Satz so, als hinge daran mehr als ein Thread — weil genau das passiert.

