35,1 % weniger Speicherplatz. Dieselben 135 Gesprächsrunden in Codex.
Codex speichert jede Unterhaltung als Datei in ~/.codex/sessions, archivierte Unterhaltungen in ~/.codex/archived_sessions. Screenshots werden direkt in diese Datei geschrieben. Eine lange Unterhaltung kann deshalb mehrere Hundert MB groß werden, und löschst du sie, ist auch ihr Verlauf weg. Am 15. Oktober 2026 senkte Optimize in der öffentlichen Version Mint 1.0.99 den Speicherbedarf von acht archivierten Unterhaltungen um 35,1 %. Codex las dieselben 135 Gesprächsrunden, und nach Undo stimmten Text und Bilder mit dem Original überein.
Das Wichtigste in Kürze
- Wo die Daten liegen. Codex legt Unterhaltungen in ~/.codex/sessions ab, archivierte in ~/.codex/archived_sessions. Screenshots schreibt Codex direkt in die jeweilige Datei.
- Öffentliche Version, 15. Oktober 2026. Optimize senkte den Speicherbedarf von acht archivierten Unterhaltungen um 35,1 %, im Schnitt um 29,18 MB pro Unterhaltung. Codex las dieselben 135 Gesprächsrunden, und 8 von 8 Inhaltsprüfungen nach Undo stimmten überein.
- Entwicklungsversion, 26. September 2026. Ein anderes Komprimierungsverfahren auf Dateiebene sparte bei drei Unterhaltungen 1,29 GB. 4 von 4 Dateien waren bytegleich, und Codex las dieselben 1.598 Gesprächsrunden. Mit der öffentlichen Version wurde der Test nicht wiederholt.
- Geltungsbereich. Der Mac eines einzelnen Entwicklers. Die beiden Ergebnisse stammen aus getrennten Tests: Sie werden nicht addiert, und keines sagt voraus, wie viel dein Mac einspart.
Wie viel Platz belegen deine Codex-Unterhaltungen?
Sieh zuerst auf deinem eigenen Mac nach:
du -sh ~/.codex/sessions ~/.codex/archived_sessions 2>/dev/null
Neuere Codex-Versionen (gemessen mit codex-cli 0.155.1) schreiben eine Unterhaltung, die sieben Tage lang nicht genutzt wurde, als .jsonl.zst-Datei neu. Die öffentliche Version Mint 1.0.99 listet diese Unterhaltungen noch nicht auf; die Direct-Version, die sie unterstützt, wartet noch auf die Veröffentlichung.
15. Oktober, öffentliche Version Mint 1.0.99: vorher, nachher und nach Undo
Durchschnittliche Nettoeinsparung = (666.017.792 − 432.566.272) ÷ 8 = 29.181.440 Byte, also 29,18 MB pro Unterhaltung. Die 35,1 % beziehen sich auf den gesamten Speicher der Stichprobe. Sie sind nicht der Durchschnitt aus acht einzelnen prozentualen Einsparungen.
Alle acht ausgewählten Unterhaltungen wurden verändert, keine schlug fehl oder wurde übersprungen. Der Vorgang dauerte auf diesem Mac 25,02 Sekunden. Der belegte Speicher sank netto um 233.451.520 Byte (35,0518 %). Die logische Größe sank stärker, doch diese Zahl verwenden wir nicht als Ergebnis für den Speicher.
Der Mac blieb währenddessen in Gebrauch. Zwischen der Ausgangsmessung und der Messung nach dem Vorgang sank der freie Speicherplatz des gesamten Volumes um 19,05 MB, während der gemessene belegte Speicher der Dateien um 233,45 MB sank. Wegen gleichzeitiger Aktivität, Dateisystem-Metadaten und Schnappschüssen lässt sich die Veränderung auf dem gesamten Volume nicht Mint zuschreiben. Auch die Forschungskopien belegten zusätzlichen Platz. Die Unterhaltungen, mit denen der Besitzer arbeitet, hat dieses Experiment nicht bereinigt.
| Messung | Vorher | Nach Optimize | Nach Undo |
|---|---|---|---|
| Durchschnittlich belegter Speicher pro Unterhaltung, einschließlich Overhead | 83,252 MB | 54,071 MB | 62,085 MB |
| Unterhaltungsdateien: logische Größe | 666,002 MB | 428,685 MB | 496,612 MB |
| Unterhaltungsdateien: belegter Speicher | 666,018 MB | 432,468 MB | 496,628 MB |
| Wiederherstellungsdaten: belegter Speicher | 0 MB | 0,045 MB | 0 MB |
| Testprofil: belegter Speicher | 0 MB | 0,053 MB | 0,053 MB |
| Belegter Speicher im gemessenen Bereich insgesamt | 666,018 MB | 432,566 MB | 496,681 MB |
Am 15. Oktober war dieser Mac bereits optimiert
Dieser Mac wird für die Arbeit genutzt, und sein Speicher war bereits mehrfach optimiert worden. Ein abgeschlossener Vorgang in seinem lokalen Mint-Verlauf, aufgezeichnet am 10. Oktober 2026 (UTC), meldete 15,45 GB freigegebenen Speicherplatz bei 4.801 Elementen, ohne dass etwas gelöscht wurde. Dieser frühere Vorgang umfasste einen größeren Kreis von Dateien. Sein von der App gemeldetes Ergebnis ist historischer Kontext, kein neu überprüfter Codex-Benchmark, und fließt nicht in die Einsparungen dieses Experiments ein.
Im Experiment vom 15. Oktober haben wir gemessen, wie stark die geeigneten Codex-Unterhaltungen noch schrumpfen konnten. Danach haben wir geprüft, ob Codex sie lesen und eine Fortsetzung vorbereiten konnte und ob sich ihr Inhalt wiederherstellen ließ. Der Durchschnitt von 29,18 MB beschreibt diese Stichprobe auf einem regelmäßig gepflegten Mac. Ob diese acht Unterhaltungen selbst schon einmal optimiert worden waren, haben wir nicht festgestellt.
Den historischen Eintrag und die Messwerte des separaten Experiments ansehen
15. Oktober: Lesen und Fortsetzungsanfragen
Wir haben die Originalkopien, die optimierten und die wiederhergestellten Kopien getrennt über den app-server geöffnet, den Codex selbst mitbringt, und jede Seite mit Gesprächsrunden gelesen. Jeder dieser Kopiensätze enthielt dieselben acht Threads mit 135 Gesprächsrunden und 257 Einträgen, und es trat kein Lesefehler auf. Alle acht Vergleiche der normalisierten Inhalte der Gesprächsrunden stimmten überein. Wurde eine Unterhaltung fortgesetzt, blieb ihr vorhandener Inhalt erhalten.
Außerdem haben wir Codex für jede Kopie eine Fortsetzungsanfrage erstellen lassen. Ein lokaler HTTP-Ersatzserver fing jede Anfrage ab und stoppte sie, bevor ein Modell aufgerufen wurde. Die Anfragen der optimierten und der wiederhergestellten Kopien stimmten in 8 von 8 Fällen mit dem Original überein. Eine zweite Kontrolle mit einem unveränderten Original stimmte ebenfalls in 8 von 8 Fällen überein. Der Vergleich normalisiert wechselnde IDs, Zeitstempel, Pfade zum Benutzerordner und Client-Metadaten; Bilder werden nach Abmessungen, RGBA-Pixeln und ICC-Farbprofil verglichen.
Geprüft wird also, was Codex liest und zum Senden vorbereitet. Die Qualität einer späteren Modellantwort testet das nicht, und es ist auch keine Sichtprüfung der Desktop-Oberfläche.
Was hat Undo genau wiederhergestellt?
Undo gelang bei allen acht Unterhaltungen. Außerhalb erkannter Bild-Data-URLs stimmten die wiederhergestellten Bytes mit dem Original überein. Jedes dekodierte Bild stimmte in Abmessungen, RGBA-Pixeln und ICC-Farbprofil überein.
Keine der acht vollständigen Dateien war nach Undo bytegleich: Die Bilder wurden in einem kleineren verlustfreien Format gespeichert, und Undo behält diese kleinere Kodierung bei. Deshalb belegen auch die wiederhergestellten Dateien noch weniger Platz. Der Test belegt, dass die geprüften Text- und Bildinhalte wiederhergestellt werden, nicht, dass die ursprüngliche Bildkodierung rekonstruiert wird.
Diese Ergebnisse gelten für Optimize. Remove media und Delete sind andere Aktionen und wirken endgültig. Undo setzt außerdem voraus, dass die benötigten Originale und der Wiederherstellungsverlauf noch vorhanden sind.
So lief der Test vom 15. Oktober ab
Das Mint-Team hat diese Studie am 15. Oktober 2026 auf einem eigenen Mac durchgeführt: einem MacBook Pro mit Apple M1 Max unter macOS 27.0.1, dazu Codex CLI 0.155.1. Wir haben Installationsprogramm und ausführbare Datei der öffentlichen Version Mint Direct 1.0.99 (114) überprüft und dieselbe ausführbare Datei dann unter einer isolierten QA-Identität mit eigenem, privatem Profil ausgeführt. Die eigentliche App und die genutzten Unterhaltungen blieben unverändert.
Der lokale Katalog enthielt 413 Sitzungsdateien. Davon kamen 39 archivierte Dateien der obersten Ebene in die engere Wahl: zwischen 2 und 320 MB groß, seit mindestens 24 Stunden unberührt und ohne Abhängigkeit von oder zu anderen Unterhaltungen. Ihre Prüfreihenfolge haben wir mit dem Seed 7 zufällig festgelegt und alle 39 darauf geprüft, ob frühere Verdichtungen des Kontexts mehr als 100 kB wiederholte Screenshot-Daten enthielten. Alle acht geeigneten Dateien kamen in die Stichprobe, weniger als das vorab festgelegte Maximum von zehn. Die Auswahl stand vor Optimize fest und richtete sich nicht nach den erzielten Einsparungen. Die Prüfreihenfolge war zufällig, die Stichprobe selbst aber steht für die geeigneten Dateien auf diesem Mac, nicht für eine Zufallsauswahl aller Unterhaltungen oder Nutzer.
- Unabhängige Bytekopien anlegen, ohne APFS-Klone oder Hardlinks. Hashes und Änderungszeiten der genutzten Originaldateien festhalten.
- Belegte Blöcke und logische Bytes getrennt messen. Jede reguläre Datei im ausgewählten Korpus, im Wiederherstellungsordner von Mint und im isolierten Profil einbeziehen.
- Denselben Optimize-Ablauf für ausgewählte Unterhaltungen ausführen, den auch die App verwendet. Abschluss, Fehler, Dauer und Speicher festhalten, bevor Prüfkopien entstehen.
- Die Wiederherstellungsdaten behalten, Undo testen und dann Original, optimierte und wiederhergestellte Kopien vergleichen: über den Lesezugriff von Codex und einen lokalen Mitschnitt der Fortsetzungsanfragen.
- Hashes und Änderungszeiten der Originaldateien erneut prüfen. Zusammengefasste Ergebnisse veröffentlichen; Text, Bilder, Pfade und Thread-IDs der Unterhaltungen privat halten.
Nur lesendes Hilfsskript zum Messen der Kopien und Prüfen der Inhalte nach Undo (Python)
26. September, Entwicklungsversion: 3,13 GB echte Codex-Dateien
Lang laufende Unterhaltungen können sich über mehr als eine Datei erstrecken. Im Experiment vom 26. September gehörten vier große Dateien zu drei echten Unterhaltungen; der ursprüngliche Eintrag nennt 540 MB, 564 MB, 877 MB und 1,15 GB. Mint komprimierte unabhängige Kopien, die genutzten Originale blieben unverändert. Diese Entwicklungsversion verwendete ein anderes Komprimierungsverfahren auf Dateiebene, bei dem die Bytes, die Apps lesen, exakt gleich bleiben.
Gemessen wurden 1,29 GB weniger, im Schnitt 428,42 MB pro Unterhaltung oder 321,31 MB pro komprimierter Datei. Die ursprüngliche Notiz rundete die Ausgangsmenge auf 3,13 GB. Die etwa 41 % sind deshalb ein gerundeter Vergleich mit dieser Menge, kein genauer Prozentsatz des belegten Speichers und keine Mindesteinsparung.
| Messung | Aufgezeichnetes Ergebnis |
|---|---|
| Im Experiment erfasste Ausgangsmenge | 3,13 GB (gerundet) |
| Eingesparter belegter Speicher | 1.285.251.072 Byte · 1,29 GB |
| Durchschnittliche Einsparung pro Unterhaltung | 428,42 MB · 3 Unterhaltungen |
| Durchschnittliche Einsparung pro komprimierter Datei | 321,31 MB · 4 Dateien |
| Komprimierung und vollständiges Zurücklesen aller Bytes | 12,6 Sekunden |
| Laut SHA-256 identische Dateien | 4 / 4 |
| Codex öffnete denselben Inhalt erneut | 1.598 Gesprächsrunden · 2.381 Einträge |
Konnte Codex diese großen Unterhaltungen noch nutzen?
In dieser Leseprüfung ja: Der app-server von Codex öffnete alle drei Threads genau so wie die unkomprimierten Kopien, mit 1.598 Gesprächsrunden und 2.381 Einträgen. Alle vier komprimierten Dateien waren laut SHA-256 identisch. Wurden die Unterhaltungen fortgesetzt, blieb ihr ursprünglicher Inhalt erhalten. Zwei der komprimierten Dateien gehörten zu einem Thread. Dessen zusätzliche erste Datei mit 44 MB wurde zum Lesen bereitgestellt, war aber keine fünfte komprimierte Datei.
Der aufgezeichnete Rückgang der Dateiblöcke und der Zuwachs an freiem Speicherplatz auf dem Volume stimmen bis auf 4 KiB überein. Die ursprüngliche Notiz nennt beide gleich; rechnet man ihre Einheiten um, zeigt sich dieser kleine Unterschied. Wir führen beide Werte in den Nachweisen auf. Das Ergebnis stammt aus einem datierten Experiment mit einer Entwicklungsversion, das die Komprimierung von Mint direkt ausführte, ohne die Oberfläche der App. Mit der aktuellen öffentlichen Version wurde es nicht wiederholt, und es testete weder den Optimize-Bereich der App noch Undo noch eine neue Modellantwort. Der Auszug aus der Quelle dokumentiert das Ergebnis; die privaten Unterhaltungen und die ursprünglichen Roh-Logs des Laufs gehören nicht zum öffentlichen Material.
Die Prüfungen vom 15. Oktober weiter oben betreffen einen anderen Vorgang, die Optimierung von Screenshots, an acht anderen Dateien. Sie bestätigen dieses Experiment nicht, und die beiden Einsparungen werden nicht addiert.
Was dieser Fall nicht belegt
Beide Experimente nutzten echte private Daten auf dem Mac eines einzelnen Entwicklers. Die Dateien vom 26. September wurden gezielt nach ihrer Größe ausgewählt und waren keine Zufallsstichprobe. Keines der Ergebnisse ist ein Mindestwert oder eine Vorhersage für alle Nutzer, und die beiden Einsparungen dürfen nicht addiert werden.
Es handelt sich um acht geeignete archivierte Unterhaltungen vom Mac eines einzelnen Entwicklers. Aktive Unterhaltungen, mit anderen verknüpfte Unterhaltungen, andere KI-Tools und andere Mint-Editionen wurden nicht getestet. Die 35,1 % sollten nicht auf deine gesamte Festplatte oder auf alle Codex-Installationen hochgerechnet werden.
Wie viel innerhalb von 24 Stunden nachwächst und wie es bei weiterer täglicher Nutzung aussieht, haben wir nach diesem Vorgang nicht gemessen. Die privaten Quellunterhaltungen lassen sich über die öffentliche Seite nicht unabhängig prüfen. Mit den veröffentlichten Messwerten, der Vergleichsmethode und dem Hilfsskript können andere die Prüfungen aber an eigenen Daten wiederholen. Ein Kundenzitat, eine Sternebewertung oder eine unabhängige Empfehlung ist damit nicht verbunden.
Häufig gestellte Fragen
Werden meine Codex-Unterhaltungen auch 35,1 % weniger Platz belegen?
Das hängt von den Dateien und vom Vorgang ab. 35,1 % ist der Rückgang des belegten Speichers bei acht archivierten Unterhaltungen mit der öffentlichen Version Mint 1.0.99 am 15. Oktober. Die etwa 41 % stammen aus einem separaten Test vom 26. September mit einer Entwicklungsversion und einem anderen Komprimierungsverfahren auf Dateiebene; dort wurde die genaue Einsparung mit einer auf 3,13 GB gerundeten Ausgangsmenge verglichen. Scanne deinen eigenen Mac und miss den Vorgang, den du auswählst.
Waren die Dateien bytegleich oder nur ihr Inhalt?
Im Test zur Screenshot-Optimierung vom 15. Oktober bewahrte Undo in allen acht Dateien den geprüften Text und die dekodierten Bilder. Es behielt aber die kleinere verlustfreie Bildkodierung bei, statt die ursprünglichen Bildbytes zu rekonstruieren. Im separaten Experiment vom 26. September mit Komprimierung auf Dateiebene lieferten alle vier Dateien identische Bytes zurück.
Hat der Fortsetzungstest vom 15. Oktober private Unterhaltungen an ein Modell geschickt?
Nein. Der Fortsetzungstest nutzte einen lokalen HTTP-Ersatzserver und stoppte, bevor ein Modell die Anfrage verarbeitete. Veröffentlicht werden nur anonyme, zusammengefasste Messwerte.
Finde heraus, was auf deinem Mac möglich ist
Starte mit einem kostenlosen Scan. Sieh dir eine unterstützte Optimize-Aktion an, prüf danach das Ergebnis und öffne noch einmal, was dir wichtig ist.