- Das Problem. KI-Tools belegten auf einem Entwickler-Mac 72,6 GiB. Allein Codex kam auf 53,7 GiB in 21.613 Dateien.
- Was wir herausgefunden haben. In den größten Unterhaltungen machten Bilder 77 % aus, und 39 % davon waren Kopien, die der Agent beim Verdichten seines Verlaufs erneut gespeichert hatte. Auf Subagenten entfielen nur 30 % der Bytes.
- Was wir gebaut haben. Optimize in Mint behält die Bilder, die Codex liest, wenn du eine Unterhaltung fortsetzt. Keep text only entfernt Bilder, Audio und Video dauerhaft und behält den Text.
Wenn Codex, Claude oder Cursor Dutzende Gigabyte belegen, kann es dich Arbeit kosten, den ganzen Ordner zu löschen. Trenne zuerst die Unterhaltungen und ihre Bilder von Caches, temporären Builds und Bundles virtueller Maschinen. Hier zeigen wir diese Unterschiede anhand von Messungen auf einem Mac und verlinken die aktuellen Aufräum-Anleitungen für jedes Tool.
Wir haben nachgesehen. Auf einem Entwickler-Mac belegten KI-Tools 72,6 GiB. Allein Codex kam auf 53,7 GiB in 21.613 Dateien. Claude Desktop hatte 11,8 GiB, davon 10,1 GiB in Bundles virtueller Maschinen. Dann folgten Cursor mit 5,4 GiB, Claude Code mit 1,5 GiB und Gemini CLI mit 0,2 GiB.
Die Summe selbst überrascht nicht besonders. Jeder Entwickler, dem wir das gezeigt haben, hat eine ähnliche Zahl. Überrascht hat uns, woraus die Bytes tatsächlich bestehen. Fast niemand errät es, und wir lagen auch daneben.
Der Text ist klein
Die übliche Vermutung lautet: Ein Agent, der lange läuft, schreibt viel Text, und der Text summiert sich. Tut er nicht. Text braucht fast keinen Platz.
Wir haben die 50 größten aktiven Sitzungsdateien (insgesamt 10,9 GB) gestreamt und jeden eingebetteten Payload auf dem Gerät gehasht. Auf Bilder entfielen 8,43 GB der 10,9 GB. 77 % dieses „Unterhaltungsverlaufs“ sind also Pixel: Screenshots, die der Agent aufgenommen hat, Bilder, die er erzeugt hat, und visuelle Tool-Ausgaben, die er sich ein einziges Mal angesehen hat.
Dann haben wir geprüft, wie viele dieser Bilder einmalig waren. Von den 8,43 GB waren es nur 5,17 GB. 3,26 GB, also 39 %, waren Kopien von etwas, das bereits in derselben Datei lag. Von 17.643 eingebetteten Bildern sind 11.790 verschieden und 5.853 Wiederholungen.
17.643 eingebettete Bilder · 11.790 einmalig · 5.853 wiederholen etwas, das schon in der Datei steht
Wie die Verdichtung Kopien erzeugt
Einer langen Sitzung geht irgendwann der Kontext aus. Damit es weitergeht, verdichtet der Agent seinen Verlauf (Compaction): Er fasst zusammen, was bisher passiert ist, und arbeitet auf Basis dieser Zusammenfassung weiter. Das ist sinnvoll und notwendig.
In diesen Sitzungen wird ein Bild vollständig gespeichert, als Data-URL direkt in den Eintrag eingebettet, ohne Pfad zu einer Datei auf der Festplatte. Wenn ein Verdichtungseintrag geschrieben wird, betten manche dieser Einträge die Bilddaten, die sie gerade zusammengefasst haben, erneut ein, statt auf sie zurückzuverweisen.
Die erste Runde enthält das Original. Die zweite enthält das Original plus die Kopie aus Runde eins, und die dritte enthält all das noch einmal. Jede Verdichtung macht den Verlauf größer, und zwar linear mit der Größe aller Bilder, die davor kamen.
Die größte einzelne Sitzungsdatei, die wir uns angesehen haben, war 14 GiB groß und enthielt eine einzige Unterhaltung. Darin steckten 359 Verdichtungen und 13,6 GiB eingebettete Bilddaten, und davon waren nur 155 MiB einmalige Bildinhalte. 99 % waren immer wieder dieselben Bilder, und fünf der Bilder tauchten jeweils 45 bis 136 Mal auf. An diesem Punkt bestehen die Verdichtungseinträge größtenteils aus Kopien von Bildern, die schon in der Datei lagen.
Woher die Bytes kamen
Für den aufgeblähten Speicherbedarf von Agenten macht gerade eine beliebte Erklärung die Runde, und sie klingt überzeugend. Agenten starten Subagenten, Subagenten erben den Verlauf ihres Elternagenten, jeder Zweig kopiert die Daten erneut, und der Baum vervielfacht sich immer weiter: mehr Agenten, mehr Kopien, bis die Festplatte voll ist.
Wir haben das auch geglaubt. Der Mac hat aber die Daten, um es zu prüfen, also haben wir geprüft.
Codex führt eine eigene Thread-Datenbank, und darin steht eine Tabelle, die festhält, welcher Thread welchen gestartet hat. Wir haben jede Rollout-Datei auf der Festplatte ihrem Thread zugeordnet und nachgesehen, wo die 50,4 GiB lagen.
Hauptsitzungen, die im Editor gestartet wurden, belegten 32,9 GiB, also 65,4 %. Gestartete Subagenten-Threads belegten 15,1 GiB oder 30,0 %, Sitzungen auf der Kommandozeile 2,1 GiB. Zwei Drittel der Bytes hatten nichts mit Subagenten zu tun.
Das ändert, was dagegen zu tun ist. Wäre die Auffächerung in Subagenten die Ursache, ginge es bei der Lösung darum, wie du Agenten einsetzt: weniger davon, weniger gleichzeitig, sorgfältiger delegieren. Das ist ein nützlicher Rat, aber auf diesem Mac hätte er höchstens ein Drittel des Problems gelöst.
Die Ursache ist das erneute Einbetten, und dafür braucht es keinen Subagenten, nur eine lange Unterhaltung mit Bildern darin. Subagenten vervielfachen den Effekt. Setzt du nur weniger Subagenten ein, bleiben die Duplikate; entfernst du die Duplikate, werden auch die Subagenten-Threads kleiner.
„Archivieren“ gibt nichts frei
Noch eine Sache, weil Leute ganze Nachmittage damit verlieren. Wenn du im Agenten eine Unterhaltung archivierst, wird die Datei nur von einem Ordner in einen anderen verschoben. Auf dem gemessenen Mac belegten 1.174 archivierte Unterhaltungen weiterhin 16,1 GiB. Archivieren hält die Liste übersichtlich und spart keinen Platz. Speicherplatz bekommst du nur zurück, wenn etwas gelöscht wird.
14 GB lesen, ohne den Mac lahmzulegen
Eine kurze technische Anmerkung, denn daran wäre die ganze Untersuchung fast gescheitert.
Unser erstes Analyse-Tool hat die Sitzungsdateien in einer Schleife gestreamt, die nichts von dem freigab, was sie gelesen hatte, und so hielt der Prozess alles fest. Nach dem Lesen von 1,15 GB blieben 1.097 MB im Speicher. Als wir es auf eine 14 GB große Datei angesetzt haben, ging dem Mac der Programmspeicher aus.
Die neue Version liest in einen einzigen wiederverwendbaren Puffer, und beim Lesen derselben 1,15 GB bleiben 14 MB belegt. Danach erfasste der vollständige Durchlauf für die Bestandsaufnahme 72,6 GiB in 8,6 Sekunden bei 28 MB residentem Speicher, und der gründliche Hash-Durchlauf streamte 10,9 GB bei 42 MB. Eine Laufzeitprüfung wacht darüber: Wächst der Speicher beim Streamen einer Datei zu stark, bricht der Durchlauf von selbst ab, statt den Mac lahmzulegen.
Ohne das kann ein Tool gar nicht erst in diese Dateien hineinsehen. Niemand kann eine Analyse ausliefern, die 18 GB Arbeitsspeicher braucht.
Deduplizieren statt löschen
Sobald du weißt, dass die Bytes Duplikate sind, fällt die Entscheidung viel leichter.
Wer eine Unterhaltung löscht, wirft Arbeit weg: die Überlegungen, die Diffs, die Gründe für eine Entscheidung. Niemand sollte dazu gedrängt werden, nur um Speicherplatz zurückzubekommen. Beim Deduplizieren innerhalb einer Unterhaltung geht nichts verloren. Das erste Vorkommen jedes Bildes bleibt, wo es ist, und spätere Duplikate werden ersetzt.
Die Unterhaltung ließ sich im Agenten weiterhin öffnen, und die Screenshots waren weiterhin zu sehen. Weil die erste Kopie die Datei nie verlassen hat, ließ sich die Änderung aus der Datei selbst Byte für Byte rückgängig machen, ohne Tresor und ohne externen Zustand, der verloren gehen könnte.
Das haben wir zuerst ausgeliefert, als Optimize, und was es versprach, stimmte. Dann haben wir dieselbe Messung über den gesamten Bestand laufen lassen statt nur über die fünfzig größten Dateien, und dabei kamen drei Dinge heraus. Duplikate innerhalb einer Unterhaltung waren der kleinste von drei Anteilen, und die meisten davon lagen in Unterhaltungen, die noch in Gebrauch waren. Außerdem kann eine Unterhaltung von der Datei einer anderen Unterhaltung abhängen, und dann ist es nicht sicher, diese Datei zu verändern. Die vollständige Bestandsaufnahme steht in Codex-Speicherplatz: Was steckt in 22 GB Unterhaltungen?, und die frühen Vorschaubilder, die dort beschrieben sind, gehören der Vergangenheit an. Heute hält Mint zwei Aktionen auseinander. Optimize behält die Bilder, die Codex liest, wenn du eine unterstützte Unterhaltung fortsetzt. Keep text only entfernt eingebettete Bilder, Audio und Video dauerhaft und behält den Text; wo ein Bild war, bleibt ein Hinweis, kein kleines Vorschaubild.
Manches ist gleich geblieben. Delete permanently entfernt ganze Unterhaltungen über den Agenten selbst, damit sein Index stimmig bleibt. Unterhaltungen sind anfangs nicht angehakt, und Keep text only und Delete permanently fragen nach einer Bestätigung, bevor sie eine Datei anfassen. Ein unterstütztes Optimize lässt sich rückgängig machen, solange die Originale und der Verlauf, die es dafür braucht, noch vorhanden sind; Keep text only und Delete permanently lassen sich nicht rückgängig machen. Prüf die Bestätigung, die deine installierte Version für die angebotene Aktion anzeigt.
Was wir gelernt haben
Der Speicher von Agenten wirkt vor allem deshalb wie eine Blackbox, weil niemand hineinschaut, und so kompliziert ist er gar nicht. Die Dateien sind reiner Text auf deiner eigenen Festplatte, die Thread-Datenbank ist eine SQLite-Datei, die du öffnen kannst, und die Duplikate kannst du an einem Nachmittag mit einer Hash-Funktion messen.
Wir sind mit der Erwartung herangegangen, am Ende zu schreiben: „Agenten erzeugen viele Daten, hier ist ein Aufräum-Tool.“ Was wir fanden, war konkreter: Das meiste sind dieselben Daten, immer wieder gespeichert. Wie viel davon, siehst du pro Datei auf deinem eigenen Mac, ohne etwas hochzuladen.
Deshalb zeigt dir Mint die Zahlen und den Grund, und du musst Mint nicht einfach glauben. Mint löscht eine Unterhaltung nur, wenn du Delete permanently wählst. Optimize behält, was Codex liest; Keep text only wägt anders ab, behält den Text und verwirft Medien. Die aktuelle Anleitung erklärt den Unterschied.
Jede Zahl hier wurde im August 2026 mit Mints eigenen, rein lesenden Scans auf einem Entwickler-Mac gemessen. Die Scans lesen nur, laufen vollständig auf dem Gerät, und du kannst sie auf deinem Mac wiederholen.