Claude Code Projects ausprobiert: Stärken und Fallstricke paralleler Threads, gelernt beim Bau einer ganzen Website

Mit Projects in Claude Code teilt Claude Ihre Arbeit innerhalb eines einzigen Gesprächs in Threads auf und lässt sie parallel in der Cloud laufen. Wie das funktioniert und wer es nutzen kann, habe ich in Was Claude Code Projects ist zusammengefasst. Dieser Artikel ist die Fortsetzung: das Protokoll eines echten Versuchs, eine komplette Website damit bauen zu lassen.

Ausprobiert habe ich es vom 26. bis 28. September 2026, als Projects noch in der öffentlichen Beta war (schrittweise für Pro und Max freigeschaltet; siehe die offizielle Dokumentation). Oberfläche und Verhalten können sich noch ändern. Was folgt, ist das, was damals tatsächlich passiert ist, mit Zahlen, die ich an der Oberfläche, am Nutzungsbericht und an der Historie des Repositorys überprüft habe.

In einem Satz: Die Entwicklung kommt erstaunlich gut voran, auch wenn man kaum hinschaut. Heraus kommt aber ein Entwurf und kein fertiges Produkt, und beim Deployment auf einen Server, der nur per SSH erreichbar ist, geht es nicht weiter. Im Folgenden beschreibe ich Gutes wie Schlechtes in der Reihenfolge, in der es passiert ist.

1. Was ich bauen ließ: die Ausgangslage und ein Geständnis vorab

Das Thema war eine Datenbank-Website, auf der man nachschlagen kann, wie viel Speicher lokale LLMs brauchen. Um die Frage „Läuft dieses Modell auf meinem Rechner?“ zu beantworten, sammelt sie die Dateigrößen quantisierter Modelle von Hugging Face, berechnet den Speicherbedarf für jede Kontextlänge und erlaubt die umgekehrte Suche ausgehend vom Speicher Ihrer GPU oder Ihres Mac. Das Projekt ist nicht zu klein und zerfällt von selbst in Teile, die parallel laufen können (Datensammlung, Berechnung, Seiten, umgekehrte Suche, SEO). Damit eignete es sich gut als Testfeld für Projects.

2. Der Einstieg und die fünf Stellen, an denen ich gestolpert bin

Die Schritte selbst sind kurz: Im Code-Tab der Desktop-App wählen Sie Projects → New, geben einen Namen, ein Ziel und ein Repository ein und legen das Projekt an. Rund um diese Schritte bin ich allerdings an den folgenden fünf Stellen gestolpert.

Zu ②: Direkt nach dem Anlegen zeigte das Gespräch den Hinweis „Up to $100 of initial usage, including the automatic setup, won't count towards your usage limits“. Das heißt: Die erste Nutzung im Wert von bis zu $100 wird nicht auf Ihr normales Kontingent angerechnet. Auch der Nutzungsbildschirm führte das als „Projekt-Setup-Guthaben“ (noch etwa 24 Stunden bis zum Ablauf). Stand 28. September wird diese Vergünstigung auf der Projects-Seite der offiziellen Dokumentation nicht erwähnt. In Abschnitt 6 zeige ich, wie schnell sie tatsächlich aufgebraucht war.

Verlaufen habe ich mich in den Umgebungseinstellungen, als ich eine bestehende Umgebung bearbeiten wollte. Über „Add cloud environment“ (Umgebung hinzufügen) landet man auf dem Bildschirm für eine neue Umgebung, und anfangs habe ich die freigegebenen Domains in das Feld für das Setup-Skript getippt. Eine bestehende Umgebung bearbeiten Sie, indem Sie in der Liste mit der Maus darüberfahren und auf das Zahnrad klicken, das dann erscheint (genau so steht es in der offiziellen Dokumentation, aber allein an der Oberfläche ist das schwer zu entdecken).

3. Rund 20 Stunden Protokoll: was passierte, während ich schlief

Hier der Ablauf vom Anlegen (gegen 22 Uhr am 26. September) bis zum Merge des letzten PR (gegen 17:30 Uhr am nächsten Tag, dem 27.). Alle Uhrzeiten sind japanische Zeit (JST).

Eine Sache, die nicht gut lief, gehört ebenfalls hierher. Beim Aufbau des Fundaments für die Datensammlung rief ein Thread die API von Hugging Face 520-mal hintereinander auf, um herauszufinden, wie die Ratenbegrenzung des externen Dienstes funktioniert. Der Review-Thread stufte das als „nicht angemessen“ ein und hielt Regeln für die Nutzung externer APIs schriftlich fest, woraufhin der spätere Datensammlungs-Thread über seine gesamte Laufzeit nur 8 Anfragen stellte. Sich selbst überlassen, denkt es nicht von allein an die Last, die es bei fremden Diensten erzeugt. Es lohnt sich, das in die Anweisungen zu schreiben.

4. Jeden Schritt freigeben oder die Arbeit übergeben

Wie in Abschnitt 1 erwähnt, lief die erste Hälfte mit Anweisungen, die an jeder Stelle eine menschliche Freigabe verlangten, und am 27. um 17 Uhr habe ich sie so umgeschrieben, dass ich die Arbeit übergab. Das Verhalten änderte sich deutlich.

Beim Übergeben gab es zwei Dinge zu beachten. Erstens: Umgeschriebene Anweisungen erreichen Threads nicht, die bereits laufen. Der Koordinator erklärte selbst: „Dieser Thread wurde gestartet, bevor die Anweisungen umgeschrieben wurden, deshalb sieht er die neuen Anweisungen nicht.“ Zweitens: Die Threads konnten alte Regeln im Speicher des Projekts nicht löschen. Ein Versuch, eine alte Notiz „Nur ein Mensch mergt“ umzuschreiben, wurde von einer Sicherheitsprüfung gestoppt. Alte Notizen muss ein Mensch in den Einstellungen unter „Memory“ (Speicher) löschen.

Das Gerüst der Anweisungen, bei dem ich schließlich landete, sieht so aus.

Dieses Projekt baut und betreibt [Ihre Website].
Das Vorgehen liegt bei dir: Der Koordinator entscheidet, welche Threads er startet, wie viele, mit welchen Modellen und in welcher Reihenfolge.
PRs darfst du mergen, sobald die CI grün ist. Konflikte löst du selbst.

Frag einen Menschen nur in diesen Fällen:
- Alles, was Geld kostet (kostenpflichtige APIs, kostenpflichtige Dienste)
- Alles, was Geheimnisse braucht (API-Schlüssel, Passwörter)
- Deployment in die Produktion oder Änderungen an Produktionsdaten
- Entscheidungen, bei denen die Wege auseinandergehen und beide vertretbar sind
- Alles, was du brauchst, aber nicht erreichst (Lücken nicht mit Vermutungen oder Dummy-Daten füllen)

Halte die Ratenbegrenzungen externer APIs ein und frage sie nicht massenhaft zu Testzwecken ab.

Mit dem, was ich danach gelernt habe, empfehle ich allerdings, „Änderungen an der CI-Konfiguration und an Deployment-Skripten braucht die Freigabe eines Menschen“ zu ergänzen. Threads, denen man die Arbeit übergeben hat, können auch die CI-Konfiguration ändern, und zusammen mit einem Deployment-Mechanismus entsteht so ein Weg, auf dem Änderungen ungeprüft bis in die Produktion gelangen (Abschnitt 7).

5. Die Qualität nach dem Livegang: Alle Tests waren grün

Was das Projekt gebaut hatte, übergab ich meinem gewohnten lokalen Claude Code und brachte es in die Produktion. Mein erster Eindruck direkt nach dem Livegang: „Irgendwie … unspektakulär.“ Es gab keine einzige Modellseite. Als ich der Ursache nachging, zeigte sich eine Lücke, wie sie typisch für parallele Entwicklung ist.

Zehn Threads, weit über hundert Tests, Reviews mit Opus und die CI: Keines davon fand diese Lücke, denn jeder Thread hatte innerhalb seiner eigenen Zuständigkeit recht. Ohne eine Rolle, die das Ganze von vorn bis hinten durchsieht, entstehen an den Grenzen zwischen den Aufgaben Lücken.

Mit echten Daten zeigten sich noch zwei weitere Probleme.

• In den Quantisierungstabellen standen Dateien, die nicht zum eigentlichen Modell gehörten. Hilfsmodelle für spekulatives Dekodieren (MTP, EAGLE und ähnliche) sowie LoRA-Dateien wurden als Quantisierungen des Hauptmodells gezählt, sodass die Tabelle eines 12B-Modells mit der Zeile „Q8_0 0,47 GB“ begann (das echte Q8_0 hat 12,7 GB). Nach der Korrektur wurden 195 Dateien aus 56 Repositorys als Hilfsdateien eingestuft.
• Bei den neuesten, am stärksten gefragten Modellen stand beim Speicherbedarf „nicht berechenbar“. Die ursprüngliche Formel unterstützte Architekturen neuerer Generationen nicht (etwa solche, bei denen verschiedene Schichten ihren Speicher unterschiedlich halten). Das wichtigste Verkaufsargument der Website fehlte also genau auf den meistbesuchten Seiten.

Beides kam erst ans Licht, als echte Daten in der Produktion landeten, weil die Tests vollständig auf Beispieldaten aufbauten. Was ich mit dem lokalen Claude Code korrigiert habe und wie lange es dauerte (28. September, 17:21 bis 22:54 Uhr, 13 Commits):

Es gab aber auch klare Pluspunkte. Die Seiten waren schnell (bei den wichtigsten etwa 0,1 Sekunden), die Dateigrößen waren die tatsächlichen Werte von Hugging Face, und der Speicherbedarf der unterstützten Modelle stimmte mit der Formel überein. SEO-Arbeit wie Titel, strukturierte Daten, die Sitemap und llms.txt war von Anfang an eingebaut. Mein Gesamturteil: Gerüst und Details waren gut gemacht; was fehlte, waren die „Nahtstellen“ zwischen den Teilen und echte Daten.

6. Verbrauch und Kosten: wohin 191,8 Mio. Tokens flossen

Der Bildschirm „Usage“ in den Projekteinstellungen zeigt die Tokens nach Thread und nach Modell. Über eine Schaltfläche oben rechts lässt sich alles als Text kopieren. Der Bericht vom 27. September um 11:47 Uhr sah so aus.

190 Millionen klingt nach viel, doch 97,7 % davon waren Cache-Lesezugriffe. Ein Thread liest bei jeder Aktion das bisherige Gespräch neu ein, und wenn ein einzelner Thread Hunderte Aktionen ausführt, ergibt sich genau dieses Bild. Der Koordinator kam nur auf 2 %, der Verwaltungsaufwand war also gering.

Zum Vergleich habe ich „gelesene Tokens ÷ ausgegebene Tokens“ dem lokalen Claude Code gegenübergestellt (die letzten drei Tage auf meinem eigenen PC): etwa 330 beim Projekt und etwa 340 lokal. Der Verbrauch pro Arbeitseinheit lag also ungefähr auf dem Niveau einer lokalen Session. Dass sich Projects schwerer anfühlt, liegt vermutlich daran, dass alles gleichzeitig parallel läuft und der Verbrauch deshalb in kurzer Zeit geballt anfällt (die Arbeit selbst war unterschiedlich, der Vergleich ist also nur ein Anhaltspunkt).

Auf der Kostenseite konnte ich verfolgen, wie das Setup-Guthaben ($100) schrumpfte.

Das Guthaben verhielt sich weitgehend wie ein Dollarbetrag, der zu API-Preisen gezählt wird. Rechnet man den Bericht von 11:47 Uhr mit den offiziellen Preisen von Anthropic (Pricing: Sonnet 5 mit $2 Eingabe, $10 Ausgabe und $0.20 Cache-Lesen; Opus 5.5 mit $4 Eingabe, $20 Ausgabe und $0.20 Cache-Lesen, jeweils pro Million Tokens), kommt man auf etwa $58–65, was grob zur damaligen Anzeige passt (78 % = $78). „Im Wert von $100“ bedeutet also die Menge, die über die API $100 kosten würde, und das ist im Rahmen eines Max-Pauschaltarifs nicht besonders viel. Ein separat ausgegebenes Guthaben für Cloud-Sessions ($250 bei Max) trug auf seinem Einlösebildschirm den Hinweis „Projekte sind ausgenommen“, und tatsächlich wurde davon kein einziger Dollar verbraucht.

7. Warum das Deployment in die Produktion hakte

Am mühsamsten war es, das Gebaute in die Produktion zu bringen, denn das Ziel war Shared Hosting, das nur per SSH erreichbar ist.

• Cloud-Threads erreichen den Produktionsserver nicht (der SSH-Schlüssel liegt nur auf meinem lokalen PC).
• Um auf dem lokalen PC zu arbeiten, nutzen Sie die Projektoption „Work locally“ (lokal arbeiten). Dahinter steckt Remote Control, und dafür muss in der Desktop-App „Use this computer from your phone and claude.ai“ (diesen Computer vom Smartphone und von claude.ai aus nutzen) eingeschaltet sein.
• Diese Einstellung gilt allerdings für die Liste aller Ordner, die Sie bisher in Claude Code geöffnet haben, und diese wird automatisch zusammengetragen. In meiner Umgebung waren es 22, darunter ein übergeordneter Ordner mit Dutzenden Projekten darin. Solange die Einstellung an ist, kann in all diesen Ordnern aus der Ferne Arbeit gestartet werden, und Ordnernamen, Pfade und Repository-URLs werden ebenfalls an Anthropic gesendet. Um das auf einen einzigen Ordner zu beschränken, braucht es einen anderen Weg: in diesem Ordner ein Terminal öffnen und claude remote-control starten.

Also habe ich mehrere Wege für das Deployment abgewogen.

Am Ende habe ich das Projekt archiviert und das Gebaute in meinen gewohnten lokalen Arbeitsablauf mit Claude Code übernommen. Es auf dieselbe Deployment-Kette zu setzen wie meine anderen Websites, hielt ich für sicherer, als einen neuen Mechanismus hinzuzufügen.

Rückblickend ist es wohl besser, Projects als etwas zu betrachten, das für Hosting gedacht ist, das beim Merge auf GitHub automatisch deployt. Bei Vercel zum Beispiel genügt die Verbindung mit GitHub, damit Änderungen bis in die Produktion durchlaufen, und eine Sackgasse wie meine entsteht gar nicht erst. Allerdings ist der kostenlose Hobby-Tarif von Vercel auf nicht kommerzielle Nutzung beschränkt, und wer Werbung wie Google AdSense schalten will, braucht den kostenpflichtigen Pro-Tarif (ab $20 im Monat) (Fair Use Guidelines). Zu einer PHP- und MySQL-Website wie dieser passt Vercel außerdem schlecht. Entscheidend ist, Technik und Hosting von Anfang an gemeinsam festzulegen.

Welche Risiken es birgt, den eigenen PC aus der Ferne steuern zu lassen, und wie sich das vom gewohnten Claude Code unterscheidet, möchte ich in einem eigenen Artikel ausführlich behandeln. Wie Sie eine lokale Session vom Smartphone aus bedienen, zeigt der Artikel zu Remote Control.

8. Wofür es sich eignet und wofür nicht

Aus dieser Erfahrung heraus würde ich vor dem Start Folgendes prüfen.

• Hosting: Wird beim Merge auf GitHub automatisch deployt? Wenn SSH nötig ist, vorab etwa festlegen, dass sich der Server den Stand selbst holt.
• GitHub-Berechtigungen: die Reichweite der Installation der Claude GitHub App. Ein eigenes Konto verwenden oder die Repositorys einschränken.
• Wie viel Sie übergeben: In den Projektanweisungen nur aufführen, was einem Menschen vorgelegt werden soll. Änderungen an CI- und Deployment-Konfiguration freigabepflichtig machen.
• Netzwerk: Wenn Sie externe APIs oder Websites nutzen, sowohl die Hauptdomain als auch ihre Subdomains auf die Freigabeliste setzen.
• Prüfung mit echten Daten: Sich nicht darauf verlassen, dass die Tests mit Beispieldaten grün sind. Zum Schluss einen Thread starten, dessen Aufgabe es ist, produktionsnahe Daten von vorn bis hinten durchlaufen zu lassen und sich das Ergebnis anzusehen.
• Kontingent: das voreingestellte Modell der Threads prüfen. In den ersten 24 Stunden gibt es ein Setup-Guthaben von $100.

Fazit

Projects nimmt einem tatsächlich die Arbeit ab, Aufgaben zu verteilen, ihnen hinterherzulaufen und denselben Hintergrund immer wieder zu erklären. Über Nacht liefen drei Aufgaben parallel, die Threads stimmten sich untereinander ab, und nach der Übergabe traf es seine Entscheidungen über Merges und die nächsten Schritte selbst. Der Tokenverbrauch pro Arbeitseinheit unterschied sich nicht vom lokalen Claude Code.

Andererseits ist das Ergebnis ein Entwurf. Wer Arbeit parallel aufteilt, reißt Lücken an den Grenzen zwischen den Zuständigkeiten. Alle Tests mit Beispieldaten können grün sein, und echte Daten decken trotzdem Fehler auf. Und mit Servern, die nur per SSH erreichbar sind, verträgt es sich schlecht. Wenn Sie es nutzen, ersparen Ihnen drei Dinge meine Umwege: ein Hosting mit GitHub-Anbindung wählen, zu Beginn schriftlich festlegen, wie viel Sie übergeben, und zum Schluss einen Thread starten, dessen Aufgabe es ist, alles von vorn bis hinten mit echten Daten zu prüfen.

FAQ

F. Was kostet Projects?

A. Es gibt keine eigene Gebühr; es zehrt am normalen Kontingent von Pro oder Max. Zusätzlich gab es diesmal ein „Setup-Guthaben“, mit dem bis zu $100 an Nutzung in etwa den ersten 24 Stunden nicht auf das Kontingent angerechnet wurden (so auf dem Bildschirm angezeigt; Stand 28. September nicht in der offiziellen Dokumentation). Die Arbeit mit 10 Threads und 11 PRs verbrauchte rund 190 Millionen Tokens und damit das gesamte Guthaben. Zu API-Preisen entspricht das etwa $100.

F. Geht es wirklich weiter, wenn ich den Laptop zuklappe?

A. Ja. Threads in der Cloud liefen weiter, ob ich den PC zuklappte oder in den Ruhezustand schickte. In diesem Versuch wurden in etwa 7 Stunden über Nacht drei Aufgaben fertig. Threads, die Sie mit „Work locally“ auf Ihrem eigenen PC starten, laufen dagegen nur, solange der PC wach ist.

F. Kann ich es mit Repositorys außerhalb von GitHub nutzen?

A. Threads, die mit Code arbeiten, setzen ein Repository auf github.com mit installierter Claude GitHub App voraus. Ich hatte dieses Projekt auf meinem eigenen Git-Server verwaltet, also habe ich ein GitHub-Konto nur für Claude angelegt, dort begonnen und am Ende alles wieder in meine lokale Umgebung zurückgeholt.

F. Was passiert, wenn ich die Projektanweisungen mittendrin ändere?

A. Beim Koordinator kommen sie sofort an, und seine Arbeitsweise änderte sich, ohne dass ich etwas sagen musste. Threads, die bereits laufen, erreichen sie jedoch nicht; lassen Sie die Arbeit bei Bedarf in einem neuen Thread fortsetzen. Alte Regeln im Speicher des Projekts musste ein Mensch in den Einstellungen löschen.

F. Ist „Work locally“ sicher?

A. Der einzige Datenverkehr ist eine verschlüsselte ausgehende Verbindung von Ihrem PC; es wird kein Port geöffnet, der Verbindungen annimmt. Wenn Sie die Einstellung in der Desktop-App einschalten, kann jedoch in allen Ordnern aus der Liste, die aus Ihrem Nutzungsverlauf zusammengetragen wird (bei mir 22, einschließlich Dutzender Projekte in einem übergeordneten Ordner), aus der Ferne Arbeit gestartet werden. Nötig sind Gewohnheiten wie: die Einstellung nur während der Nutzung einschalten und sicherstellen, dass das Konto, mit dem Sie sich anmelden, eine Zwei-Faktor-Authentifizierung hat.

F. Kann ich das Gebaute so verwenden, wie es ist?

A. In meinem Fall nicht. Gerüst und SEO-Arbeit waren gut gemacht, aber die Logik an den Grenzen zwischen den Zuständigkeiten fehlte komplett, und es gab Fehler, die erst mit echten Daten auftraten. Vor dem Livegang braucht es einen Schritt, in dem echte Daten eingespielt werden und das Ganze von vorn bis hinten geprüft wird.