DeepSeek-Harness-Sitzungsprotokoll-Speicher 2026

Der richtige Messrahmen

Die zentrale Formel lautet:

Gesamtspeicher
= Sitzungsereignisse
+ Werkzeugausgaben
+ Anhänge
+ Arbeitsbereichsprodukte
+ Laufzeit- und Zwischenspeicher
+ Sicherungskopien

Die erste wichtige Abgrenzung betrifft Tokens. Ein Tokenverbrauch beschreibt die Datenmenge, die ein Modell verarbeitet. Der lokale Mac-Speicher enthält dagegen serialisierte Ereignisse, JSON-Strukturen, Datenbankseiten, Werkzeugresultate, Bilder, temporäre Dateien und gegebenenfalls mehrere Kopien derselben Datei. Beide Werte können zusammenhängen, sind aber nicht identisch.

Die DeepSeek-API-Dokumentation zur Completion-Antwort weist unter usage unter anderem prompt_tokens, completion_tokens und total_tokens aus. Diese Werte sind für Kosten- und Lastanalysen nützlich, ersetzen aber keine Messung des Sitzungsordners oder des Arbeitsbereichs.

Wer nur die Eingabe- und Ausgabetokens aus einer Abrechnung übernimmt, misst deshalb nicht den tatsächlichen Speicherplatz für DeepSeek-Harness-Sitzungsprotokolle. Für jede Messung sollten mindestens diese Angaben notiert werden:

• DeepSeek-Harness-Version und Commit;
• Betriebssystemversion und Dateisystem;
• Aufgabentyp, beispielsweise Repository-Analyse, Build, Testlauf oder Bildprüfung;
• Start- und Endzeit des Testlaufs;
• Anzahl der parallelen Sitzungen;
• verwendete MCP- oder ACP-Dienste;
• Aufbewahrungs- und Sicherungsregel.

Diese Dokumentation ist nicht nur für die Vergleichbarkeit wichtig. Bei einer Änderung des Sitzungsformats, der Komprimierung oder der Anhangsbehandlung kann derselbe Auftrag später eine andere lokale Struktur erzeugen. Ein Messwert ohne Versionsangabe ist für eine Beschaffungsentscheidung daher nur eingeschränkt verwendbar.

Sitzungsereignisse und SessionEvent

Eine wiederaufnehmbare Agentensitzung besteht nicht nur aus dem sichtbaren Dialog. Je nach Implementierung können Benutzerereignisse, Modellantworten, Werkzeugaufrufe, Werkzeugantworten, Genehmigungen, Fehler, Kontextkomprimierungen und Wiederaufnahmeinformationen in einer dauerhaften Ereigniskette landen.

Der Begriff SessionEvent sollte deshalb als Messkategorie verstanden werden: Er beschreibt ein gespeichertes Ereignis oder einen Eintrag der Sitzungsablage, nicht automatisch eine bestimmte Dateigröße. Ein unabhängiges DeepSeek-Harness-Projekt dokumentiert beispielsweise eine Ereignisbehandlung über on_event und das Speichern von Gesprächsverläufen; daraus lässt sich jedoch keine allgemeingültige Speichergröße für DeepSeek Harness ableiten. (Beispiel einer nicht-offiziellen Harness-Implementierung)

Wo liegen die Sitzungsprotokolle von DeepSeek Harness?
Die sichere Antwort lautet: Das hängt von der am Messtag installierten Version und ihrer Konfiguration ab. Statt einen vermeintlich festen Pfad aus einem Blogbeitrag zu übernehmen, sollte das Team zuerst die offizielle Sitzungsdokumentation und das aktuelle Quellverzeichnis prüfen. Danach wird der tatsächliche Sitzungsordner während eines Testlaufs beobachtet.

Auf macOS kann die Suche beispielsweise so beginnen:

find "$HOME/Library" "$HOME/.config" "$HOME/.local" \
  \( -iname '*deepseek*' -o -iname '*harness*' \) 2>/dev/null

Die Ausgabe ist nur ein Suchergebnis und keine automatische Freigabe zum Löschen. Nach der Identifikation des aktiven Pfads wird die Größe vor und nach einer Aufgabe verglichen:

du -sh "/PFAD/ZUR/SESSIONS-ABLAGE"

find "/PFAD/ZUR/SESSIONS-ABLAGE" -type f -print0 |
  xargs -0 stat -f '%z %N' | sort -nr | head -20

Die Größenanzeige von macOS kann zusätzlich über Systemeinstellungen > Allgemein > Speicher geprüft werden. Apple beschreibt in der Anleitung zur Anzeige des verfügbaren Mac-Speichers, dass die Speicheransicht Kategorien und Volumes getrennt ausweisen kann. Für eine Harness-Messung bleibt du oder die Dateistatistik dennoch erforderlich, weil „Systemdaten“ zahlreiche unterschiedliche Quellen zusammenfassen kann.

Für einen reproduzierbaren Basiswert sollten nicht mehrere Aufgaben gleichzeitig gestartet werden. Zuerst wird die Sitzung geschlossen oder sauber beendet, anschließend wird der Ordnerwert notiert. Nach genau einem definierten Auftrag wird erneut gemessen. Die Differenz ist der Rohwert des Testlaufs:

Delta_Sitzung = Größe_nachher - Größe_vorher

Ein langer Dialog mit wenigen Werkzeugen kann dadurch kleiner bleiben als ein kurzer Dialog, der große Kommandoausgaben, Quelltextblöcke oder strukturierte Rückgaben speichert.

Werkzeugausgaben und Arbeitsbereich

Die zweite Messgröße entscheidet häufig über die Obergrenze eines langen Entwicklungsauftrags. Build-Ausgaben, Testprotokolle, Paketlisten, Suchtreffer und umfangreiche Codeausschnitte können entweder in der Sitzungsablage, im Arbeitsbereich oder an beiden Orten landen. Genau diese Unterscheidung muss vor einer Bereinigung geklärt werden.

Drei Fälle sind in der Praxis zu trennen:

1. Werkzeugausgabe im Sitzungsprotokoll: Die Ausgabe bleibt für Wiederaufnahme, Prüfung oder Replay erhalten.
2. Werkzeugausgabe als Arbeitsdatei: Das Ergebnis liegt beispielsweise als Logdatei, JSON-Bericht oder Patch im Projektordner.
3. Doppelte Ablage: Eine gekürzte Anzeige wird protokolliert, während das vollständige Ergebnis zusätzlich im Arbeitsbereich verbleibt.

Die gleiche Logik gilt für CI/CD- und Build-Artefakte. Die GitHub-Dokumentation zu Workflow-Artefakten nennt unter anderem Logdateien, Testresultate, Screenshots, komprimierte Dateien und Code-Coverage-Berichte als typische Artefakte. Diese Beispiele sind keine DeepSeek-Harness-Messwerte, zeigen aber, warum Arbeitsbereichsprodukte und Sitzungsereignisse getrennt bilanziert werden müssen.

Für den Vergleich verschiedener Ausgabestrategien sollte dasselbe Basisprojekt verwendet werden. Der erste Lauf speichert die vollständige Ausgabe, der zweite begrenzt die Terminalausgabe und schreibt ausführliche Resultate in eine benannte Datei, der dritte verwirft nicht benötigte Zwischenresultate. Nach jedem Lauf werden Sitzungsordner und Arbeitsbereich getrennt gemessen.

BEFORE_SESSION=$(du -sk "/PFAD/ZUR/SESSION" | awk '{print $1}')
BEFORE_WORK=$(du -sk "/PFAD/ZUM/WORKSPACE" | awk '{print $1}')

# Hier wird genau ein definierter Benchmark-Auftrag ausgeführt.

AFTER_SESSION=$(du -sk "/PFAD/ZUR/SESSION" | awk '{print $1}')
AFTER_WORK=$(du -sk "/PFAD/ZUM/WORKSPACE" | awk '{print $1}')

printf 'Sitzung: %s KiB\n' "$((AFTER_SESSION - BEFORE_SESSION))"
printf 'Arbeitsbereich: %s KiB\n' "$((AFTER_WORK - BEFORE_WORK))"

Die Beispielausgabe des Skripts enthält bewusst keine behaupteten Messwerte:

Sitzung: <gemessene Differenz> KiB
Arbeitsbereich: <gemessene Differenz> KiB

Wie viel Speicherplatz benötigt eine lange Sitzung?
Eine belastbare Antwort gibt es erst nach einem Test mit dem realen Aufgabentyp. Für eine reine Textsitzung wird der Messwert anders ausfallen als für einen Agentenlauf, der mehrfach Tests startet, Dateien durchsucht und große Resultate an die Sitzung zurückgibt.

Die korrekte Planung lautet daher:

Monatlicher Logbedarf
= Aufgaben_pro_Tag
× Arbeitstage
× Delta_Sitzung_pro_Aufgabe
× Aufbewahrungsmonate

Für den Arbeitsbereich wird eine zweite Reihe geführt:

Arbeitsbereichsbedarf
= neue oder veränderte Dateien pro Aufgabe
× Aufgabenanzahl
+ feste Repository- und Build-Größe

Das verhindert, dass ein Team eine Logbereinigung durchführt, während erzeugte Testberichte, Paket-Caches oder Artefakte weiterwachsen.

Bilder und persistente Anhänge

Bildaufgaben werden separat erfasst. Die Zahl der Bilder genügt nicht, weil ein einzelner Anhang in Originalauflösung, als verarbeitete Kopie, als Vorschaudatei oder nach einer Wiederaufnahme mehrfach vorhanden sein kann.

Das MCP-Protokoll beschreibt Bildinhalte als eigene Content-Art und weist zugleich darauf hin, dass Verbraucher Grenzen für Bild- und Inhaltsgrößen festlegen können. Daraus folgt für die Kapazitätsplanung: Eine Bildübergabe ist nicht automatisch gleichbedeutend mit einer einzigen lokalen Datei. Implementierung, Konfiguration und Wiederaufnahmeverhalten müssen tatsächlich geprüft werden.

Werden Bildanhänge zusammen mit der Sitzung dauerhaft gespeichert?
Das ist für die konkrete Installation anhand eines Testlaufs zu verifizieren. Ein Bild sollte einmal als Referenzanhang eingebracht, die Sitzung beendet und anschließend wieder aufgenommen werden. Danach wird geprüft, ob die Originaldatei, eine abgeleitete Datei oder nur ein Verweis vorhanden ist.

find "/PFAD/ZUR/SESSION" "/PFAD/ZUM/WORKSPACE" \
  -type f \( -iname '*.png' -o -iname '*.jpg' -o -iname '*.jpeg' \
  -o -iname '*.webp' -o -iname '*.heic' \) \
  -exec stat -f '%z %N' {} \; | sort -nr

Die Messung sollte vier Zustände enthalten:

• Originalanhang vor der Verarbeitung;
• zusätzlicher Speicher nach dem ersten Modellaufruf;
• Speicher nach Sitzungsende;
• Speicher nach Wiederaufnahme und Export.

Für Datenschutz und DSGVO müssen zusätzlich Herkunft, Zweck, Zugriff und Löschfrist dokumentiert werden. Die ICO-Leitlinie zur Speicherbegrenzung erläutert, dass personenbezogene Daten nicht länger als für den jeweiligen Zweck erforderlich aufbewahrt werden sollen. Screenshots mit Quellcode, Kundendaten oder Zugangsinformationen gehören daher nicht automatisch in eine Langzeitaufbewahrung, nur weil sie technisch wiederherstellbar sind.

Ein sicherer Löschprozess muss außerdem prüfen, ob Kopien im Arbeitsbereich, in temporären Verzeichnissen oder in Sicherungen verbleiben. Bei sensiblen Bildern ist die Löschentscheidung deshalb nicht allein eine Speicheroptimierung, sondern Teil der Datenschutz- und Zugriffskontrolle.

Sicherungen, Snapshots und Wiederherstellung

Online-Daten und Sicherungskopien dürfen nicht als derselbe Speicherbereich geplant werden. Die Kapazitätsformel sollte mindestens diese Variablen enthalten:

Planbarer Bedarf
= Online-Daten
+ lokale Snapshots
+ externe oder entfernte Sicherung
+ Migrationskopie
+ Rückfallreserve

Apple beschreibt in der Dokumentation zu Time-Machine-Snapshots, dass macOS lokale Snapshots ungefähr stündlich anlegen und ältere Snapshots bei Platzbedarf automatisch entfernen kann. Diese Snapshots liegen auf demselben Mac-Speicher wie die Produktivdaten und sind von einer separaten Sicherung zu unterscheiden.

Für eine externe Time-Machine-Sicherung empfiehlt Apple als allgemeinen Richtwert ein Sicherungslaufwerk mit mindestens der doppelten Kapazität des Mac-Speichers. Das ist keine DeepSeek-Harness-Regel und kein fester Mietwert, sondern eine allgemeine Apple-Empfehlung für die Sicherungsplanung. (Apple: Auswahl eines Backup-Laufwerks für Time Machine)

Ein zusätzlicher Fehler entsteht, wenn eine Sicherung zwar lesbar ist, aber nach einem Versionswechsel nicht direkt fortgesetzt werden kann. Vor einer Bereinigung sollte deshalb mindestens ein Wiederherstellungstest ausgeführt werden:

1. Einen repräsentativen Sitzungsstand auswählen.
2. Sitzungsdaten und zugehörige Arbeitsdateien in eine isolierte Testumgebung kopieren.
3. Die verwendete DeepSeek-Harness-Version dokumentieren.
4. Die Sitzung auf einem separaten Arbeitsverzeichnis wieder aufnehmen.
5. Prüfen, ob Werkzeuge, Anhänge und Genehmigungszustände nachvollziehbar bleiben.
6. Das Ergebnis als „wiederaufnehmbar“, „nur lesbar“ oder „nicht kompatibel“ kennzeichnen.

Ein lesbarer Export ist damit nicht automatisch ein funktionsfähiger Wiederanlauf.

Messung innerhalb einer Arbeitswoche

Die folgende Reihenfolge verhindert, dass ein Team zu früh erweitert oder zu aggressiv löscht:

1. Version einfrieren: Commit, Paketstand, macOS-Version und Konfiguration notieren.
2. Arbeitsbereich vorbereiten: Ein frisches Repository oder eine definierte Kopie verwenden; bestehende Caches getrennt ausweisen.
3. Basiswerte erfassen: Sitzungsordner, Arbeitsbereich, temporäre Ablage und verfügbare Kapazität messen.
4. Benchmark ausführen: Einen typischen Agentenauftrag mit realen Werkzeugen, Freigaben und gegebenenfalls Bildern starten.
5. Nachmessung durchführen: Sitzungsdaten und Arbeitsbereich getrennt erfassen.
6. Wiederaufnahme prüfen: Sitzung schließen, erneut öffnen und die Größenänderung dokumentieren.
7. Sicherung erstellen: Online-Daten, Snapshot und externe Kopie getrennt protokollieren.
8. Bereinigung testen: Nur eindeutig regenerierbare Artefakte in einer Kopie entfernen.
9. Wiederherstellung validieren: Prüfen, ob der verbleibende Stand tatsächlich weiterverwendbar ist.
10. Kapazitätsplan erstellen: Tageslast, Aufbewahrungsdauer, parallele Sitzungen und Kopien in die Formel einsetzen.

Die operative Messung kann mit einem einfachen Protokoll erfolgen:

Version:
Aufgabentyp:
Beobachtungszeitraum:
Sitzungsgröße vorher:
Sitzungsgröße nachher:
Werkzeugausgaben:
Arbeitsbereich vorher:
Arbeitsbereich nachher:
Anhänge:
Sicherungskopie:
Wiederaufnahme erfolgreich: ja/nein

Das Beobachtungsintervall sollte lang genug sein, um mindestens einen vollständigen Auftrag mit Abschluss, Wiederaufnahme und Sicherung abzubilden. Ein einzelner Dialog ohne Nachlauf kann temporäre Dateien und Wiederherstellungskopien übersehen.

Bereinigung und Erweiterung

Welche Sitzungsdaten lassen sich sicher löschen?
Sicher löschbar sind nur Daten, deren Funktion und Wiederherstellungsbedarf bekannt sind. Typische Kandidaten sind abgeschlossene Zwischenberichte, reproduzierbare Build-Artefakte, doppelte Bildvorschauen und temporäre Downloads. Nicht ohne Prüfung entfernt werden sollten Ereignisse, die für Audit, Genehmigung, Fehleranalyse oder eine spätere Wiederaufnahme erforderlich sind.

Die Entscheidung sollte anhand dieser Bedingungen erfolgen:

• Wenn ein Artefakt aus einer versionierten Quelle reproduzierbar ist und kein Prüf- oder Aufbewahrungsbedarf besteht, dann kann es nach erfolgreicher Wiederherstellung aus dem aktiven Arbeitsbereich entfernt werden.
• Wenn eine Werkzeugausgabe die einzige Erklärung für eine Änderung oder Genehmigung enthält, dann bleibt sie bis zum Ende der festgelegten Prüfphase erhalten.
• Wenn ein Bild personenbezogene oder vertrauliche Informationen enthält, dann wird zuerst die DSGVO-Löschentscheidung dokumentiert und erst danach werden aktive und gesicherte Kopien behandelt.
• Wenn der Speicherzuwachs vor allem aus Arbeitsdateien stammt, dann wird zuerst der Arbeitsbereich bereinigt, nicht die Ereignisablage.
• Wenn die Aufbewahrung fachlich notwendig ist und die freie Kapazität unter die interne Sicherheitsreserve fällt, dann wird erweitert oder auf eine größere Cloud-Mac-Umgebung gewechselt.
• Wenn die Messwerte zwischen zwei Versionen stark abweichen, dann wird der Benchmark wiederholt, bevor eine dauerhafte Mietentscheidung getroffen wird.

Für die laufende Kontrolle eignen sich Schwellenwerte, die aus dem gemessenen Bedarf abgeleitet werden, nicht aus pauschalen Hardwaretabellen. Beispielsweise kann ein Alarm ausgelöst werden, sobald der freie Speicher unter den für einen vollständigen Benchmark plus Wiederherstellung benötigten Wert sinkt. Dieser Schwellenwert muss pro Team festgelegt werden.

Entscheidungstabelle für die Beschaffung

Vor der Auswahl einer Cloud-Mac-Umgebung sollte jede Zeile mit den gemessenen Werten der eigenen Aufgaben gefüllt werden. Die Tabelle enthält deshalb keine erfundenen Konfigurations- oder Preisangaben.

Für die Planung eines Cloud-Macs werden anschließend vier Werte eingesetzt:

Speicherreserve
= gemessener Bedarf pro Aufgabe
× Aufgaben pro Aufbewahrungszeitraum
× Anzahl paralleler Aufgaben
+ Sicherungs- und Wiederherstellungsbedarf
+ freie Betriebsreserve

Die Formulierung „freie Betriebsreserve“ sollte dabei nicht als pauschale Prozentzahl verstanden werden. Sie muss aus dem größten realen Auftrag, temporären Build-Dateien, Wiederaufnahmeprüfung und dem gewünschten Reaktionsfenster bei unerwartetem Wachstum abgeleitet werden.

Die passende Mac-Strategie

Ein lokaler Mac ist für Teams sinnvoll, die dauerhaft dieselbe Umgebung benötigen, physische Schnittstellen anschließen müssen oder langfristig hohe, gut planbare Lasten ausführen. Eine Cloud-Mac-Miete passt dagegen besser zu zeitlich begrenzten Tests, wechselnden Projekten, Beschaffungsphasen und Teams, die zuerst den realen Speicherzuwachs von DeepSeek Harness messen möchten.

Ein pauschaler Hardwarekauf löst das eigentliche Problem nicht: Er beantwortet weder, welche Daten wachsen, noch welche Kopien aufbewahrt werden müssen. Auch eine ungeprüfte Bereinigung ist riskant, weil dabei Audit-Ereignisse oder für die Wiederaufnahme benötigte Werkzeugresultate verloren gehen können.

Bei einem Cloud-Mac lassen sich Testumgebung, Mietdauer und Kapazitätsentscheidung zunächst getrennt bewerten. Für die weitere Planung kann die Übersicht zu Mac-Mietoptionen für DeepSeek Harness als Einstieg dienen; bei einem bestimmten Standort sollte anschließend die passende Cloud-Mac-Bestellung für Virginia oder eine andere verfügbare Region geprüft werden.

Nach dem ersten Benchmark empfiehlt sich zusätzlich der Leitfaden zur Übergabe einer Mac-Umgebung, damit nicht nur Speicher, sondern auch Zugriff, Arbeitsbereich und Wiederaufnahme getestet werden. NodeMini ist besonders dann eine sachliche Option, wenn kurzfristig eine reproduzierbare Mac-Umgebung für Messung, Migration oder ein zeitlich begrenztes DeepSeek-Harness-Projekt benötigt wird.

Für dauerhaft hohe Last, zwingende physische Anschlüsse oder eine langfristig unveränderte Installation bleibt der eigene Mac jedoch die transparentere Lösung. Wenn Logs, Werkzeugresultate und Bilder fachlich nicht sicher gelöscht werden dürfen, sind eine größere Kapazität und eine getestete Sicherungsstrategie sinnvoller als eine aggressive Bereinigung. Entscheidend ist, dass die Mietentscheidung erst nach der Messung getroffen wird: zuerst den Einheitszuwachs bestimmen, anschließend Aufbewahrung und Kopien einrechnen, dann erweitern oder die Cloud-Mac-Miete auf den tatsächlichen Bedarf abstimmen.