Wie stellt man Cloud-Sitzungen in Claude Code Projects wieder her? Kapazitätsplanung 2026

Dieser Leitfaden richtet sich an Entwickler und kleine Teams, die Claude Code Projects für lange oder parallele Aufgaben einsetzen. Wir trennen Sitzungszustände, Projektdateien, Agent-Threads, Build-Artefakte und Wiederherstellungsreserven und leiten daraus eine belastbare Kapazitätsplanung für 2026 ab.

Eine offizielle Projects-Anleitung trennt drei verwaltbare Bereiche: Projektwissen, Anweisungen und Gespräche. Die Dokumentation zum Erstellen und Verwalten von Projects macht damit indirekt klar, warum die Wiederherstellung von Cloud-Sitzungen in Claude Code Projects nicht mit dem bloßen Zählen von Chats erledigt ist.

Geeignet: Für lange Aufgaben, parallele Agenten und Teams, die nach einer Unterbrechung ohne Datenverlust weiterarbeiten müssen.

Nicht geeignet: Für kurze Einzelaufgaben ohne dauerhafte Dateien und ohne Wiederaufnahmebedarf; dafür genügt häufig eine lokale oder leichte Umgebung.

Wir planen Kapazität deshalb nicht nach der Zahl der Agenten allein. Maßgeblich sind aktive Sitzungen, wartende Tool-Aufrufe, parallele Threads, Projektdateien, Kontext, Build-Artefakte und eine getrennte Reserve für Fehler und Wiederherstellung. Wenn ein lokales Gerät regelmäßig schläft oder die Netzwerkverbindung verliert, ist ein dauerhaftes Cloud-Arbeitsplatzmodell die verlässlichere Wahl.

Dieser Beitrag richtet sich an:

• Entwickler, die lange Claude-Code-Aufgaben trotz lokaler Ruhephasen oder Verbindungsabbrüchen fortsetzen müssen;
• Verantwortliche kleiner Teams, die mehrere Agenten am selben Codebestand arbeiten lassen;
• Administratoren, die Cloud-Mac- oder Remote-Entwicklungsarbeitsplätze, Berechtigungen und Wiederherstellung planen.

Kapazität nach Aufgabentyp

Eine kurze Codeänderung, ein langer Testlauf und ein paralleler Refactoring-Auftrag belasten den Arbeitsplatz auf unterschiedliche Weise. Die Sitzungsanzahl ist daher nur ein Eingangswert.

Für eine erste Schätzung erfassen wir pro Aufgabentyp diese Variablen:

• S = gleichzeitig aktive Sitzungen;
• T = parallele Tool- oder Agent-Threads je Sitzung;
• D = Größe der Projektdateien einschließlich lokaler Metadaten;
• C = Kontext, Protokolle und gespeicherte Gesprächsdaten;
• A = temporäre und dauerhaft aufzubewahrende Artefakte;
• B = zusätzliche Last durch Build, Test, Linting oder Datenbankprozesse;
• R = Wiederherstellungsreserve für Abbrüche, Rollbacks und erneute Läufe.

Eine einfache Planungsformel lautet:

Gesamtbedarf = Basis-Arbeitsbereich + S × (D + C + A) + B + R

Diese Formel ist kein Anbieterlimit. Sie verhindert vielmehr, dass ein Team die falsche Größe optimiert. Werden Projektdateien für jeden Agenten kopiert, wächst der Speicherbedarf anders als bei gemeinsam genutzten, schreibgeschützten Abhängigkeiten. Werden Build-Ausgaben lange behalten, kann der Artefaktspeicher stärker wachsen als der Quellcode.

Die Bewertung beschreibt nicht die Leistung eines bestimmten Angebots. Sie zeigt, wie hoch das Fehlerrisiko einer Betriebsart ohne passende Kapazitätsreserve ist. Ein Team sollte also nicht automatisch die höchste Parallelität wählen. Wenn Agenten dieselben Dateien ändern, kann weniger Parallelität schneller zum stabilen Commit führen.

Sitzungszustände und Wiederaufnahme

Wie lassen sich Claude Code Projects Sitzungen nach einer Unterbrechung fortsetzen? Zuerst muss die Sitzung einem Zustand zugeordnet werden. „Nicht sichtbar“ bedeutet nicht automatisch „verloren“. Wir unterscheiden aktive, wartende, angehaltene und abgeschlossene Sitzungen.

Eine aktive Sitzung verarbeitet gerade Eingaben oder führt Werkzeuge aus. Eine wartende Sitzung wartet beispielsweise auf einen Prozess, eine Netzwerkantwort oder einen Build. Eine angehaltene Sitzung ist nicht beendet, benötigt aber eine bewusste Wiederaufnahme. Eine abgeschlossene Sitzung erzeugt möglicherweise noch wertvolle Protokolle, Diff-Dateien, Testergebnisse oder Gesprächskontext, die für einen späteren Auftrag erhalten bleiben müssen.

Für jede Sitzung sollte die Verwaltung mindestens diese Felder führen:

1. eindeutige Sitzungskennung;
2. zugehöriges Project und Repository;
3. verantwortlicher Agent oder Teammitglied;
4. letzter bestätigter Commit;
5. Status des Arbeitsverzeichnisses;
6. laufender Tool- oder Build-Prozess;
7. benötigte externe Dienste;
8. Wiederaufnahmeaktion und zuständige Person.

Die offizielle Beschreibung von Projects bestätigt die Verbindung von Projektdateien, Anweisungen, Wissen und Gesprächen. Die Anleitung zum Organisieren von Aufgaben mit Projects ist deshalb als Funktionsbeschreibung wichtig, ersetzt aber keine Kapazitätsmessung des eigenen Arbeitsplatzes.

Die Kapazitätstabelle muss den Peak erfassen, nicht nur den Tagesdurchschnitt. Drei kurze Aufgaben am Vormittag können weniger Ressourcen benötigen als ein einziger paralleler Testlauf mit großen Logs. Zusätzlich reservieren wir einen eigenen Anteil für fehlgeschlagene Wiederholungen. Ohne diese Reserve wird ein Fehler genau dann zum Kapazitätsproblem, wenn das Team ihn beheben möchte.

Wiederaufnahme ohne Doppelarbeit

Bei einer Unterbrechung prüfen wir nicht nur, ob die Oberfläche die alte Sitzung zeigt. Wir prüfen, ob der technische Zustand noch stimmt:

• Ist der letzte Commit bekannt?
• Sind nicht committete Änderungen gesichert?
• Wurde ein Prozess beendet oder läuft er noch?
• Sind erzeugte Dateien vollständig?
• Sind Zugangsdaten oder Tokens noch gültig?
• Hat ein externer Dienst den Auftrag bereits angenommen?
• Ist ein erneuter Tool-Aufruf idempotent?

Für lokale Änderungen bietet die offizielle Git-Dokumentation zu git stash einen dokumentierten Mechanismus, um Arbeitsänderungen zwischenzulagern. Das ist kein Ersatz für Commits und keine vollständige Sitzungssicherung. Es kann jedoch verhindern, dass ein Neustart ungesicherte Änderungen überschreibt.

Arbeitsbereich, Dateien und gemeinsamer Kontext

Projects-Dateien, geteiltes Wissen und Gesprächskontext gehören logisch zusammen, sind physisch aber nicht zwingend derselbe Speicherbereich. Diese Unterscheidung ist für die Kapazitätsplanung entscheidend.

Wir rechnen mindestens fünf Gruppen getrennt:

• Repository: Quellcode, Konfiguration, Tests und Dokumentation;
• Abhängigkeiten: Paketmanager-Caches, virtuelle Umgebungen, SDKs und Containerdaten;
• Generierte Dateien: Build-Ausgaben, Bundles, Datenbankmigrationen und Testdaten;
• Diagnosedaten: Logs, Screenshots, Traces und Fehlerberichte;
• Agent-Arbeitsbereiche: temporäre Dateien, Patch-Vorschläge und Zwischenstände.

Gemeinsam genutzte, schreibgeschützte Abhängigkeiten können Duplikate vermeiden. Sie sparen aber nur dann tatsächlich Speicher, wenn die Infrastruktur keine vollständige Kopie pro Agent anlegt. Ein logischer gemeinsamer Workspace ist daher nicht automatisch eine physische Speicherteilung.

Bei paralleler Entwicklung kommen Branches und Worktrees hinzu. Git beschreibt git worktree als Möglichkeit, mehrere Arbeitsbäume aus einem Repository zu verwalten. Das kann Dateien voneinander isolieren, vervielfacht aber je nach Struktur große generierte Verzeichnisse, lokale Builds oder Abhängigkeiten. Vor der Entscheidung messen wir daher:

• Größe des reinen Quellcodes;
• Größe der installierten Abhängigkeiten;
• Größe eines frischen Builds;
• Größe eines vollständigen Testlaufs;
• Wachstum der Logs je Auftrag;
• Zahl der gleichzeitig benötigten Arbeitsbäume.

Wie beeinflussen Projektdateien und gemeinsamer Speicher die benötigte Kapazität? Dateien, die nur als Referenz dienen, belasten den Arbeitsplatz anders als Dateien, die jeder Agent verändert. Gemeinsame Anweisungen und Erinnerungen erhöhen vor allem den organisatorischen Kontext. Kopierte Repositories, parallele Build-Verzeichnisse und gespeicherte Artefakte erhöhen dagegen den physischen Bedarf. Wir behandeln deshalb „Memory“ nicht als Synonym für Arbeitsspeicher: Gesprächskontext, Projekterinnerung und RAM sind drei verschiedene Größen.

Container verschärfen diese Trennung. Die Docker-Dokumentation zu persistenten Volumes erklärt, dass Anwendungsdaten außerhalb des flüchtigen Container-Layers gespeichert werden können. Für die Planung heißt das: Ein Container-Neustart kann sicher sein, wenn die relevanten Daten in einem korrekt gesicherten Volume liegen. Ein Volume ist aber noch kein Backup. Snapshot, Aufbewahrungsdauer und Wiederherstellungstest müssen separat geplant werden.

Parallelität, Builds und Warteschlangen

Wie viel Cloud-Arbeitsplatz braucht Claude Code für mehrere parallele Agenten? Wir geben dafür keine pauschale Agent-Zahl an. Ohne Messwerte zu Codebasis, Tools, Build-Prozess und Artefakten wäre eine solche Zahl irreführend. Stattdessen ordnen wir die Arbeitsweise in drei Betriebsmodi ein.

Bei serieller Ausführung bearbeitet ein Agent eine Aufgabe, bevor die nächste startet. CPU und Arbeitsspeicher sind meist leichter vorhersehbar. Die Wartezeit kann jedoch steigen, wenn ein Agent oft auf externe Werkzeuge oder lange Tests wartet.

Bei begrenzter Parallelität laufen nur voneinander unabhängige Aufgaben gleichzeitig. Ein Agent kann beispielsweise Dokumentation vorbereiten, während ein anderer einen isolierten Test untersucht. Der Engpass entsteht oft bei Datenträgerzugriffen und gemeinsamen Diensten, nicht bei der Modellinteraktion.

Bei hoher Parallelität werden mehrere Agenten und Builds gleichzeitig gestartet. Dann müssen wir CPU-Auslastung, Arbeitsspeicher, Datenträger-I/O, Netzwerk und Prozesswarteschlange gemeinsam beobachten. Ein Arbeitsplatz kann noch freien Speicher besitzen, aber wegen I/O-Konkurrenz langsam oder wegen Arbeitsspeicherdruck instabil werden.

Für jeden Agenten erfassen wir daher nicht nur „läuft“ oder „läuft nicht“, sondern:

• maximale und typische CPU-Last;
• Arbeitsspeicher vor und während des Builds;
• Lesen und Schreiben auf dem Datenträger;
• Größe und Wachstum der Ausgaben;
• Netzwerkbedarf bei Downloads und externen APIs;
• Wartezeit in der Build- oder Testwarteschlange;
• Verhalten nach Abbruch und Neustart.

Die GitHub-Anleitung zur Aufbewahrung von Workflow-Artefakten zeigt einen wichtigen Grundsatz: Testergebnisse und Build-Ausgaben müssen bewusst als Artefakte behandelt werden. Werden sie unbegrenzt oder länger als nötig aufgehoben, wird die Kapazitätsplanung schleichend falsch. Die passende Gegenmaßnahme ist eine definierte Aufbewahrung und regelmäßige Bereinigung; die Dokumentation zum Entfernen von Workflow-Artefakten beschreibt diesen Teil der Verwaltung.

Ein sinnvoller Betriebswert ist die Peak-Parallelität: der höchste gleichzeitig laufende Mix aus Agenten, Tools, Builds und Tests. Der Tagesdurchschnitt gehört in die Auswertung, darf aber die Dimensionierung nicht ersetzen.

Wiederherstellungsreserve und Zustandsgrenzen

Eine stabile Wiederaufnahme besteht aus mehreren Zuständen, die nicht verwechselt werden dürfen:

• Sitzungszustand: Was die Unterhaltung und der Agent zuletzt wussten;
• Projektwissen: Dateien, Anweisungen und dauerhaft bereitgestellter Kontext;
• Git-Zustand: Commit, Branch, Worktree und nicht committete Änderungen;
• Build-Zustand: laufende Prozesse, temporäre Dateien und Testergebnisse;
• externer Zustand: Datenbanken, API-Aufträge, Queues, Tokens und Webhooks.

Fällt ein Arbeitsplatz aus, kann die Sitzung sichtbar zurückkehren, während ein externer Auftrag bereits abgeschlossen ist. Umgekehrt kann der Code gespeichert sein, während ein noch laufender Build abgebrochen wurde. Vor dem Wiederanlauf schreiben wir deshalb eine kurze Übergabenotiz: letzter Commit, bekannte Änderungen, ausgeführte Schritte, erwartetes Ergebnis und sichere nächste Aktion.

Für Cloud-Arbeitsplätze ist die Lebenszykluslogik ebenfalls relevant. Die Dokumentation zum Lebenszyklus von Codespaces unterscheidet unter anderem laufende und angehaltene Zustände. Die konkrete Plattform kann anders funktionieren, aber die Planungsfrage bleibt gleich: Welche Daten bleiben erhalten, wenn der Arbeitsplatz stoppt, und welche Prozesse müssen neu gestartet werden?

Sieben Schritte für eine belastbare Wiederherstellung

1. Peak erfassen: Für jede Woche den höchsten gleichzeitigen Mix aus Sitzungen, Agenten, Builds und Tests notieren.
2. Zustand markieren: Jede Aufgabe als aktiv, wartend, angehalten oder abgeschlossen mit Aufbewahrungspflicht kennzeichnen.
3. Repository sichern: Vor riskanten Agent-Aufrufen einen nachvollziehbaren Commit oder einen kontrollierten Zwischenstand anlegen.
4. Änderungen trennen: Für parallele Aufgaben Branches oder Worktrees verwenden und gemeinsame Schreibpfade vermeiden.
5. Artefakte klassifizieren: Logs, Screenshots, Testberichte und Build-Ausgaben nach Wiederherstellungswert und Aufbewahrungsdauer sortieren.
6. Externe Zustände prüfen: API-Aufträge, Datenbanken, Tokens und Webhooks vor einem erneuten Aufruf abgleichen.
7. Wiederherstellung testen: Einen absichtlich unterbrochenen Auftrag fortsetzen und prüfen, ob keine Aktion doppelt ausgeführt wird.

Für Timeout-Strategien ist die Dokumentation zu konfigurierbaren Codespaces-Zeitüberschreitungen ein nützlicher Vergleichspunkt. Ein Timeout ist kein Fehler, wenn vorher gespeichert, protokolliert und sauber beendet wurde. Es wird zum Fehler, wenn ein laufender Prozess ohne Übergabe abgebrochen wird.

Bei einem Mac-Arbeitsplatz prüfen wir zusätzlich die lokalen Energieeinstellungen. Apple beschreibt Einstellungen für Schlafen und Aufwachen auf dem Mac. Das ist besonders wichtig, wenn lokale Ausführung als Alternative zur Cloud betrachtet wird: Ein schlafender Rechner kann eine lange Agent-Aufgabe, einen SSH-Prozess oder einen Build unterbrechen, obwohl die Anwendung selbst korrekt konfiguriert war.

Entscheidungslogik für 2026

Wir verwenden folgende Rückfallregeln:

• Wenn nur eine kurze Interaktion ohne dauerhafte Dateien geplant ist, reicht lokal oder ein leichter Workspace.
• Wenn ein Auftrag über längere Zeit auf Tools, Builds oder externe Antworten wartet, wird Persistenz wichtiger als die reine Sitzungszahl.
• Wenn mehrere Agenten dieselben Dateien ändern, reduzieren wir zuerst die Parallelität oder isolieren die Arbeitsbereiche, bevor wir die Umgebung vergrößern.
• Wenn Artefakte über mehrere Tage benötigt werden, rechnen wir deren Aufbewahrung ausdrücklich in den Speicherbedarf ein.
• Wenn ein Fehlschlag ohne Doppelverarbeitung behoben werden muss, reservieren wir Platz und Zeit für Protokolle, Snapshots, Wiederholungen und manuelle Übernahme.
• Wenn lokale Geräte schlafen, neu starten oder häufig die Verbindung verlieren, wird ein dauerhaftes Cloud-Arbeitsplatzmodell plausibler.
• Wenn Datenschutz oder DSGVO-Anforderungen gelten, prüfen wir zusätzlich Zugriffskontrolle, Speicherort, Protokollierung und Löschfristen. Die Datenschutzhinweise von ZekVPS sollten dabei neben den technischen Projektanforderungen gelesen werden.

Die zentrale Entscheidung lautet also nicht „Wie viele Agenten möchten wir starten?“, sondern „Welche Spitzenlast muss gleichzeitig sicher gespeichert, ausgeführt und wiederhergestellt werden?“ Erst danach wählen wir Arbeitsplatzgröße, Persistenzmodell und Parallelitätsgrenze.

Lokale Ausführung oder gemieteter Mac-Arbeitsplatz

Lokale Entwicklung bleibt sinnvoll, wenn die Aufgaben kurz sind, keine dauerhaften Sitzungen benötigen und das Gerät zuverlässig verfügbar ist. Für längere Claude-Code-Aufgaben hat die lokale Variante jedoch drei typische Schwächen: Schlaf- und Neustartverhalten unterbrechen Prozesse, die Internetverbindung kann während eines Tool-Aufrufs ausfallen, und mehrere parallele Agenten konkurrieren direkt mit der täglichen Nutzung des Rechners. Ein zusätzlicher lokaler Mac löst außerdem nicht automatisch die Fragen nach Artefaktaufbewahrung, Zugangsschutz und Wiederherstellung.

Ein gemieteter Mac-Arbeitsplatz von ZekVPS ist für temporäre Projekte, reproduzierbare Tests und längere Cloud-Sitzungen dann interessanter, wenn die benötigte Laufzeit, der gewünschte Standort und die Aufbewahrung der Daten vorher festgelegt werden. Für einen ersten Vergleich können Sie die verfügbaren Arbeitsplätze auf der ZekVPS-Übersicht für Mac-Arbeitsplätze prüfen. Für eine standortbezogene Planung ist beispielsweise die Seite zum Mac mini in Japan relevant.

Die Entscheidung sollte trotzdem gegen die Variablen aus diesem Beitrag geprüft werden: Peak-Parallelität, Projektgröße, Artefaktwachstum, externe Zustände und Wiederherstellungsreserve. Bei dauerhaft hoher, planbarer Auslastung kann ein eigener Mac wirtschaftlicher und administrativ einfacher sein. Physische Schnittstellen, lokale Peripherie oder besonders strenge Datenresidenz können ebenfalls gegen Miete sprechen. Für zeitlich begrenzte Entwicklungsphasen, lange Agent-Aufgaben und Tests mit wechselnder Kapazität bietet ein persistenter ZekVPS-Arbeitsplatz dagegen einen kontrollierteren Ausgangspunkt als ein Mac, der nebenbei als persönliches Arbeitsgerät läuft.