# KI-Mac-Cleaner: Was ein Modell entscheiden darf und was nicht
> Rangfolge und Zuordnung dürfen probabilistisch sein, die Löschentscheidung nicht. Wie cc-cleaner, DevCleaner, Agent-Skills und Mole diese Grenze jeweils ziehen, und welches Werkzeug zu Ihrer Festplatte passt.
Published: 2026-08-20 | Updated: 2026-08-22
„AI Mac Cleaner" meint zwei verschiedene Dinge. Das eine ist eine Cleanup-App mit einem
Modell irgendwo darin, verkauft über die Intelligenz ihrer Empfehlungen. Das andere ist ein
Werkzeug, um den Speicherplatz zurückzuholen, den Claude Code, Cursor, Ollama und ihre
Caches im letzten Jahr still und leise belegt haben. Das zweite ist es, was die meisten
Leute 2026 meinen, wenn sie diese Suchanfrage eingeben. Trotzdem lohnt es sich, zuerst das
erste zu klären, denn die Antwort entscheidet, wie viel Vertrauen alles in der zweiten
Gruppe verdient.
## Teil eins: Was das Modell tatsächlich entscheidet
Ein Cleaner, der mit KI wirbt, macht eine Aussage über einen einzigen Schritt in einer
Pipeline, die mindestens vier hat:
1. **Erfassen.** Die Festplatte durchlaufen und vermessen. Arbeit in der Form von `du`,
ohne jedes Urteilsvermögen.
2. **Zuordnen.** Entscheiden, welche App oder Toolchain zu welchem Pfad gehört.
3. **Einordnen und erklären.** Entscheiden, welche zwölf von viertausend Kandidaten einen
Blick wert sind, und in einem Satz sagen, was jeder einzelne ist.
4. **Entscheiden und löschen.** Entscheiden, was gefahrlos entfernt werden kann, und es
dann entfernen.
Schritt zwei und drei sind wirklich unscharf, und dort hilft ein Modell tatsächlich.
Schritt vier ist ein Problem anderer Art, für das ein Modell das falsche Werkzeug ist. Fast
jede Debatte über KI-Cleaner dreht sich in Wahrheit darum, welchen Schritt der Anbieter
eigentlich meint.
### Wo sich ein Modell lohnt
Die Zuordnung ist der ehrlich schwierige Fall. Angenommen, Sie finden
`~/Library/Application Support/Foo Labs` mit 3 GB Inhalt, aber keine App namens Foo Labs
auf der Platte. Die Indizien sind schwach und verstreut: Bundle-Identifier-Fragmente in den
eigenen Plists des Ordners, ein passendes Präfix in `~/Library/HTTPStorages`, ein
`.savedState`-Bundle unter `~/Library/Saved Application State`, eine Installationsquittung
in `/var/db/receipts`. Ein einfacher Namensabgleich scheitert sofort, weil der Hersteller
an der einen Stelle `Foo Labs` schreibt und an der anderen `com.foolabs.editor`, und ein von
Hand gepflegter Katalog deckt die paar hundert wichtigsten Apps ab, bevor er abrupt endet.
Genau in dieser Form schlägt ein Modell eine feste Regel: viele schwache Signale, keines
davon eindeutig, ein langer Schwanz, den niemand je fertig katalogisieren wird.
Beim Einordnen zeigt sich dasselbe Muster: Ein Scan, der 4.000 Pfade und 60 GB zurückgibt,
ist selbst ein neues Problem, kein Ergebnis. Das Erklären ist noch einfacher, denn
`~/Library/Caches/com.apple.nsurlsessiond` in einen verständlichen Satz zu übersetzen, ist
reine Übersetzungsarbeit. Ein Tool, das ein Modell für genau diese drei Aufgaben einsetzt
und das auch so sagt, bewirbt ein echtes Feature.
### Warum das letzte Tor deterministisch sein muss
Die Löschentscheidung braucht drei Eigenschaften, die ein Modell nicht liefern kann.
**Determinismus.** Gleiche Festplatte, gleiche Version, jedes Mal dieselbe Antwort.
Temperatur null erkauft das nicht, weil der Prompt den Inhalt Ihres Rechners mitträgt:
Installieren Sie eine App mehr, verschiebt sich die Dateiliste, und mit ihr verschieben
sich die Tokens, an denen die Entscheidung hängt. Eine Sicherheitsregel, die auf Ihrem Mac
gilt, aber nicht auf dem Ihres Kollegen, ist keine Sicherheitsregel.
**Prüfbarkeit im Voraus.** Eine Schutzliste ist eine Menge von Pfadpräfixen, in einer Minute
vollständig lesbar und zwischen zwei Versionen per Diff vergleichbar. Gewichte plus Prompt
lassen sich nicht als Liste dessen lesen, was verweigert wird, also zeigt Ihnen nichts die
Grenze, bevor Sie sie überschreiten.
**Prüfbarkeit im Nachhinein.** Löscht eine deterministische Regel das Falsche, bekommen Sie
einen reproduzierbaren Fehler: hier der Pfad, hier die Zeile, die es erlaubt hat, hier der
Test, der jetzt fehlschlägt. Macht ein Modell das, ist der einzige Beleg ein Transkript, die
Korrektur eine Prompt-Änderung, und welche Wirkung diese Änderung auf jeden anderen Fall
hat, bleibt ungemessen.
Auch die Fehlerfolgen sind ungleich verteilt. Eine schlechte Einordnung kostet einen Scroll,
ein falsches Löschen von `~/.claude/projects` kostet jedes Transkript, das Sie je hatten.
Die richtige Frage lautet also nicht „KI gut, KI schlecht", sondern wo die Pipeline in der
Mitte geteilt wird: probabilistisch dort, wo ein Fehler nur Aufmerksamkeit kostet,
deterministisch dort, wo ein Fehler Daten kostet.
Die Trennlinie verläuft nicht zwischen klugen und dummen Tools, sondern zwischen der Hälfte der Pipeline, in der ein Fehler nur einen Scroll verschwendet, und der Hälfte, in der ein Fehler eine Datei kostet.
### Auf welcher Seite Mole steht
[Mole](https://mole.fit/) liefert kein Modell aus und führt keine Inferenz durch. Ob ein Pfad überhaupt zum
Löschkandidaten werden kann, entscheidet eine feste, in die App einkompilierte Liste
gesperrter relativer Präfixe mit Einträgen wie `.ollama/models`, `.lmstudio/models`,
`.cache/huggingface`, `.cache/torch`, `.claude/projects`, `.codex/sessions`,
`.grok/sessions` und `Library/Caches/com.apple.e5rt.e5bundlecache`. Die vom Nutzer
editierbare Hälfte ist eine reine Textdatei, die Sie mit `cat ~/.config/mole/whitelist`
lesen können. Die kostenlose [Mole-CLI](https://github.com/tw93/Mole) ist Open Source unter
GPL-3.0 und wendet dieselbe Liste an, der Code, der sie durchsetzt, liegt also offen.
Der letzte Eintrag ist das ganze Argument im Kleinen. `com.apple.e5rt.e5bundlecache` liegt
in `~/Library/Caches`, und in seinem Namen steckt das Wort „cache", also stuft ihn jede
Heuristik der Welt als entbehrlich ein. Tatsächlich enthält er kompilierte Modelle für die
Apple Neural Engine, und ihn zu leeren, während eine App Modelle geladen hat, bricht
Erkennungsaufrufe, bis der Rechner neu startet. Geschützt ist er, weil jemand genau in
diesen Fehler gelaufen ist und die Zeile geschrieben hat.
Der praktische Test für jedes Tool hier ist also eine einzige Frage: Welchen der vier
Schritte übernimmt das Modell? Erfassung, Zuordnung, Einordnung und Erklärung sind
glaubwürdige Antworten. Auf „Es entscheidet, was sicher gelöscht werden kann" folgt am
besten die Bitte, die Liste zu sehen, und gibt es keine Liste, gibt es auch nichts zu
prüfen.
## Teil zwei: Werkzeuge zum Aufräumen nach KI-Tools
Das ist gemeint, wenn die meisten Leute danach suchen. Der Fußabdruck zerfällt in vier
Datenarten mit vier verschiedenen Regeln, und genau dort, wo man sie vermischt, passieren
die Unfälle:
- **Tool-Caches und Logs.** `~/Library/Caches/claude-cli-nodejs`, die Electron-Caches von
Cursor, Telemetrie- und Debug-Verzeichnisse unter `~/.claude`. Regenerierbar und
uninteressant.
- **Transkripte und Projektzustand.** `~/.claude/projects`, `~/.codex/sessions`,
`~/.grok/sessions`. Oft die größte Überraschung in einem Scan, und unersetzlich.
- **Alte CLI-Versionen.** Agenten-CLIs mit Selbstupdate lassen frühere Releases zurück. Bei
Codex sind das rund 300 MB pro Release, fünf angehäufte Releases kommen so auf 1,2 GB,
obwohl nur eines aktiv genutzt wird.
- **Modellgewichte.** `~/.ollama/models`, `~/.cache/huggingface/hub`, das
Modelle-Verzeichnis von LM Studio. Mit Abstand am größten, und Eigentum des Tools, das sie
heruntergeladen hat.
Erst messen, dann ein Tool wählen:
```
du -sh ~/.claude ~/.codex ~/.ollama/models ~/.cache/huggingface 2>/dev/null | sort -h
```
### Mole, für einen geprüften Durchgang, der diese Pfade schon kennt
Das Clean-Tool scannt zuerst und zeigt Ihnen ein Ergebnis, das Sie prüfen, bevor sich
irgendetwas bewegt. Jede Kandidatenzeile trägt ihren genauen Pfad, Eigentümer und ihre
Größe, und alles, bei dem sich der Scanner nicht sicher ist, kommt unmarkiert an, sodass der
Standardklick die kleinere Aktion auslöst. Entferntes wandert in den Papierkorb, statt
direkt gelöscht zu werden, und jede Operation hängt sich an
`~/Library/Logs/mole/operations.log` an, wo `TRASHED` und `DELETED` zwei verschiedene
Wörter sind.
Der Scan ist abgeschlossen, bevor der Prüfbildschirm erscheint, sodass Sie nie Elemente aus einer halbfertigen Liste auswählen.
Zwei Verhaltensweisen sind speziell für KI-Werkzeuge wichtig. Alte Versionsverzeichnisse von
Agenten-CLIs werden angeboten, das aktive Release wird aber nie zum Kandidaten: Das
Launcher-Ziel wird zuerst aufgelöst und festgelegt, sodass die gerade laufende Version
bereits konstruktionsbedingt ausgeschlossen ist und nicht bloß über eine geratene
Versionsnummer. Und beim Deinstallieren zählt die Eigentümerschaft, nicht der
Namensabgleich, sodass beim Entfernen einer App eines Herstellers der gemeinsame
`Application Support`-Elternordner nicht mit angeboten wird, wenn ein noch installiertes
Geschwisterprogramm ihn braucht.
So läuft der Ablauf: Clean öffnen, den Scan abwarten, groß wirkende Gruppen aufklappen,
alles abwählen, was bleiben soll, dann bereinigen und den freigewordenen Platz prüfen. Das
Scannen ist kostenlos, und jedes kostenpflichtige Tool lässt sich zweimal gratis
ausprobieren, sodass sich die ganze Prüfung nachvollziehen lässt, bevor Sie entscheiden, ob
Ihnen $19 das wert sind.
### Die Mole-CLI, wenn Sie lieber im Terminal bleiben
Ein eigenständiges kostenloses Produkt, Open Source unter GPL-3.0, installiert mit
`brew install mole`. Erst die Vorschau, immer:
```
mo clean --dry-run
mo purge --dry-run
```
`mo clean` kümmert sich um Caches und Logs, `mo purge` zielt auf alte Build-Artefakte in
Projekten, und jeder destruktive Befehl akzeptiert `--dry-run`, damit Sie zuerst die genaue
Pfadliste lesen. Sie teilt sich die Schutzliste und das Betriebsprotokoll mit der Mac-App.
Ein Unterschied, bevor Sie das Flag weglassen: Die CLI-Cache-Bereinigung entfernt Dateien
endgültig, während Deinstallation und Rückstands-Entfernung weiterhin im Papierkorb landen.
### cc-cleaner, die Open-Source-Terminal-Option für genau dieses Problem
[cc-cleaner](https://github.com/elexingyu/cc-cleaner) steht unter der MIT-Lizenz, braucht
Python 3.10 oder neuer und lässt sich mit `pipx install cc-cleaner` installieren. Es bringt
22 Cleaner mit, darunter für Claude Code, npm, uv, cargo, Docker, Playwright,
Browser-Caches, sowie eine KI/ML-Modellgruppe für Hugging Face, PyTorch, Whisper und Ollama.
`cc-cleaner status` gibt eine Größentabelle aus, `cc-cleaner clean` öffnet eine interaktive
Auswahl, `-n` ist ein Probelauf.
Das Risikomodell ist explizit: Safe-Elemente werden standardmäßig bereinigt, während
Moderate- und Dangerous-Elemente `--force` verlangen, und die README ordnet „conversation
transcripts, shared stores" in die Moderate-Stufe ein. Den Rest verrät der Quellcode. Der
Ollama-Cleaner entfernt `~/.ollama/models` als Ganzes in einem Rutsch, der
Hugging-Face-Cleaner macht dasselbe mit `~/.cache/huggingface/hub` und `datasets`, und der
Claude-Cleaner bietet die `*.jsonl`-Transkripte unter `~/.claude/projects` an. Gelöscht wird
mit `shutil.rmtree` und `Path.unlink`, es landet also nichts im Papierkorb. Die
Sicherheitsschicht ist eine fest eingefrorene Menge verbotener Systempfade plus die Vorgabe,
dass jedes Ziel innerhalb des Home-Verzeichnisses liegen muss: eine deterministische Liste,
von einem Menschen geschrieben, genau wie es sein sollte. Der Unterschied liegt darin, wo
die Grenze gezogen wird, nicht in der Sorgfalt. cc-cleaner stellt Modellspeicher und
Transkripte hinter ein Flag, Mole verweigert sie ganz.
### DevCleaner, wenn Sie dafür lieber eine Menüleisten-App möchten
[DevCleaner](https://devcleaner.app) ist ein Menüleisten-Tool ab macOS 14, aktuell Version
1.9.0, das 23 Ökosysteme abdeckt, von Xcode DerivedData und Gradle bis npm und Docker, mit
eigenen Scannern für Claude, ChatGPT, Cursor, Ollama und LM Studio. Safe-Elemente werden
standardmäßig gelöscht, bei Warning-Elementen liegt die Entscheidung bei Ihnen,
Danger-Elemente sind nie vorausgewählt, dazu kommt eine feste Sperrliste für Zugangsdaten
und Session-Dateien sowie eine Warnung, bevor die Caches einer laufenden App angefasst
werden. Die Grundfunktionen sind kostenlos, Pro wird als Einmalkauf oder Jahresabo
verkauft; die aktuellen Preise stehen auf der Anbieterseite. Die Website sagt nicht, ob
Entferntes im Papierkorb landet, und genau das lohnt sich, vor dem ersten Lauf zu klären.
MacPaw bietet außerdem eine CleanMyMac-CLI als öffentliche Beta über ein Homebrew-Cask an,
die auf dieselben Artefakte zielt. Sie ist proprietär, ihr Repository dient nur als
Issue-Tracker und nicht als Quellcode, und ihr Verhalten ändert sich ausdrücklich noch, also
lesen Sie lieber, was der Bestätigungsschritt tatsächlich anzeigt, als irgendeine
veröffentlichte Beschreibung.
### Einen Agenten direkt auf die eigene Festplatte loslassen
Der letzte Weg überspringt Cleanup-Tools ganz und bittet Claude Code oder einen ähnlichen
Agenten, die Platte direkt aufzuräumen, wahlweise über einen der veröffentlichten
Cleanup-Skills. Sein Vorteil ist echt, und kein anderes Werkzeug hier hat ihn: Ein Agent
kann über eine Struktur nachdenken, die niemand katalogisiert hat, egal ob das ein erst
letzten Monat erschienenes Framework ist, eine private Toolchain oder ein Home-Verzeichnis,
das nur Sie so angeordnet haben.
Genauso deutlich muss die Kehrseite benannt werden. Die Shell-Befehle entstehen live zur
Laufzeit gegen Ihr echtes Dateisystem, also hat niemand geprüft, was da läuft, bevor es
lief. Einen Probelauf gibt es nur, wenn Sie ausdrücklich danach verlangen. Der
Wirkungsradius ist Ihr gesamtes Home-Verzeichnis, und ein `rm -rf`, das aus einer Variable
zusammengesetzt ist, die sich als leer herausstellt, hat eine lange Geschichte als
Fehlerquelle. Teil eins gilt hier ohne Sicherheitsnetz: Die Entscheidung ist probabilistisch
und direkt mit dem letzten, kritischen Tor verdrahtet.
Vier Leitplanken kosten fast nichts:
- **Den Agenten ein Tool mit Vorschau-Flag steuern lassen, statt Löschbefehle selbst
zusammenzusetzen.** Ein öffentlicher Claude-Code-Skill kapselt die `mo`-CLI und macht
`mo clean --dry-run` vor `mo clean` verpflichtend, gibt die vollständige Vorschau aus und
verlangt eine eingetippte Bestätigung. Der Agent wählt das Ziel, ein deterministisches
Tool führt die Löschung aus.
- **`rm` in den Berechtigungseinstellungen nie pauschal freigeben.** Jeden Löschbefehl
einzeln genehmigen, und dabei den Pfad lesen, nicht nur dessen Zusammenfassung.
- **Den Papierkorb zum Standard machen.** `trash` aus Homebrew, oder `mv` nach `~/.Trash`,
macht aus jedem Fehler einen wiederherstellbaren.
- **Den Arbeitsbereich eng abstecken.** Den Agenten auf ein einzelnes Verzeichnis ansetzen
und vorher `du -sh`, hinterher `df -h` verlangen, damit der behauptete Gewinn gemessen und
nicht bloß geschätzt ist.
### Modellspeicher gehören dem Tool, das sie heruntergeladen hat
Hierfür sollte kein allgemeiner Cleaner Ihr Werkzeug sein, auch keiner der oben genannten.
Ollama und Hugging Face führen beide inhaltsadressierte Speicher, in denen sich Modelle
Blobs teilen, sodass nur das jeweilige Tool selbst weiß, welcher Blob noch referenziert
wird. Nutzen Sie `ollama ls` und `ollama rm `, sowie `hf cache ls` mit
`hf cache rm model/ --dry-run`. Warum manuell gelöschte Blob-Dateien ein Modell
verwaisen lassen, steht in
[KI-Tool-Rückstände entfernen](https://mole.fit/de/blog/how-to-remove-ai-tool-leftovers-mac).
## Der Vergleich im Überblick
| Tool | Entscheidet deterministisch | Zeigt Pfade vorab | Wiederherstellbar | Schützt Modellspeicher und Chatverlauf | Kosten |
|---|---|---|---|---|---|
| Mole for Mac | Feste Sperrliste plus benutzerdefinierte Whitelist | Ja, Pfad, Eigentümer und Größe pro Zeile | Ja, standardmäßig Papierkorb, plus Betriebsprotokoll | Ja, werden nie Kandidat | $19 einmalig, zwei Macs, Updates auf Lebenszeit |
| Mole CLI | Dieselbe gemeinsame Schutzliste | Ja, `--dry-run` bei jedem destruktiven Befehl | Deinstallation in Papierkorb, Cache-Bereinigung endgültig | Ja, dieselbe Liste | Kostenlos, GPL-3.0 |
| cc-cleaner | Fest eingefrorene Menge verbotener Pfade, auf Home-Verzeichnis begrenzt | Ja, Probelauf mit `-n` und interaktive Auswahl | Nein, `shutil.rmtree` und `unlink` | Erreichbar hinter `--force`, nicht verweigert | Kostenlos, MIT |
| DevCleaner | Drei Risikostufen plus Sperrliste für Zugangsdaten | Größen pro Scanner, Danger nie vorausgewählt | Nicht dokumentiert, vor dem Lauf nachfragen | Modellgewichte als eigene Klasse ausgewiesen | Kern kostenlos, Pro einmalig oder jährlich |
| CleanMyMac CLI | Nicht veröffentlicht, Repository ist nur Issue-Tracker | Ja, Bestätigung vor dem Entfernen | Nicht dokumentiert | Nicht dokumentiert | Öffentliche Beta, Anbieterbedingungen prüfen |
| Agent mit Shell-Zugriff | Nichts, Entscheidung fällt zur Laufzeit | Nur wenn Sie es verlangen | Nur wenn Sie den Papierkorb erzwingen | Nur wenn Sie es im Prompt vorgeben | Ihr Agenten-Abo |
| `ollama rm`, `hf cache rm` | Referenzzählung im Speicher selbst | `hf cache rm --dry-run` | Nein, aber neu herunterladbar | Das ist der Schutz | Kostenlos |
## Die Grenze, unverblümt gesagt
Mole ist keine Malware-Abwehr, kein Backup und kein Ersatz für den Deinstaller eines
Herstellers bei Software, die Treiber, VPN-Komponenten oder Systemerweiterungen mitbringt.
Es löscht weder Modellgewichte noch KI-Chatverläufe. Steckt Ihr 200-GB-Problem also
komplett in einer Modellbibliothek, zeigt Ihnen Mole in Analyze nur deren Umriss und
überlässt die eigentliche Arbeit Ollama oder LM Studio. Das ist eine bewusste Grenze, keine
Lücke, die später noch geschlossen wird.
## Die passende Wahl
**200 GB Build-Output und ein Dutzend Toolchains.** Das Volumen steckt in Caches, alten
`node_modules`, DerivedData und Docker, nicht in irgendetwas KI-Spezifischem. Fangen Sie mit einem
geprüften Durchgang oder `mo clean --dry-run` an, und arbeiten Sie sich dann durch
[Entwickler-Caches bereinigen](https://mole.fit/de/blog/how-to-clear-dev-caches-mac) für die Speicher, die
einen eigenen Prune-Befehl brauchen. cc-cleaner eignet sich gut als zweiter Durchgang, wenn
Sie vorher seine Risikostufen lesen.
**Eine große lokale Modellbibliothek.** Für die Gewichte selbst lassen Sie allgemeine
Cleaner komplett außen vor. `ollama ls`, `hf cache ls` und die My-Models-Ansicht von LM
Studio sind die einzigen Werkzeuge, die einen gemeinsam genutzten Blob gefahrlos freigeben
können. Nutzen Sie eine Speicherkarte, um den Speicherort zu finden, und das zugehörige
Tool, um ihn zu verändern.
**Ihnen ist gerade aufgefallen, dass Cursor oder Claude Code Speicherplatz frisst.** Der am
leichtesten zu lösende Fall: Caches und Logs regenerieren sich, alte CLI-Versionen sind
reine Verschwendung, und die Transkripte sind das Einzige, was unangetastet bleiben sollte.
Jedes hier vorgestellte, geprüfte Tool kommt damit klar, die Schritt-für-Schritt-Version
steht unter
[Aufräumen nach KI-Coding-Tools](https://mole.fit/de/blog/how-to-clean-up-ai-coding-tools-mac).
## Häufige Fragen
### Löscht ein KI-gestützter Mac-Cleaner sicherer als ein gewöhnlicher?
Nach allem, was bislang bekannt ist: nicht. Bei der Frage, welcher App ein verwaister
Ordner gehört, und bei der Einordnung, was Aufmerksamkeit verdient, kann ein Modell eine
feste Regel schlagen, weil das unscharfe Probleme mit vielen schwachen Signalen sind. Ob
ein Pfad gefahrlos gelöscht werden kann, braucht dagegen Determinismus und eine prüfbare
Liste, und beides liefert ein Modell nicht. Fragen Sie einen Anbieter, welchen
Pipeline-Schritt sein Modell übernimmt, und verstehen Sie „es entscheidet, was sicher
gelöscht werden kann" als Aufforderung, sich die Liste zeigen zu lassen.
### Ist es sicher, Claude Code den Mac aufräumen zu lassen?
Das ist die flexibelste Option und zugleich die am wenigsten begrenzte. Die Befehle
entstehen live zur Laufzeit und laufen gegen Ihr Home-Verzeichnis, eine Vorschau gibt es
nur, wenn Sie ausdrücklich danach fragen. Wenn Sie es trotzdem tun: Lassen Sie den Agenten
ein Tool mit Vorschau-Flag steuern, statt selbst `rm -rf` zusammenzubauen, geben Sie `rm`
in den Berechtigungseinstellungen nie pauschal frei, schicken Sie Entferntes in den
Papierkorb, und beschränken Sie ihn jeweils auf ein einziges Verzeichnis.
### Löscht ein Mac-Cleaner meine Ollama-Modelle oder meinen Claude-Code-Verlauf?
Das hängt vollständig vom jeweiligen Tool ab, weshalb genau das die erste Frage sein sollte.
Mole sperrt `~/.ollama/models`, `~/.lmstudio/models`, `~/.cache/huggingface`,
`~/.claude/projects`, `~/.codex/sessions` und `~/.grok/sessions` unabhängig vom Alter am
Löschtor, sodass sie nie zum Kandidaten werden. cc-cleaner stuft Modellverzeichnisse und
Claude-Code-Transkripte als Moderate-Risiko ein und entfernt sie, wenn Sie `--force`
übergeben. Lesen Sie die Risikostufen eines Tools vor dem ersten Lauf, nicht danach.
### Was frisst nach einem Jahr KI-Coding-Tools tatsächlich den Speicherplatz?
Meist alte CLI-Versionen und Transkripte, nicht die Caches, die man erwarten würde. Eine
Agenten-CLI mit Selbstupdate kann pro Release mehrere hundert Megabyte zurücklassen, bei
Codex kommen fünf angehäufte Releases auf rund 1,2 GB, obwohl nur eines aktiv genutzt wird.
Transkripte unter `~/.claude/projects` sammeln sich still an und sind das, was einen Scan am
wahrscheinlichsten überrascht, weshalb sie in einem Durchgang eher ausgeschlossen als
einbezogen gehören.
## Weiterführende Links
- [Ollama- und LM-Studio-Modelle auf dem Mac aufräumen](https://mole.fit/de/blog/how-to-remove-ai-tool-leftovers-mac)
für die Mechanik inhaltsadressierter Modellspeicher.
- [Entwickler-Caches leeren, ohne Builds zu zerstören](https://mole.fit/de/blog/how-to-clear-dev-caches-mac) für
Paketmanager-Speicher und verstreute `node_modules`.
- [Aufräumen nach KI-Coding-Tools](https://mole.fit/de/blog/how-to-clean-up-ai-coding-tools-mac) für die
Schritt-für-Schritt-Version, Pfad für Pfad.
---
Canonical HTML page: https://mole.fit/de/blog/ai-mac-cleaner-tools
Blog index for agents: https://mole.fit/de/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
